I have several of these sensors and they have been included and updated fine with ZwaveJS.
But I just tried to add two new ones and though they seem to include OK they none of their states like tamper protection or open/close update once included. The door sensor always reads closed and the tamper protection always shows safe even with the cover off.
The sensor is sensing the door open/close because the LED is blinking when the reed switch is opening/closing.
The only thing I’ve changed is updating the ZwaveJS add-on to the latest version that dropped a few days ago.
As a test I took a look at the disabled entities for the old binary_sensor entities and as a test I re-enabled all of them (binary_sensor.z_wave_door_window_sensor_any, etc). As soon as I did that all of the sudden the binary_sensor.z_wave_door_window_sensor_access_control_window_door_is_open entity that was created and enabled by default on inclusion started working.
After disabling the disabled-by-default legacy binary_sensor entities the new entity continues to work.
So there definitely seems to be some kind of bug with how ZWaveJS handles these devices on inclusion.
I’ve had a bunch of these sensors working fine for years. Yesterday I decided to try excluding/reincluding one of them with the new zwavejs, just to see how things went. Unfortunately, now the tampering sensor stays on after the cover is opened, and no longer turns back off after the cover is replaced. So I have to reset the state manually in dev tools. Everything else is working as expected.
Not sure if this was done by design or a bug. I imagine use cases where you may want the state to remain until you get a chance to physically inspect the device. However in my case I prefer the sensor to reset itself immediately after the cover is replaced.
Has anyone got any further on this apparent bug in zwavejs?
[Aha, it appears there may already be a fix waiting in the zwavejs pipeline for this…
The description includes “Auto-idle notifications for Ecolink DWZWAVE25”. All my other ecolink door sensors that I haven’t reincluded with zwavejs (so they still work properly with the original zwave integration)… have the tampering notification set to “IDLE” when the cover is on. I’m guessing the next core update will include these changes to the zwavejs integration… [fingers crossed] this issue should go away after that is released.]
I have a similar problem with the Ecolink DWZWAVE25. I am using the Zwave JS to MQTT add-on. Every time I restart home assistant, all my ecolink sensors show like this: binary_sensor.XXX_home_security_tampering_product_cover_removed.
I can reset them in Developer tools, but they still show as [3] Tampering, product cover removed in the Zwave JS to MQTT UI. I have attempted to write an automation using “Call service” “zwave_js.set_config_parameter” with the parameter given by UI (I tried with the name or number) but I get “Configuration parameter with parameter name 19-113-0 could not be found” in the trace. I’m thinking there might be a way to get MQTT to do something, but I don’t know what topic or payload to publish - yes, I AM that dumb. Here’s a screenshot that might help if someone wants to assist , has a similar problem, or has solved a similar problem:
