Aeon Labs Z-Wave Door/Window Sensor

Configuration
1

Is this sensor supported within HA? The first time I added it to my USB stick, rebooted the PI and started HA I had 3 new AEON devices (temp/??/Sensor). The one named Sensor 5 worked exactly as I hoped. When I opened the door HA showed a checkmark inside Sensor 5. When I closed the door, the checkmark was gone. Perfect.

I then had to restart HA and the device once named Sensor 5 now became Aeon Labs Sensor 5. HA no longer responded to the device open/close states. Restart and reboot did nothing. I removed/excluded it from the USB stick, (re)included and upon restart the device became Sensor 6. The other two previous sensors were no longer present. HA did not respond to either open/closed states of the sensor even though it was apparent by the device LED that the contact was behaving as it should.

I am at a loss. Without the ability to get open/close sensors to work properly my project is dead in the water before I even get it off the ground :frowning:
Any help?

2

While I do not have those same sensors, my motion sensors register as a different device for each function, but they have a base device of id=“4” or id=“5”. It has not changed due to reboot. There are two that I use, the rest I have hidden in my customization section. There should be a file in your .homeassistant directory that starts with zwcfg_0xd…xml that can help you identify things. I actually modified the file to put in friendly name for the device.

what I am using for my motion sensors:
binary_sensor.stairwell_motion_sensor_4
binary_sensor.stairwell_motion_sensor_5

The other items that I have hidden.
sensor.stairwell_motion_alarm_level_4:
sensor.stairwell_motion_burglar_4:
sensor.stairwell_motion_alarm_type_4:
sensor.stairwell_motion_sourcenodeid_4:
sensor.basement_motion_detector_alarm_type_5:
sensor.basement_motion_detector_burglar_5:
sensor.basement_motion_detector_sourcenodeid_5:
sensor.basement_motion_detector_alarm_level_5:

3

Well, it’s hard to tell if a z-wave device is supported or not. The general idea is that everything supported by OpenZWave should be supported by home-assistant. Though, there is no development made in home-assistant to target a specific device.

A Z-wave device include some generic building blocks like sensors, switches and so on and those are generally implemented in home-assistant. That is why you don’t get a “Door-sensor” device in home-assistant, but you get every buildingblock as a separate device (Temp, Sensor…). As an example, i have some Fibaro Smoke Sensors, and every one of those devices have 5 different sensors, and some alarms built into it that all appear as separate devices in HA.

The identification of the device may be a bit slow sometimes, thats why the device was first given a generic name like “Sensor 5”. After your restart the identification were made and the device was renamed. Though it is weird that it stopped working after that.

I would like to know a bit more about your setup. How do you run HA? In what environment? Could it be that you have installed something more z-wave related that interferes with the communication to your z-stick? In the beginning i tries a lot of stuff and installed a lot of z-wave tools on the same environment and that kinda ****d up my HA in the way that devices turned on and of by it self and i didn’t get the correct status in HA.

Good luck! Don’t give up!

4

Brand new Raspberry PI 3 with the latest version of Raspian. The really is nothing else running on the PI at this moment. The USB dongle is Aeon Labs Z-Stick S2 The only other device I have included so far is a Leviton Socket (Model # DZPD3-742).
I got HA and the z-wave component installed following the instructions found on the Main HA site as well as Z-Wave - Home Assistant

Let me know if you need any more.

Thanks in advance

5

Then I’d suggest you install open zwave control panel (https://github.com/OpenZWave/open-zwave-control-panel) and do a network health check

6

Well I sort of got it working but only through persistence. After excluding/including several timeit works again but I am almost sure it will fail after a reboot. The two out of 3 sensors working are “Aeon Tech Door/Window Alarm Level” and “Sensor 9” As indicated by images below, the latter shows a checkmark when the door/sensor is in open (magnets are separated) position. No mark when closed (magnets are touching). The Alarm level either shows number 0 or 255. The 255 indicates the little wheel switch on the main sensor part is pressed down. Once released, the number becomes 0. I believe this is used for a sliding window and the magnet is not required.

7

More to the above. After a “sudo service hass-daemon restart” The above screen(s) change to:

Note that the sensor formerly called Sensor 9 is now labeled aeotec door/window sensor sensor 9 It no longer works:rage:

What does work is the Sensor Alarm level but that is used for sliding windows when a magnet contact is not practical.

8

What is the complete entity-names if you check in your dev-tools? http://your-uri/devState

9

For the Magnet contact sensor the complete name is:
binary_sensor.aeotec_doorwindow_sensor_sensor_9

For the Sliding window Sensor (current value=255):
sensor.aeotec_doorwindow_sensor_alarm_level_9

The one sensor (current value=0) which does not appear to do anything:
sensor.aeotec_doorwindow_sensor_alarm_type_9

Since my last post I have found that after an HA restart, if I open the sensor casing and press the z-wave (include/exclude) button the magnet contact sensor begins to work properly within HA If I reboot/restart, this sensors stops working until I once again push this button. The Alarm_Level_9 sensor works always.

10

Is this you? https://github.com/OpenZWave/open-zwave/issues/812
If not, seems to be exact same issue, and feels like a generic OpenZWave issue due to sleep-state in the device itself

11

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.

12

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.
13

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

14

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.

15

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

16

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

17

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:

Screenshot from 2016-04-11 18-51-20.png716Ă—189 29.2 KB

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.

18

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:

19

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

20

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