Switch 1,3 are set to 17 (in the tool tip that pops up this is the recommended default)
Switches 2,4 are set to 272 (not sure if this is recommended or some special config value)
Switch 5 which was my problem switch was set to 17. I set it to factory defaults, which is 0, and that stopped all communication of mag switch/tamper switch events. I set the value to 272 and that magical number seems to be the right value for it to auto communicate to the controller.
I did notice when I tried an invalid value there are tons of debug messages and if it does not understand what you are asking it to do it defaults to 0. Be sure to hit refresh, write down that value and then play with settings that way you have something to go back to.
Bingo… For some (unknown) reason I have 3 out of 5 working. The other 2 are being used to test different configurations. I really do not understand why they suddenly started to work but I do believe your magical number is in play here. I did change other parameters as well so I do need to explore different configs without the magic number or only changing the 17 value to 272 and no other changes. All I know is that I can get them to work with HA which is a big deal. Thanks for your post.
I feel like I had one sensor that had a value of 256 as well looking at all the numbers in binary it looks like the binary output should be 9 1/0’s in length and start with a 1 meaning the value would be > 256. I would bet that 273 would work. I just wish there was a way to translate the spaces much like the linux chmod.
The sensors worked within Smartthings without any special tweaks required therefore I decided to look at the ST device driver for this sensor. I noticed that the Basic Set report was used for open/close contact. Got to wonder… Would 32 (00100000) have worked as well??? Now that I have all 5 sensors working dont think I will rock the boat
BTW: It seems to only parameter that I need to change to get these sensors working was the report type from 17 to 272. All other parameters I tried made no difference.
How are you able to change the value from 17 to 272? When I try to change it, it changes back to 17. This is of course after saving changes and copying the zwcfgxxxx file into the hass directory.
Out of curiosity, why are you copying the xml into the hass directory after making the change? I didn’t and when HA loaded and scanned the ozw component it updated the current xml in my hass path.
I had that problem as well. I cant remember how I resolved it. I believe I changed the number then saved it. There was no “magic bullet”. I kept trying till it stuck. I do know thgat once I got the first one working the other remaining 4 were a snap.
This same issue has cropped up on my system. I have an Aeotec DSB29 Door/Window Sensor (2nd Edition). I’m running on a Raspberry Pi 3 set up with the All-in-One installer. I’m using an Aeotec Gen5 USB hub on /dev/ttyACM0.
After pressing the zwave button, the sensor shows up in OZWCP as “off” when the door is closed, "on"when open. However, it says “Asleep” the whole time and after a few minutes goes to sleep for real I suppose. I’ve tried the above recommended change to 272 but it keeps changing back to the default 255. Any ideas? Did any of you refine the process for getting this to work?
Okay… well I guess I needed to post in order to get it to work. It’s working now. Here’s what I did:
(Prerequisite: make sure Home Assistant is stopped)
If your door sensor shows up as asleep, press the zwave button to wake it up.
Make sure it’s registering by opening and closing your door. You’ll see it switch from off to on.
While it’s still awake, change the parameter (as mentioned above) to 272 and hit the Submit button below. (I’m guessing this reprograms the door sensor so that it sends that number instead of what it used to send. It has to be wide awake to be reprogrammed…)
Hit “Save…” at the top right.
Hit Close.
If you’re using Putty like me, you can hit Ctrl+C to get a command prompt in the Putty window.
sudo reboot
For good measure, I hit the zwave button again on the door sensor after rebooting. Not sure if this matters.
This kind of dance is sadly par for the course for any battery powered ZWave device. IF you have a powered option its best to use it just for the config piece. FWIW, when they are setup I have found ZWave to work very well.
Z-Wave is very finicky, but the proper way to add new devices is as follows:
Make sure HASS is shutdown so that it is not using the z-wave controller
Install open-zwave-control-panel
Make a symlink to the zwcfg file inside of home-assisstant, so that all changes will persist between the two interfaces. Make sure HASS’s copy is the source, so open-zwave will be using a link to the one in the HASS folder. This way your zwcfg file can be backed up with your .homeassistant folder and you won’t lose all of your device references if you move to another machine or have to start over.
Setup the new device in open-zwave
Wait for open-zwave to fully query the device to pull all the information about it so that it assigns the correct device into the zwcfg file
Assign a name to your new z-wave device in open-zwave (like Living Room Window)… when it is fully accessd by HASS, it will use that name with the node number attached, so you will get something like sensor.living_room_window_7. Do not add the word sensor or switch or whatever to the name in open_zwave, otherwise it will be called sensor.living_room_window_sensor_7
Click the close button in open-zwave to detach it from the z-wave controller and shutdown open-zwave
Start HASS and wait for it to fully boot up.
The first time HASS starts up with a new z-wave device, it will be labeled something like sensor.sensor__7 or something like that. Do not use that reference in your automations. This is a temporary name. I find that if I wait a few minutes and then restart HASS again, on the next startup, the sensor.sensor__7 device will now read as sensor.living_room_window_7, and that is the permanent name you want to start using in your scripts and automations.
If after a restart it still shows the temporary name, wait a bit longer, and restart again… rinse and repeat the restarting of HASS, eventually it will reference the name you assigned it in open-zwave
FYI, you don’t have to go through these steps, top to bottom, for each device you have on hand, as you can do multiple devices at once. If you have multiple devices already purchased and in hand, add them all in open-zwave one after the other, giving them all names, so you only have to restart HASS the once and hopefully HASS will start pulling them all in simultaneously. Then just go through the process again for any new devices.
Thanks for these tips jbardi. Yeah I did notice that the entity id’s (there are three associated with the door sensor) changed from their initial names after a hass reboot.
Yeah, the z-wave devices will often split out and display as several devices, each referencing a different interface of the one device. Many of the “secondary” references you will not use, such as alarm_level, alarm_type, burglar, etc. I mean you can use them if you like to pull attribute data from for template sensors, etc, but often the multiple devices contain a lot of the same attributes, like battery level. Most people will only use the primary sensor or switch device and ignore the secondary interface devices. If you are not overriding the default_view group, you may want to hide those secondary devices by adding them to customize: and setting them as hidden so they don’t display in the frontend.
I would highly recommend overriding the default_view, as having a frontend full of rows and rows of circles that are hard to read is pretty ugly. Its preferable to create groups and put all of your devices in the groups. Makes for a very clean look.
Also, new users of HASS should definitely look into splitting out their configuration.yaml into different files before they get too deep into setting things up. Shoving everything into the configuration.yaml gets cluttered, VERY long and hard to find and edit what you want.
Look at this topic on home-assistant to understand what I am talking about:
Was anyone able to get the Aeon Labs Aeotec Zwave Door Window Sensor 6 ZW120 working with Home Assistant? I have it connected via Aeon Labs Aeotec Zwave USB ZStick Gen 5 ZW090. I have probably spent 12 hours now adding and removing and getting it working for 5 min, then it stops sending door open updates (the burglar updates send instantly and without any issues). This happens both in regular and secure mode. I have a Fibaro Zwave Door Window Sensor FGK-101 that works great and was super easy once I added a wired device to extend range. It instantly reports all door open/close updates.
So this was driving me crazy, and I’m so glad I found this post.
Just wanted to share how I fixed this with 0.46 installed through the AIO installer on a fresh Raspbian system.
Shut down the HASS service.
cd to /srv/homeassistant/src/open-zwave-control-panel
then start the openZWave control panel by typing ./ozwcp (you can specify a port, but the default it 8090.
open up the control panel http://[ip address]:8090/
specify the device name at the top (should be familiar if you setup the device in your configuration.yaml. Mine was /dev/ttyACM0)
Hit Initialize.
Under controller, I added the device. For me, I had already commented out the security key in the options.xml file found under the /srv/homeassistant/src/open-zwave-control-panel/config directory of OZW (it’s a pointer…), so I added it as a secure device.
Showed up just fine in the list. HOWEVER, click on the node table row for the Aeotec XW112 Door Window Sensor 6 (make it highlight green.
Then select “Configuration”
This next step is important. Hold down your wake button on the back of the sensor for 3 seconds until it turns yellow. Then let go. It should start blinking yellow. This’ll wake it up for a few minutes. You should see “Awake” or “Dynamic (awake)” in the last column now instead of “asleep” or “sleeping” or something to that affect.
While it’s awake, change the “Report Type to Send” to be “Sensor Binary Report”, then click the “submit” button at the bottom. This’ll push that setting the the now awake sensor.
Now at the top right, you’ll see a “save” button. Click that.
Then go into /srv/homeassistant/src/open-zwave-control-panel and copy the zwcfg_0xxxxxxxx.xml file from that directory to your HASS directory. Be sure to back up the original file thats IN the HASS directory first, just rename it to .BAK or something.
Then, go back to the control panel, and click the “close” button to the left of the “initialize” button you originally clicked. This’ll unmount your z-stick.
Then go back to your shell, and ctrl+c to end the ozwcp thats running.
Then start HASS back up.
Now you should see it as a binary sensor, and on/off values will work in your automations.
Just made account to say thanks for pointing me in the direction. Also to post that this fix is even easier now in HASS 0.55.
For my sensor: aeotec_zw120_door_window_sensor_gen5
Change the following two value in the zwave config section for the node (zwave node management):
121:Report Type = 17 (Ideal Setting for OZW is 17 (Sensor Binary and Battery Report)
That fixes the issue with status of the binary sensor changing when the magnet is removed.
1:Sensor Binary Report = Open 0xFF, Close 0x00 (mine was inverted)
This fixes the issue with HASS showing the opposite state. i.e. By default mine showed a check mark when the magnet was removed and empty circle when magnet present - which is backwards. Now it’s fixed. [edit] Nevermind. Didn’t need to do this step.
What I did need to do was go to customization and change the sensor class to “safety”. Now it behaves how I want and the icon changes appropriately.
For those who were having issues with changing the 121: report Type variable and getting it to stick, I had the same issue and you have to press the z-wave button on the back of your sensor and almost immediately afterwards change that variable as I think it only stays active for a short time. If you do it straight after you press the z-wave button it should update the value to 272, which solved my issue.
Thanks very much for the detailed response to this guys.
I never har that problem, but i thought I did. After a long time I discoverd that the access_control shows 22 when open and 23 when closed. The number now (254) is because the sensor is not mounted on the door. I hope this helps.
