Closed restauffer closed 10 months ago
Post a serial log so we can see what's going on when the door is triggered.
Paul,
When I went to pull the logs, the problem was no longer occurring. I am sure it was occurring yesterday as I did quite a few different attempts to get it to work. I tried various attempts to recreate the issue but no matter what I tried, it still worked. I guess we'll take that as good news but it leaves a nagging worry that the problem still lurks but needs some certain sequence of events to make it manifest.
BTW, I did pull log files and they showed that it recognized the door was already open:
3A5D 3900 3A5D QUEUE MSG ARRIVED [home/garageratgdo-1/command/door] open MQTT: open the door 3855 | door state: 55 1010101 3031 31EE 3A4D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 Door state opening QUEUE MSG SENT [home/garageratgdo-1/status/door] opening 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3801 | door state: 1 1 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D 3852 | door state: 52 1010010 Door state open QUEUE MSG SENT [home/garageratgdo-1/status/door] open 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D 3852 | door state: 52 1010010 3A5D 3900 3A5D QUEUE MSG ARRIVED [home/garageratgdo-1/command/door] open MQTT: open the door The door is already open 3852 | door state: 52 1010010
If the problem occurs again, I will report it.
Thanks for all your work on Ratgdo and Happy New Year.
Ricke
I am using a 2.5 board with V2.56 firmware with a sec +1 GDO and an LM889 panel running MQTT firmware.
The "open" command is working like a toggle when used in an HA automation. Assuming the door is physically closed, the first open command opens the door as expected. If, while the door is still open, the open command is again issued, the door closes. You can again issue open and it will open again. Yet another open command will again close the door.
FWIW, the "close" command seems to be working properly.
I have created a work around in the automation in question by making the open command conditional on the door status being closed but think the current function of the "open" command may have a bug.
Another workaround I tested is to use the services "cover: open" and "cover: close". These two also do not toggle.