HA Z-Wave not recognizing Aeotec recessed door sensors?

[richardtallent]

I’m new to HA and new to Z-Wave. I installed my first Z-Wave devices – two Aeotex Recessed Door Sensor 7’s. I’m using the Z-Wave integration and a Zooz Z-Wave Plus S2 USB Stick ZST10.

After a significant amount of effort trying to pair them, I got them to show up under the Z-Wave integration configuration panel. However, they show up as Aeotec Limited Unknown: type=0102, id=00bb rather than being recognized as a door sensor.

I believe what I’m then seeing is a result of them not being recognized – under the Entities for each one, there’s a whole *slew of entities.

I think I figured out the three I actually care about for each sensor (boolean state, alarm type for open/close events, and battery level???), and I manually renamed those entities, as well as the nodes themselves:

I’ve checked “Exclude this entity from Home Assistant” for each of the other miscellaneous entities, but my Overview still looks like this:

Is this really the sort of laundry list I should expect when I add a Z-Wave device, or is this the result of the integration not having information to interpret this into a more reasonable number of entities with states like “open/close”, etc.?

I have four First Alert Z-Wave smoke detectors sitting here and a third door sensor, but I don’t want to install them yet until I know if I’m missing a step somewhere along the way to make these show up with a bit more syntactic sugar in the HA UI.

[AGW (Andrew)]

Is that not just that you haven’t edited down the number of badges in your default view to something manageable?

[Bartem]

As @AGW said that is the default view where everything is added automatically… you may want to “take control of your Lovelace” and make a view you add only the things you want to see… https://www.home-assistant.io/lovelace/dashboards-and-views/

As far as the Door sensor, you may want to search the forum for just that model number, it’s possible it is not supported out of the box, which in most cases means you would have to make a template sensor based on one of those “extra” entities you saw. If you look at them while opening and closing the door, one of those values should change when the door opens and closes. You would then make a template binary sensor based on that entity…

Template Binary Sensor

[richardtallent]

Ah! So this is normal behavior when adding ZWave devices?

If my setup has now “graduated” to needing me to take over and create the dashboard manually, that’s fine. I was hoping to avoid it a bit longer, since I’m sure that’s going to be a whole other learning curve. So far the default dashboard logic has done pretty good creating panels and controls for everything – LIFX, MiLight, RadioThermostat, Wemo, security cameras, printers, etc. So it was just a little surprising to see a single new door sensor pop up as 9 separate, interpreted raw data streams.

What would be involved in adding support for this door sensor? I saw some sort of XML config to interpret its data on GitHub, but it was buried in the git repo for the OpenZWave integration, which I gather is unrelated to the ZWave integration that’s part of the HA Core?

I can do the template thing, but that sounds like something I’d have to copy/paste for each sensor, and it wouldn’t improve the situation for others who buy the same sensor. I’d rather put that effort into a pull request and make it come in better by default, if that’s reasonably straightforward.

[Bartem]

@richardtallent

Ah! So this is normal behavior when adding ZWave devices?

For some devices yes. Most Z-Wave devices will have quite a few entities, most of the time one of which will be the applicable door or motion binary sensor entity you are expecting to see… or a regular sensor entity for something like a temperature or lux meter… but sometimes you will need to create your own using the values from one of those other entities… I have a motion sensor I had to do this for, but all of my other devices properly generated the expected type of entity based on what type of device it is.

For your sensor, it’s possible someone has already had this question, and either it is supposed to be recognized, and is not…
I also read a few things about changing a “parameter” on the device…
or it’s a very basic template sensor that you need to create and once you make the first one, the others would be super simple…

is there a more specific model number for the sensor… ZW08 or something like that?

also as you mentioned you could customize the XML file so it is detected automatically, but how exactly to do that I would have to defer to some of our experts on the subject as I have never had to do that…

Here are a few posts that may be relevant…

Adding the Aeotech recessed door sensor

I have a Aeotech recessed door sensor which shows up fine in HA but always shows as ON. According to this, I need to switch the sensor from Basic Set to Sensor Binary Reporting. I tried using the zwave set_config_parameter service calls with the following which just causes HA to stop: { "node_id": 38, "parameter": 121, "value": 16 } Items logged after I call set_config_parameter: 16-10-24 21:31:09 homeassistant.components.http: Serving /dev-service to 172.19.210.23 (auth: False) 1…

How do I setup this Aeotec zw089 Recessed Door Sensor?

I purchased an Aeotec Recessed Door Sensor Gen5 from Amazon, Click here to see it on Amazon. It has been adopted into the Z-Wave on my Home Assistant and under Z-Wave Node Management, I have named it “Pool Door (Node:4 Probe)”. I made several attempts to try to get this to register properly in Home Assistant so I can be notified when the door is opened. You can see several Entities of this node in the screen shot here. Which one do I need to be using for my Automation? I tried several different…

Aeotec ZW089 Recessed Door Sensor Gen5

I’ve seen several older threads about this but nothing recent or definitive. Has anyone got these to work properly? I have a binary sensor for them, but it just shows “on” all the time no matter what. I can see the Basic Set value changing from 255 to 0 and back when I apply the magnet, but as HA doesn’t pick that up it’s useless.

[richardtallent]

Thanks @Bartem!

This device’s model number is ZW187-A.

I feel like I’ve missed a critical part of understanding the relationship of whatever “Open Z-Wave” is to Home Assistant.

I’m using the core Z-Wave Home Assistant integration.

I know there’s another integration called Open Z-Wave (which has, on GitHub, some XML code related to this door sensor), but I was under this impression that “Open Z-Wave” is some sort of experimental alternative protocol and/or firmware, and that this integration (which is still in beta) uses that protocol, but also requires having an MQTT broker set up (I don’t) and yet another background process running (“ozwdaemon”), which has its own web-based UI separate from HA.

Adding to the confusion, the core HA ZW integration (which appears to be completely unrelated to the aforementioned “Open Z-Wave” integration or daemon) calls its log the “OZW” log. sigh

That first thread looks like it’s also specific to this separate OZW tool.

The second thread starts to sound like it’s relevant to me, but then it also starts referring to “enabling parameters” – a concept I didn’t run across until just now, and just read up on.

I see the “Node Configuration Options” panel in the Z-Wave integration config, but the Configuration Parameter drop-down has no choices – so there’s no “121” as the second thread suggests. I checked this for all three door sensors (two installed, one sitting here on my desk). Woke up the one on my desk, did both “test node” and “refresh node,” and the parameter list is still empty.

Incidentally, I am seeing the sensors change state in the OZW log to open and to closed (Access Control Event Type 22 and 23, respectively), so I’m fine with just writing a template sensor to decode this into something more useful, I’m just trying to understand the best way to set these things up so they appear, by default, in the most sensible way in HA. Especially since the next step will involve more door sensors and four new smoke/CO detectors, which I’m hoping to install this weekend, if we don’t lose power due to yet another hurricane landing tomorrow…

[freshcoast]

@richardtallent

I feel like I’ve missed a critical part of understanding the relationship of whatever “Open Z-Wave” is to Home Assistant.

OpenZWave (OZW) is the C++ library that interfaces with your Z-Wave USB controller. As a C++ library it can be used in multiple applications. It is the same driver behind the zwave integration and the openzwave integration.

The zwave integration use a python wrapper around the C++ API and is embedded in the hass process. This also means the Z-Wave network is started and stopped at the same time HA is. It uses an obsolete version of OpenZWave that has ceased being supported.

The openzwave integration requires a remote daemon process (can be installed on the same host or a remote one) that HA interfaces to using MQTT. Being a remote process, the z-wave network remains running while HA restarts. It uses an up-to-date version of OpenZWave.

Yes, the naming is a little confusing, but they are both related to OpenZWave the library.

That first thread looks like it’s also specific to this separate OZW tool.

That thread is related to the zwave integration. It references a very old web-based tool (OZW Control Panel). No relation to the openzwave integration besides using the same C++ library.

The second thread starts to sound like it’s relevant to me, but then it also starts referring to “enabling parameters” – a concept I didn’t run across until just now, and just read up on.

I recommend browsing the extensive z-wave docs, which would explain this and more.

I see the “Node Configuration Options” panel in the Z-Wave integration config, but the Configuration Parameter drop-down has no choices – so there’s no “121” as the second thread suggests.

Your ZW187 is a different product than the ZW089. Naturally, different products may not have the same configuration settings (turns out that the parameter 121 is parameter 1 for your device). Since you are using an obsolete version of OZW, it doesn’t have any knowledge about your device including the name and configuration parameters. The XML file you found is used by the current version of OZW, but not by the old version.

Incidentally, I am seeing the sensors change state in the OZW log to open and to closed (Access Control Event Type 22 and 23, respectively), so I’m fine with just writing a template sensor to decode this into something more useful

The docs provide examples for that. Having to write these templates was a pet peeve of mine. Luckily, in the openzwave integration this is done automatically for you.

[freshcoast]

@freshcoast

Since you are using an obsolete version of OZW, it doesn’t have any knowledge about your device including the name and configuration parameters.

You can, however, still use the service call to set configuration parameters.

zwave.set_config_parameter with service data

node_id: 4
parameter: 1
value: 1
size: 1

Should enable your binary_sensor. The binary sensor is for backwards compatibility. The access control sensor with 22/23 values is the modern implementation for notifications.

[richardtallent]

Thank you, this is a perfect explanation!

I’m a CS-degreed full-time software developer (and have been for over 25 years), but this is a whole new world, and I’m learning it in 15-minute chunks of time between work, family, etc.

I read the docs you linked (that’s where I found the info about Configuration Parameters, under the Control Panel page), but it didn’t explain any of the above.

I had not run across that doc example yet about the open/closed door sensor template.

Sounds like running the daemon and MQTT separately would be a bit more work but might provide a better OOTB experience as I add new sensors… unless the core integration will be upgraded soon to use the newer OZW library?

If going through the setup of another few docker containers for ozwdaemon and mosquitto makes installing these new smoke detectors (and additional door / IR / etc. sensor) easier, I may bite the bullet rather than going the template route.

I just found another article that goes into some related detail on the history and how to set up OZW separately, so I’m pasting it here for my own reference or anyone else who might run across this thread:

New OpenZWave (beta) for Home Assistant - Self Hosted Home

[freshcoast]

The zwave integration is no longer being worked on by the core developers. If you submit PRs they probably would get accepted. I presume eventually it will be deprecated, but I wouldn’t expect that anytime soon. The last commit of the official OZW 1.4 release was over 2 years ago, it’s EOL. There is no migration path to OZW 1.6 for the Python wrapper.

That article is a pretty good write up of the OpenZWave integration, and mostly still relevant. There are still issues with dimmers that need to be addressed, as the author observed, but RGB bulbs are fully supported.

I recommend using the new integration especially if you’re just starting out brand new. Just be aware that there are issues here and there. In my specific case, I have zero problems with ozwdaemon, it works nearly perfect for my needs. Others, especially with large networks, have seen problems.

If you plan on having any switches and are using your own docker container, I would stick to the build-150 docker image tag as the newer images have issues. If no dimmer/bulbs, the latest images are fine. The desktop ozw-admin application is much easier to use than the embedded VNC client, so you can skip the allinone image unless you are fine with the small resolution of the embedded one.