Door sensors change state by themselves

Hello,

When my door sensors wake up, they sometimes update to wrong state by themselves, eg. door is closed but the state changes to open. It stays open until the door is opened and closed again. From doing some experimenting I have discovered that:

  • happens every time I manually wake the sensors
  • happens sometimes when they automatically go through their wakeup period
  • the state they change to is always the same, so it seems they kind of “reset” to this value

The sensors are Fibaro FGK-101 and Sensative Strips. Main controller is Aeotec Z-Stick Gen5. These are my only devices as I have just started to experiment with Z-Wave.

Since this happens with two different sensors (=all my sensors), I’m guessing it must be a setup problem somewhere? Anyone heard this happen before?

Will post detailed configs and logs on request.

1 Like

If I had to take a guess, I would bet that you’re reading a value that isn’t reporting the close state of the door, but instead reporting the sleep state or some other state of the device.

For example, my FIBARO motion sensors do not update the sensor.fibaro_system_fgms001_motion_sensor_alarm_level_2_1 correctly. Instead I have to use the sensor.fibaro_system_fgms001_motion_sensor_burglar_2_10 values and do some trickery in the config to detect if the state is the following.

0 = No Motion
8 = Motion
3 = Tampered (Moved)
254 = Deep Sleep Mode

Did some more research and these are all the entities which react when the switch state is changed using the magnet:

** FGK-101 **
sensor.fibaro_system_fgk101_door_opening_sensor_access_control_8_9:
22	When switch is opened
23	When switch is closed
254	After device wakeup*
sensor.fibaro_system_fgk101_door_opening_sensor_general_8_0: 
0	When switch is closed
255	When switch is opened and after wakeup*

** Strips **
sensor.sensative_strips_access_control_9_9:
22	When switch is opened
23	When switch is closed
254	After device wakeup*

*Always with manual wakeup, sometimes with automatic wakeup (wakeup period)

So apparently they do both have unique values for open/closed states within the access control entity. Basically I’d need to ignore value 254 and assume the state is still whatever it was before this value. Not sure how this’d be done in Grafana for example, but maybe it can be done.

Are we really supposed to try and guess how the devices work (ie. what the different values and entities mean)? I find it puzzling that these are not stated in the manual or in the Z-Wave product finder.

2 Likes

Just wanted to update that I have reached out to both vendors about the unknown values. Fibaro replied with their user manual even though I had explained it doesn’t contain this information. I reminded them about this, and haven’t heard from them ever since :unamused:

With the Strips I can change the notification type to binary and in this mode the sensor works just as expected without any additional values. I’d still like to know why the notification report mode works as it does though, so I’ll update here once they reply.

So apparently they do both have unique values for open/closed states within the access control entity. Basically I’d need to ignore value 254 and assume the state is still whatever it was before this value.

I realised this is still problematic after HA is restarted, because in this case I cannot know if the door state has changed while HA was off.

Sensative actually replied promptly, but I got busy with other stuff for a while. Their answer:

We like to inform you that when a Gateway sends to the Strips an “Alarm Get” request, which is an unsupported request, the Strips responds with 254. 254 means “unknown”.

I’m guessing I should take this to the Open Z-Wave project, since the value is seen in the OZW_Log?

Fibaro stopped replying to me altogether.

2 Likes

That’s worth doing because if they address that it’ll fix it for all platforms using OZW, not just HA.

@github-0 Did you take it to the Open Z-Wave project? Could you post the issue link or a reference? I have the same problem.

I really thought I did, but can’t find it anywhere so I guess I didn’t :frowning:

Not really sure if this or this is the right place?

I’ll add it at some point if you don’t.

@github-0 I think maybe a post to their google group first would be best, as I’m not sure if this constitutes a bug or not. What do you think?

https://groups.google.com/forum/#!forum/openzwave

If you would like to post the question there, I’ll gladly follow up with a “me too” or with more information.

By the way, I just configured the strips to “binary sensor reporting”, and I think it looks better than using a template and checking for the Access Control value with an if-then-else it is 22.

From the HA developer tools, I called the z_wave “set_config_parameter” service with this JSON: ‘{ “node_id”: “7”, “parameter”: “1”, “value”: “0”, “size”: “1” }’ where my sensative strips is node 7, yours will probably be another.

Now it works with the default binary_switch feature.

Now, the Access Control value always says 254, which means “unknown”.

2 Likes

Hi,

i’m sorry but i don’t understand how to do…
I wish see on my frontend if my window is opened or closed (“just” this).
I’ve got a template sensor which watch the value of access_control (if state =23 -> closed ; else -> open), but my value switch quickly from 22 or 23 to 254, until I open manually.

did you find a solution ?

thank you !!!

Hi, Will! It sounds like you haven’t configured the strips to “binary sensor reporting” (see my above answer). If you do this, you will not need that template, instead you will get a new entity which is on/off. See my above answer for instructions. If they are unclear, please explain to me which part is unclear. Hope you make it work! Mine have been working flawlessly since I configured them to “binary sensor reporting”.

Has anybody solved this? I’m having the same issue with all my sensative strips. :frowning: They are all reporting in binary sensor mode.

See t hi is thread it’s a bug with the strips software since they updated mine I’ve had no issue