Aeon Labs Z-Wave Door/Window Sensor

No it is not but the problem definitely sounds similar. I only have to press the button once though and all is good until the next restart. One other thing that is different is that the Alarm_Level_Sensor works fine at all times. Unfortunately, that is not practical for usage with my door.

Like the other poster, I have no issues with this sensor when included within the Smartthings hub.

So… based on the OZW log file, I believe when HA is restarted the device is either asleep or HA marks it as being asleep. Here are the log entries for this device when HA was restarted

2016-04-09 17:55:22.740 Detail, Node012,   ZW_SEND_DATA Request with callback ID 0x0b received (expected 0x0b)
2016-04-09 17:55:22.740 Info, Node012, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.
2016-04-09 17:55:22.740 Info, Node012,   Node 12 has been marked as asleep
2016-04-09 17:55:22.740 Info, Node012, Node not responding - moving QueryStageComplete command to Wake-Up queue

At (re)start, HA does not seem to respond to the contacts opening/closing however…
When I open/close the contacts the log shows entries for each event. The device does not appear to be asleep and HA does get a message when either event occurs. Not sure I understand why HA appears to ignore or not know what the message received actually means. Here are the log entries for when the device was opened then closed

2016-04-09 19:40:24.376 Detail, Node012,   Received: 0x01, 0x09, 0x00, 0x04, 0x08, 0x0c, 0x03, 0x20, 0x01, 0xff, 0x2b
2016-04-09 19:40:24.376 Detail, 
2016-04-09 19:40:24.377 Info, Node012, Received Basic set from node 12: level=255. Treating it as a Basic report.
2016-04-09 19:40:24.391 Detail, Node012,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0c, 0x03, 0x20, 0x01, 0xff, 0x23
2016-04-09 19:40:24.391 Detail, 
2016-04-09 19:40:24.391 Info, Node012, Received Basic set from node 12: level=255. Treating it as a Basic report.
2016-04-09 19:41:08.655 Detail, Node012,   Received: 0x01, 0x09, 0x00, 0x04, 0x08, 0x0c, 0x03, 0x20, 0x01, 0x00, 0xd4
2016-04-09 19:41:08.655 Detail, 
2016-04-09 19:41:08.655 Info, Node012, Received Basic set from node 12: level=0. Treating it as a Basic report.
2016-04-09 19:41:08.670 Detail, Node012,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0c, 0x03, 0x20, 0x01, 0x00, 0xdc
2016-04-09 19:41:08.670 Detail, 
2016-04-09 19:41:08.670 Info, Node012, Received Basic set from node 12: level=0. Treating it as a Basic report.

Hi. Just adding a note here to say that I’m experiancing the same problem. Fibaro Door Sensor + Aeon Zstick Gen5 + RPI 3 + HA 0.16.1

Same issue with me too…

  • Fibaro Door Sensor
  • Aeon Zstick Gen 5
  • HA 0.16.1

I’ve tried it on RPI 2 as well as Ubuntu 15.04.

Same result.

I have been researching this problem for days now and the answers are always the same. “After each restart of the PI or HA you must manually wake up each sensor”. With my Aeotec sensors this means removing it from the door, removing the back and pressing the Z-Wave button. That is a deal breaker for me.

What I dont understand is that these same sensors worked without issue when included on a Smarthings Hub. Based on my findings I see there are two common pieces. One is HA itself and the other is a Aeotec z-wave Stick. Which is it?

I would like to know if anyone is successfully using either Aeon or Fibaro door sensors with HA and a controller other than Aeon Stick

I am using Aeon Gen 1 Door/Window sensors I bought a lot of 5 of them on eBay. 4 of them auto connect and work with out incident as soon as HA is started. One is stuck that I have to manually trigger the tamper switch before I can get a magnetic switch read. I have configured them all the same in open-zwave-control-panel but I just don’t know what the difference in configuration is on my 5th. I think that this is a configuration/setting on the door sensor that is causing my connectivity issues.

links for my hardware:
USB controller: Aeon zstick
Door/window sensors: Gen 1 Aeon door sensor
Setup working with HA versions 0.16.0, 0.16.1, 0.17.0, 0.17.1, and 0.17.2
Server OS: DISTRIB_DESCRIPTION=“Ubuntu 15.10” on kernel 4.2.0-35-generic

Just got to testing some configs with open-zwave-control-panel and found that I have two different configurations for my Aeon door sensors.

Again I have 5 sensors 4 work, 1 I have to hit the tamper switch for it to communicate

the only value that differs is under the configuration settings
Determines which report will be sent when Magnet switch is opened/ closed. ____

Screen Cap:

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. :slight_smile:

I am glad that worked for you!

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.

Base 2________Base 10
000010001 === 17
100000000 === 256
100010000 === 272
100010001 === 273

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 :wink:

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.

1 Like

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)

  1. Follow these directions (https://home-assistant.io/getting-started/installation-raspberry-pi-all-in-one/#using-the-ozwcp-web-application)
  2. If your door sensor shows up as asleep, press the zwave button to wake it up.
  3. Make sure it’s registering by opening and closing your door. You’ll see it switch from off to on.
  4. 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…)
  5. Hit “Save…” at the top right.
  6. Hit Close.
  7. If you’re using Putty like me, you can hit Ctrl+C to get a command prompt in the Putty window.
  8. sudo reboot
  9. 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:

  1. Make sure HASS is shutdown so that it is not using the z-wave controller
  2. Install open-zwave-control-panel
  3. 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.
  4. Setup the new device in open-zwave
  5. 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
  6. 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
  7. Click the close button in open-zwave to detach it from the z-wave controller and shutdown open-zwave
  8. Start HASS and wait for it to fully boot up.
  9. 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.
  10. 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