Have connected the Blaq controller to my Australian Merlin MS105MYQ via Home Assistant. All functions appear to work ok with the exception of reporting the status of the obstruction sensor.
If I block the sensor, the motor responds as I expect and prevents the door from closing, or reverses the closing motion if it is already in action. However the status of the instruction sensor still shows OK in Home Assistant.
If I check the Blaq logs both direct through the web interface and via the ESPHome Builder app in Home Assistant, it doesn’t appear to report or sense any change in status.
A few other quirks that I’ve noticed after living with the GDO Blaq for a week:
The Merlin unit has its own remote activation warning system and will flash the light 4 times before activating. What happens is the GDO Blaq activates it’s warning lights and sirens for 5 seconds before triggering the merlin to close. Home alert and the GDO Blaq logs show the door open percentage reducing and the door closing, but the door has yet to move or commence closing as the motor is still flashing the light.
The percentage open doesn’t seem to correspond to the actual travel of the door. For example if I set it to open to 20%, it only opens a fraction of the way.
It appeared to record every opening regardless of whether it was triggered by the GDO Blaq or another remote. However, in the last 48 hours it appears to be losing track every couple of hours. The GDO Blaq shows that it is synchronised, but it’s not reporting the status of the door changing when the motor is activated by a remote, and the door is not responding to commands. Resyncing appears to fix the issue.
I have two of the exact same Merlin motor and my experience has been identical to yours. Also on most recent revision of esphome project. However in my case the motors become desynchronised frequently, where they don’t report activity and can’t be triggered. From the esphome logs, the following is what I see when triggering the motor from the standard Merlin radio remote.
[20:17:33.997][D][esp-idf:000][gdo_main_task]: E (2061873324) gdolib: RX data signature error: 0x3e0030
[20:17:34.000][D][esp-idf:000][gdo_main_task]: E (2061873324) gdolib: RX buffer read error, 6 pending messages.
[20:17:34.003][D][esp-idf:000][gdo_main_task]: E (2061873324) gdolib: RX buffer read error, 5 pending messages.
[20:17:34.006][D][esp-idf:000][gdo_main_task]: E (2061873324) gdolib: RX buffer read error, 4 pending messages.
[20:17:34.009][D][esp-idf:000][gdo_main_task]: E (2061873324) gdolib: RX buffer read error, 3 pending messages.
[20:17:34.069][D][esp-idf:000][gdo_main_task]: E (2061873325) gdolib: RX buffer read error, 2 pending messages.
[20:17:34.073][D][esp-idf:000][gdo_main_task]: E (2061873325) gdolib: RX buffer read error, 1 pending messages.
[20:17:34.795][D][sensor:118]: 'Heap Free' >> 152404 B
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878399) gdolib: RX data signature error: 0xce3e0e
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878399) gdolib: RX buffer read error, 6 pending messages.
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878399) gdolib: RX buffer read error, 5 pending messages.
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878399) gdolib: RX buffer read error, 4 pending messages.
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878399) gdolib: RX buffer read error, 3 pending messages.
[20:17:39.087][D][esp-idf:000][gdo_main_task]: E (2061878400) gdolib: RX buffer read error, 2 pending messages.
[20:17:39.094][D][esp-idf:000][gdo_main_task]: E (2061878400) gdolib: RX buffer read error, 1 pending messages.
[20:17:42.159][D][esp-idf:000][gdo_main_task]: E (2061881469) gdolib: RX data signature error: 0x3ecec0
[20:17:42.159][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 8 pending messages.
[20:17:42.159][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 7 pending messages.
[20:17:42.159][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 6 pending messages.
[20:17:42.159][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 5 pending messages.
[20:17:42.193][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 4 pending messages.
[20:17:42.193][D][esp-idf:000][gdo_main_task]: E (2061881470) gdolib: RX buffer read error, 3 pending messages.
[20:17:48.302][D][esp-idf:000][gdo_main_task]: E (2061887620) gdolib: RX data signature error: 0x0ece3e
[20:17:48.306][D][esp-idf:000][gdo_main_task]: E (2061887620) gdolib: RX buffer read error, 2 pending messages.
[20:17:48.306][D][esp-idf:000][gdo_main_task]: E (2061887621) gdolib: RX buffer read error, 1 pending messages.
It would be great to receive some guidance on how to debug this. I’d like to be able to log the raw data received, to determine how it’s different when it’s working versus when it’s unable to decode incoming messages.
And separately, it would be great to be able to increase resilience by sending a ping (GDO_CMD_PING?) on a regular schedule—assuming that pings “fix” the state like toggling the light appears to.
But that should only come after we work out why the messages are not being parsed correctly, whether it’s a problem with the library or the motor itself.
I’ve found the problem. There’s a bug in the UART reading code. If an incomplete packet ever arrives, the fragment sits in the buffer and is tacked onto the start of the next complete packet. So instead of reading [COMPLETEGOODPACKET] it combines the old bad packet with the new good one.
That would have been fine. One extra packet gets mangled, 99.9% of the time it’s a status pulse anyway.
Except it doesn’t do that. It only reads the length of one packet BADPACKET][COMPLETEGO and the remainder ODPACKET] is retained, sitting in the buffer, waiting to ruin the next incoming packet. This cycle repeats ad infinitum.
In case anyone cares, I have posted a fix onto a github branch. I made a very elaborate fix which resynchronises whenever it sees bad data, but also tries to rehabilitate the faulty data (“fancyfix” branch). This has been working great on my Merlin motors for 12 days running.
I also implemented a bare minimum fix which does a resync-on-bad only. 99.999% of the time the bad data is just an idle ping, so it’s probably a Good Enough™ solution. But I haven’t run this version for more than a few hours so I have no idea if it actually works. I’ve put it on one of my two blaQ controllers and I’ll report back.
Needless to say I haven’t tried this on anything other than my own Australian market Merlin MS105MYQ with Konnected blaQ controllers. YMMV.
As a courtesy I posted my analysis of the issue into that ratgdo bug report, and in return, my post was edited by the maintainer of that project to remove key information. He declared the issue already fixed due to a “complete rewrite of the serial interface”, but when someone in the EU pointed out that it didn’t fix the problem, he implemented the exact same workaround I suggested, deleted my posts, and banned me from his github project.
Is there something I’m not aware of about ratgdo? This sort of behaviour doesn’t come out of nowhere.
Anyway, that was fun. My front and rear motors have been absolutely rock solid for three weeks now using both branches.