Aeon Labs Window / Door Sensor 6

I purchased a Aeon Labs Window / Door Sensor 6 model ZW112-A. The OpenHAB log says that it isn’t in the database. “No database entry: Aeon Labs [ID:70,Type:102]” I tried to add it but noticed it is already in the database, it just isn’t fleshed out yet.

I found a version of the manual that has the configuration and association parameters at

Do I need a user account to modify the data base item?

Also I have a Aeotec Dry contact sensor that looks to be in the database, but the OpenHAB log reports “No database entry: Aeon Labs [ID:61,Type:102]”


yes. Sign up and let @chris know and he can grant access for you to upload the xml file generated by your binding. This will, as you say, flesh out the device. You can then also use the document to add all the configuration parameters.

It is a pretty new device and looks excellent, being it can be painted and all. What do you think of the form factor now that it is in hand?

Thanks @xsnrg. I made the account, I’ll see what I can do about getting rights from @chris.

The sensor looks nice, and seems to function well. But I do have one complaint. The sensor uses a mounting bracket to hold it in place. The bracket is what is actually fastened to the door or window. I am mounting the sensor on a sliding glass door (I’ll attach a photo later) . This makes the sensor fit snug against the corners of the frame of the door. However, when I want to take the sensor off the mount to access the button ir charge port, I have to slide it into the direction of the door frame, and the door frame gets in the way and prevents the sensor from releasing. Even with three door open I still have the top of the door frame in the way.

I am going to play with the positioning of the sensor to see if I can make a compromise where the switch still sees the magnets, but the sensor isn’t so close to the frame that I can’t remove it.

On another note. There isn’t an xml file in the directory for the door sensor.

Should be done - any problem, please just yell…

First thing to check is if the device is waking up - you will normally need to press a button on the device (often 3 times) to wake it up, and you may need to do this a few times. When you do this, it needs to be close to the controller…

If this doesn’t work, then please provide a log showing the startup of the device and its wakeup so I can see what’s preventing the initialisation…

OK. I had to wake it up several times, but it made an XML file and I have fleshed out most of the database entry.

However I am not sure about a few things:

I am getting the warning: “There are 1 association groups but none are linked to the controller. Is this correct?” Should I check the box on the association? I have never used them sorry.

I am not sure how to determine the firmware version

I copied some of the entries form another Aeon Labs door sensor. Like the basic, generic, and specific classes. I hope that is OK.

Also there is still an error: No channels have been assigned even though there are user configurable command classes.

Lastly and not related to the database entry, there is an option to bind this as a security sensor and encrypt the traffic. Does 1.8.3 support this?


Probably - the association is used to report information to openhab, so if whatever information the association group reports is something that is needed, then you need to check the controller box.

This information should be automatically added when you load the XML file to the database. I wouldn’t suggest to edit this sort of information.

Again, this should have been added to the database when you loaded the XML. It is probably not a good idea to add this manually.

Channels should be added when you load the XML file - I’m starting to get the feeling you haven’t done this :wink:. I would suggest uploading the XML to the database, although given you’ve manually filled data in now, it might reject the file… If so, please email it to me and I’ll try and sort it out…

I did upload the file initially. Before I started adding things manually.

The only thing I changed on the xml file was my id. I can’t remember the exact field name, I think it was openhab id. It seemed to be the same in all of my nodes, so I changed it to all zeros as I assumed it was personally identifiable information.

Was it successful, or was there an error? It doesn’t seem to have worked.

I guess this is the homeId - it’s fine if you change it as it’s not used, and it won’t matter to the import. Personally I wouldn’t bother hiding it though - it’s data that is useless and if someone wants to attach your system, they can easily see if as it’s transmitted in the open on every zwave frame.

Anyway, I will dig out the XML file you loaded and manually add the channels when I get a chance.

I just switched to openHAB2 and I’m having trouble with this device. If I search for a new Z-Wave thing it finds it but the device is unknown. I have woken the device up until my thumb hurts :slight_smile:

I have tried including it as a normal and as a security device, but the result is the same.

Everything in the database looks OK. Should I provide you with another XML node file?


2017-01-19 00:02:09.229 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE to ONLINE: Node initialising: DETAILS
2017-01-19 00:02:09.231 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: DETAILS to ONLINE: Node initialising: GET_CONFIGURATION
2017-01-19 00:04:24.882 [ThingUpdatedEvent         ] - Thing 'zwave:device:d69ac13a:node21' has been updated.
2017-01-19 00:04:27.601 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: GET_CONFIGURATION to ONLINE: Node initialising: DYNAMIC_END
2017-01-19 00:04:27.610 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: DYNAMIC_END to ONLINE: Node initialising: HEAL_START
2017-01-19 00:04:27.611 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: HEAL_START to ONLINE: Node initialising: DELETE_ROUTES
2017-01-19 00:04:32.080 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: DELETE_ROUTES to ONLINE: Node initialising: RETURN_ROUTES
2017-01-19 00:04:45.091 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: RETURN_ROUTES to ONLINE: Node initialising: NEIGHBORS
2017-01-19 00:04:47.178 [ThingUpdatedEvent         ] - Thing 'zwave:device:d69ac13a:node21' has been updated.
2017-01-19 00:04:47.179 [ConfigStatusInfoEvent     ] - ConfigStatusInfo [configStatusMessages=[]]
2017-01-19 00:04:47.181 [hingStatusInfoChangedEvent] - 'zwave:device:d69ac13a:node21' changed from ONLINE: Node initialising: NEIGHBORS to ONLINE

Yes - it would be good to check the xml file of your device.

Here is the node file

node21.xml (9.8 KB)

Do you see anything in the file that stands out as an issue?

Hi all.
I would like to add something to this thread. I do have the same sensor and (in my case) the best way to get it detected correctly was to have it included (securely) to the controller (it will then already show in the debug-logs) and then awake it (pressing that button)… then keep it awake (pressing it for 4 seconds)… and while doing that, always open and close the sensor. I also did one health check (hold for 6 seconds)… just don’t give up, keep playing with that button and the open/close until the sensor has a name in the thing-discovery. :slight_smile:

Didn’t get the XML though… but luckly, wasn’t necessary!

Hmmm - if the XML isn’t written, then the device initialisation probably didn’t complete properly. Getting the XML is necessary to speed up initialisation when the binding starts (among other things).