secplus 1 GDO can be unreliable if power cycled with RATGDO

[p-jean]

Hardware: v2.5 Firmware: https://github.com/PaulWieland/ratgdo/blob/main/docs/flasher/ratgdo_esp8266_hV25_sV2.51.bin

Problem seen: 1) Door opens (and re-opens if closed) by itself 2) Door status in HA is unreliable/incorrect

Resolution: Disconnect RATGDO

How to cause:

• power off GDO and RATGDO
• wait 30s+
• Power on GDO and RATGDO simultaneously.

Frequency: Seen once incidentally, then reproduced in 1 of 2 tries.

System: 8500C + wallpanel + keypad

Notes:

• Serial bus has many framing and parity errors
• Disconnecting RATGDO stops the errors

[PaulWieland]

You probably sent a retained mqtt command message to ratgdo. watch your serial log or the mqtt broker log. retained messages are sent whenever a subscriber comes online.

[p-jean]

Originally all is well, door is closed, and MQTT is stable. After a power cycle, the door opens by itself, a few minutes later. Is there any reason for MQTT to open the door?

I can close the door via HA and it opens again after some time.

Surely the framing errors and parity errors are playing a role? These are not seen normally.

I'd like to see the logs, but it will be a challenge (not impossible) to get them: 1) Unit is high up on the wall in the corner 2) RATGDO will not power-cycle at the same time as GDO when connected to the laptop 3) Can I power cycle RATGDO and see the early logs, or do I need to re-connect to COM port first?

[dbrewer-wdc]

Yes, there is a reason for MQTT to open the door. As Paul stated, if you send a door command via MQTT and it is "retained", this is an option for when you send the command, then when the Ratgdo reconnects with the MQTT broker, it will see the command and treat it as if it is new. The Ratgdo software will check if the current status matches the command before executing. I.E. if the door status is closed and a close door command is received, then it will not act on the command. But if the Ratgdo was power cycled, its initial door state could be "unknown". So check that you are not setting the retained bit in your door commands. I use Node Red with Homeassistant and retained was default on.

[PaulWieland]

The latest release ignores mqtt commands that are received within X seconds after ratgdo connects to wifi/broker.

[p-jean]

Thanks. I’ll try the new version.

I have been using Home Assistant with the cover card:

[p-jean]

The problem is still happening with version 2,54. The reason appears to be that the RATGDO is entering emulation mode. Please re-consider making emulation mode into a configurable option (bug #19)

emulation_mode.log

[gullygossner]

Yes, there is a reason for MQTT to open the door. As Paul stated, if you send a door command via MQTT and it is "retained", this is an option for when you send the command, then when the Ratgdo reconnects with the MQTT broker, it will see the command and treat it as if it is new. The Ratgdo software will check if the current status matches the command before executing. I.E. if the door status is closed and a close door command is received, then it will not act on the command. But if the Ratgdo was power cycled, its initial door state could be "unknown". So check that you are not setting the retained bit in your door commands. I use Node Red with Homeassistant and retained was default on.

When you say that node red has retained messages on by default, are you referring to the mqtt node ? I'm fighting the same issue and would really like a solution.

[dbrewer-wdc]

I don't have access to my home assistant /node red system, but for sending MQTT commands to a topic in node red, there is a checkbox for "retain". For the door command, that needs to be off, and probably should be off for other commands; however, Paul updated the code to ignore retained commands. There could be other reasons for this too. If you are using dry contacts to control the door, a reset could cause the door to toggle.