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)
- Follow these directions (https://home-assistant.io/getting-started/installation-raspberry-pi-all-in-one/#using-the-ozwcp-web-application)
- 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.
good game.
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.
3 Likes
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:
Trust me, you will thank me in the long run
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.
Thanks in advance!
Michael
Yes, I did. There was a similar discussion/problem here which was resolved. Check it out here:
By the way; I only have succes if I add this sensor non-secure
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.
Boy, that was a fun few hours…
HTH
3 Likes
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.
1 Like
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.
2 Likes
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.
254 is for a deep sleep state, which in theory should only be seen when the door is closed.