search

ratgdo / mqtt-ratgdo

ratgdo via mqtt
GNU General Public License v2.0
76 stars 16 forks source link

MQTT status of "stopped" is misinterpreted by Home Assistant #14

Closed joeshaw closed 7 months ago

joeshaw commented 7 months ago

This might be related to #12. I've been seeing some spurious door status changes, using a ratgdo v2.5 with the MQTT firmware with a Security+ 1.0 opener. Here's what I see on the MQTT topics:

2023-11-28T11:25:01-0500 ratgdo/status/door stopped
2023-11-28T11:25:01-0500 ratgdo/status/door closed
2023-11-28T12:59:45-0500 ratgdo/status/door stopped
2023-11-28T12:59:46-0500 ratgdo/status/door closed

And here is how Home Assistant interpreted it:

image

And because I have the opener bridged into HomeKit I get notifications about the door being opened when it really wasn't.

I'm not sure if this is something to be fixed on the ratgdo MQTT side or the Home Assistant side (or both), but it seems like "stopped" status messages are triggering the wrong state in HA.

joeshaw commented 7 months ago

Relevant HA MQTT cover code here: https://github.com/home-assistant/core/blob/595663778cfe971ba4f15a3da584cc3d401a1531/homeassistant/components/mqtt/cover.py#L375-L383

ratgdo doesn't currently set a position_topic in its config, so the HA behavior is to set it to STATE_OPEN unless the previous state was STATE_CLOSING, which it isn't in my case. This doesn't seem like the right fallback to me, and I may open an issue against HA to change that to ignore stopped if it's already STATE_OPEN or STATE_CLOSED. Update: filed https://github.com/home-assistant/core/issues/104667

I don't know if it's possible for ratgdo to support position_topic but that would probably be a good way to address this from its side.

joeshaw commented 7 months ago

They've fixed the misinterpretation of "stopped" upstream in https://github.com/home-assistant/core/pull/104726, so I'll close this. Should I open a separate issue for the "stopped" messages? I also see "closing"+"closed" messages sometimes when the door is already closed. For example:

2023-11-29T07:59:31-0500 ratgdo/status/door closing
2023-11-29T07:59:41-0500 ratgdo/status/door closed
2023-11-29T08:04:10-0500 ratgdo/status/light off

2023-11-29T11:17:05-0500 ratgdo/status/door closing
2023-11-29T11:17:05-0500 ratgdo/status/door closed
2023-11-29T11:21:13-0500 ratgdo/status/door closing
2023-11-29T11:21:14-0500 ratgdo/status/door closed

The messages before the line break are legit.

lukescott commented 6 months ago

@joeshaw So the fix upstream on home-assistant fixes the constant notification issue? In regards to closing/closed, I've noticed my notifications seem to happen during evenings/nights when it's particularly cold. I wonder if a temperature change could cause the door to move slightly and make ratgdo think the door has moved.

joeshaw commented 6 months ago

@lukescott It improved the situation but didn't fix it outright. I haven't had the ability to attach a serial console to see the messages to the ratgdo, but I suspect there's something happening there that's triggering the MQTT state change messages.

PaulWieland commented 6 months ago

Just so everyone is aware - ratgdo only does what the GDO tells it. The door opener is streaming these status updates over the serial control line and ratgdo is reporting what it hears.

These state changes have always been there, but we didn't know about it because we weren't monitoring it.

joeshaw commented 6 months ago

There are probably some status changes that don't make sense to report, like going from "closed" to "closing". But it's not clear to me what layer we should filter these out (ratgdo-mqtt or home assistant or elsewhere?) if at all.

lukescott commented 6 months ago

@joeshaw I'm curios on what causes it. I have two garage doors, and at least in the past 24 hours, one of my doors it happened 3 times between 8 PM and 4 AM. My other door it only happened once around 2 AM. During the day it doesn't seem to happen at all. So I'm wondering if it has to do with some type of thermal expansion/contraction. I'm not sure how to go about testing that though.

PaulWieland commented 6 months ago

There are probably some status changes that don't make sense to report, like going from "closed" to "closing". But it's not clear to me what layer we should filter these out (ratgdo-mqtt or home assistant or elsewhere?) if at all.

The update stream is relatively fast. I will look into having it only report status changes when two consecutive matching packets are received. This will slow down status updates slightly, but it will also cut down on false reports and so it might be a worth while trade off.