Zwave door sensor

[orct...@gmail.com]

Hi

i am trying get the door sensor to work but not having any luck. I have attached the node file for more info on the command classes that it supports. I can get the battery level to work with the BATTERY command. I was wondering if the command clases it supports are also supported by ORC and any help in implement would be greatly appreciated.

i tried setting it up with the STATUS command and custom sensor as well as a level sensor but not neither seemed to work.

here is more the user manual of the device:

https://community.smartthings.com/t/monoprice-recessed-zwave-plus-door-sensor/52247

https://www.monoprice.com/product?c_id=122&cp_id=12212&cs_id=1091804&p_id=15268

Thanks!

[c steele]

If this is "eerily similar to the aeon labs one" and not just in looks, then it uses the Security feature and that means it is unusable to other Controllers, in parallel. I have 4 of the Aeon ones and I have tried to get them working with OR with no success. They all connect to SmartThings, and once there, since they have shared a security key already, won't communicate in non-security mode with my Z-Stick (OR). After unpairing them, I can see a conversation, with my Z-Stick (OR) but I have never gotten them to be useful on OR. Now, I just add them to SmartThings and use them there.

All the Security Feature devices seem the same, I can pair them to one Hub (Controller) at a time, although even after pairing, functionality is iffy. This includes the Aeon MultiSensor6 for example. It works beautifully on SmartThings, pretty much not at all on OR. (No functionality - perhaps battery, but with needing to edit the Node files to adjust device values (vs a gui interface on SmartThings) there's no reason, in my environment, to pursue OR's use of this category of device.)

I have 4 Controller/Hubs on my Zwave network, running in parallel. SmartThings, Z-Stick (OR), Staples, Wink. None do enough, by themselves to be fully useful. I also have what might be called Remotes, but are actually Controllers, such as the MiniMote and a 7 button In-Wall "remote." But so far, other than to confirm they work with SmartThings and not with OR, I don't use them. None are as useful as the Pico Remotes from Lutron via Staples Connect Hub.

[orct...@gmail.com]

Thanks for your comments and thoughts. They do have security enabled- the node file shows security.

However I can get the battery status to work with the "battery" command. So i have a feeling it is not related to security. Looking at the command classes in the node file, it looks like it uses command class "notifications" for communicating change in state. Not sure if this command class is supported in OR.

Again I am fairly new to OR and Zwave so I can't be sure.

[c steele]

I don't want to get overly technical but there are highly technical docs out there now.. Sigma has opened access. If you want to read all the gory details, they are available to you.

Security can be S0 or S2 with S2 further divided into 3.. so that door locks (perimeter security) devices perform differently from light switches, yet all are part of a secured Zwave network. Of course there's always unsecure. It's possible for a device to pair to a Controller securely and still respond to another controller via insecure. Door locks wouldn't want to work like that, while a light switch might. Battery level certainly seems like a value that might be "visible" via insecure.

[Rainer Hitz]

The file node8.xml looks good so far that means the device has been successfully included and (secure) communication with the device works very well.

Currently the sensor device doesn't know where to send the status update because a Z-Wave association from the device to the controller is missing. In order to add the association you have to edit the node8.xml file manually and add the following association setting:

<configuration hash="8B3B690C7F146CE4B7849E0147043B51">
    <associations>
      <association-group id="1" capacity="5">
        <association>
          <node>1</node>
        </association>
      </association-group>
    </associations>
    <parameters />
    <wake-up interval="3600" />
</configuration>

After you've edited the file you have to restart the controller. Note that your device cannot be configured immediately because it is sleeping most of the times. In the worst case you have to wait 3600 seconds (current wake up interval) before the new association configuration will be active. In order to accelerate configuration of a battery powered device you can wake it up manually (see device manual). I think in your case you have to press the Z-Wave button on the device for 6 seconds. I'm not 100% sure about that because I couldn't find a device manual but I could imagine that the device behaves similar to a Aeon Labs Recessed Door Sensor and this device is very well documented.

See also the 'Association Configuration' section in the OpenRemote Z-Wave documentation.

If you encounter problems configuring the device try it with the following currently most up to date Z-Wave version : Z-Wave 3.1.2 Beta1 (*REPLACE* zwave.jar in the folder <OpenRemote Controller>/webapps/controller/WEB-INF/lib) 

I'm thinking about adding the Z-Wave association from the device to the controller automatically at inclusion time of the Z-Wave device. With the new Gen5 devices this is possible because the so called 'Lifeline' association is always in the association group number 1. In the past  there was no guarantee that the 'Lifeline' association is in group 1 (e.g. Fibaro has choosen group 3 most of the times). So in an upcoming version of the Z-Wave protocol implementation there will be no need to configure the 'Lifeline' association in case of Gen5 devices.

[Rainer Hitz]

Configuring a security enabled battery powered device works only if you use the currently most up to date Z-Wave version : Z-Wave 3.2.1 Beta 1 (*REPLACE* zwave.jar in the folder <OpenRemote Controller>/webapps/controller/WEB-INF/lib) 

[orct...@gmail.com]

thanks! greatly appreciate the quick responses on this forum. I will try adding the association configuration in the node file as you have pointed out and test it out. I am already using the 3.1.2 Beta 1 version of the zwave file. 

Out of curiosity, is there anything special or different about this device that requires us to add the extra association parameters manually? I have 7 or 8 other ZWave devices and have not had to do this for any of them in the past. I just added a light wall switch (node9 - xml file attached) and it works fine without those extra association parameters. Is it because of the security being enabled on these door sensors or is it something else? Would be good to know for future.  

Thanks again

[orct...@gmail.com]

after adding the association parameters, the door sensor is working great! It makes sense that battery powered devices that are mostly sleeping and only wake up to send changes (without being polled by the controller) would need to know where to send the messages to and hence would require the association parameters specified as opposed to the some other devices like switches that only respond to polls from the controller.

thanks again!