AUS - Merlin MS105MYQ - Blaq Obstruction Sensor Not Reading in Home Assistant

Konnected Garage Door Opener
, ,
1

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.

2

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.

Using firmware 1.5.7.

3

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.
4

I’ve set up an automation in HA that turns the light on every for 2 seconds every 2 hours and that seems to retain the sync.

Still having the other issues with the percentages wildly out and obstruction sensors not registering in HA.

5

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.

6

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.

7

Looks like a similar problem has been cited by ratgdo users, with no solution posted

1 Like
8

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.

[COMPLETEGOODPACKET]
[COMPLETEGOODPACKET]
BADPACKT][COMPLETEGO
ODPACKET][COMPLETEGO
ODPACKET][COMPLETEGO
ODPACKET][COMPLETEGO
ODPACKET][COMPLETEGO
ODPACKET][COMPLETEGO
ODPACKET][COMPLETEGO
9

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.

Replace the lib_deps: with my branch, like so:

esphome:
  platformio_options:
    lib_deps:
      - https://github.com/sjwright/gdolib#simplefix

esphome:
  platformio_options:
    lib_deps:
      - https://github.com/sjwright/gdolib#fancyfix
1 Like
10

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.

11

Who knows. How does what ratgdo do with their code impact what Konnected does (is their code base part of what Konnected implement on the Blaq)?

I’m more concerned about the lack of any commentary or response in this thread by any of the Konnected staff and how they intent to implement a fix.

12

Adding that I am seeing the same behaviour as Kesawi with the same opener.

13

@kesawi @Simondotau @akum036 First of all, let me sincerely apologize for allowing this issue to slip through the cracks. I try to stay on top of these community forum discussions, but somehow this thread missed my radar until recently when someone pointed this out to me via a support ticket that was escalated my way.

Thanks to your reports, and particularly @Simondotau’s investigation, I’ve confirmed an issue/bug with the way the blaQ handles line noise or dropped packets. Basically exactly what you described in your March post above. I have no idea why this seems to only manifest on the Merlin openers. That nuance made it really tricky for us to track down.

@Simondotau I’ve sent you a AUD$ 150 store credit toward your next Konnected purchase for your efforts here in identifying the bug and potential fix! I totally appreciate the help and sharing and transparency. And thank you for being a loyal Konnected customer for more than 5 years!

Anyway, a fix is up for review here: gdolib PR #36

I have tested this locally, but I would love for at least one or two of you with the affected Merlin units to test it as well to ensure that it resolves the problem. If you are managing your GDO blaQ firmware via ESPHome Builder, you can test the firmware fix by adding this to your device’s YAML config and re-compiling/installing:

# TEST: gdolib Security+ 2.0 RX resync fix (konnected-io/gdolib PR #36)
# Remove this block to return to the stock gdolib version.
esp32:
  framework:
    components:
      - name: gdolib
        source: https://github.com/konnected-io/gdolib
        ref: fix/v2-rx-resync

If you are using the Konnected app to manage your firmware, please DM me your device ID and project version, and I will prepare a test build for your device with the fix.

14

Thanks @nate ! I’ll test asap and report my findings.

15

Have uploaded the fix and will also report back.

Any comment on the other quirks I’ve notice:

  • Obstruction sensor not reporting state in home assist
  • Travel percentage not corresponding to the actual travel of the door
16

This one I don’t really know and I can only assume that there is some difference in the data in the way that the Merlin models communicate the obstruction status from the North America models that we developed with. My understanding is that in Australia the IR beam hardware is sold separately and optional, is that right? I wouldn’t be surprised if they communicate different signals.

We probably just need to get a live capture of what the packets look like on this this model. It probably speaks a slightly different dialect, and once we know that we can support it better in the firmware.

That’s where I could use some help since I don’t have access to a Merlin model here. With Claude Code now this is pretty easy for many people to do. Clone gdolib locally, run claude in that project, and ask it to build a live capture firmware so you can capture the obstruction sensor data. I already have a CLAUDE.md and documentation in that project that teaches the AI how to do this. You may need to also provide it your firmware config YAML so it can build a couple firmware variants with verbose debugging. Claude will actually update the code, build the firmware, upload it to your device, and walk you through waving your hand thru the sensor and capture the data.

If anyone tries this please share what you find.

The door position percentage is based on timing how long it should take for the door to fully open and fully close. the most common reason that this is off is if the timings are off. Press the reset door timings button on the blaQ’s web page, then fully open and fully close the garage door. It will capture the timings from that cycle.

17

No need to apologise when the source code is open.

I’ve installed it on my second garage door 24 hours ago and so far everything is working fine. IIRC the symptom sometimes took a day to show up so I’ll keep my eye on it, but I’m already confident that your fix is solid.

It’s honestly just a coincidence that in my previous house I had a Bosch alarm panel, and in my current house I have two Merlin GDOs.

18

It’s been a while since I delved into it, but my recollection is that the motor didn’t send any packets at all corresponding to detections by the safety sensor.

I suppose it could be possible to read the sensors directly, electrically, but that would require someone with a modicum of electrical engineering knowledge to detect how the sensor transmits and how to jack into that signal without disrupting it for the GDO. (The emitter and detector sit on opposite sides of the garage door, each have two wires, and both connect to the same two terminals. This means that a single pair conductors is handling power and signal.)

Maybe I’ll see if AI knows.

20

Thanks Nate, I took you up on the live capture. Short version first, details and data below. All captured data is from the main door (IR beams fitted); my second door is described under “Two doors” below. Times are AEST, and “device t” means the ESP’s own millisecond clock. The post has largely been generated by Claude AI.

Setup

  • Merlin MS105MYQ (AU), Security+ 2.0, IR beams fitted. blaQ project 1.6.2, ESPHome 2026.9.1, HA 2026.9.4.

  • gdolib at PR #36 (fix/v2-rx-resync, 4110dca) plus log-only additions: every received and sent frame, errors, resyncs, door and obstruction state changes, with device timestamps. Built following docs/live-capture-workflow.md; no behaviour changes. I’ve since rolled the door back to the build I was running before.

  • Two sessions on 5 Oct (about 14:25 to 15:48): beam blocks (door closed, open, closing, rapid waves), full open/close from the wall button and from HA, and stops/reversals mid-travel. I noted each action by wall clock and matched it to the frames.

Two doors, set up differently

Main door (this capture) Small door
Opener Merlin MS105MYQ MT100EVO
Protocol Security+ 2.0 Security+ 2.0
IR beams Fitted None
Toggle-only Off: discrete open, close and stop On (set because it has no beams): a single toggle
Close from HA The Merlin runs about 7.4 s of its own warning before the door moves Starts moving straight away (my observation, not captured)
Position tracking Drifts on closes (see below) Tracks cleanly
Obstruction Works (see below) n/a, no beams

Both run blaQ 1.6.2, ESPHome 2026.9.1 and the same gdolib PR #36. I’m happy to run the same capture on the small door for a comparison, just not in this session.

Obstruction: reports correctly in HA

  • The Merlin reports it in the STATUS frame: byte1 is 0x68 when clear and 0x28 when the beam is broken. I saw no OBST_1, OBST_2 or PAIR_3_RESP frames (the secplus_gdo component sets obst_from_status = true).

  • Every trip was followed by a clear: 5 s blocks, 1 s blocks, a block while closing, and two sets of 5 rapid waves (all 10 trips and clears reported). Frames arrive within about a second of the physical break. I didn’t see the ~4.4 s STATUS lag mentioned in the gdolib comments.

  • Beam broken while closing: the Merlin switches to “opening” 1.0 s and 1.2 s after the beam frame (two runs).

  • One thing I can’t interpret: byte2 bit 0x04 goes high with the first beam break. With the door closed it clears with the beam; with the door open or moving it stays set until the door’s next state change.

  • Was it 1.6.2? My InfluxDB history shows this entity existing from 22 Aug on project 1.6.0, writing “off” at each boot but never changing to “on” over the ~10 days I was crossing and testing the beam. I updated to 1.6.2 on 1 Sep, and it started changing state within hours (first event 1 Sep 18:36). So I suspect 1.6.2, not the resync fix, is what made it work. 1.6.0 only gave it an initial state.

Travel percentage: the Merlin’s pre-close warning gets learned as travel

Time between the Merlin’s “opening”/“closing” frame and its “open”/“closed” frame (device clock):

Move Button/remote HA command
Full open 15.1, 15.1, 16.1 s 15.1, 16.1, 16.1 s
Full close 18.1, 18.9, 19.1 s 26.1, 26.1 s
Close after a stop (about 26 to 33% open) n/a 13.0 s, 15.0 s

Opens are identical either way. Closes from HA take 7.4 s longer (6.95 to 7.97 s across the full closes; the two partial runs, compared against my partial button closes, give 7.1 s and 8.0 s). The sequence on an HA close is: blaQ alert (2 s), command sent, the Merlin sends “closing” about 1 s later and runs its own warning (flashing light), and the door only starts moving about 7 s after that frame. Nothing marks the start of movement: in all four HA closes the opener’s rolling code advances by exactly 1 between the “closing” and “closed” frames, so no frames are sent in between, and the STATUS bytes don’t change when the door starts. My guess is that the Merlin applies the warning to discrete close commands from the bus and not to button presses, which would also explain the small door, where toggle-only means there is no discrete close.

What I see in gdolib’s behaviour:

  • The cover entity reaches “closed” 5 to 6 s before the Merlin’s closed frame (15:43:46.1 vs 15:43:51.5, and 15:45:27.3 vs 15:45:33.2).

  • The position updates imply a stored close time of about 27 s, against about 19 s real. From my reading of update_door_state(), durations are measured between the closing and closed frames, so a close learned from an HA command picks up the warning.

  • Resetting the door timings can’t fix this, because one stored time can’t suit both kinds of close: a time learned from a button close makes HA closes show “closed” about 7 s early, and one learned from an HA close makes button closes lag.

  • Partial moves also have about 1.4 s of start-up time (from my partial button closes, close time is roughly 1.4 s + 17.3 s x the fraction), so a straight 0 to 100% line is a few percent off even with no warning.

A possible change. I think gdolib could calibrate this itself:

  1. A close counts as “ours” if gdolib sent a discrete close within about 3 s before the Merlin’s “closing” frame (in my log the frame follows the command by 0.8 to 1.2 s). Otherwise it’s “external”: button, remote, or the opener’s own timer.

  2. It learns a close time for each kind from uninterrupted open-to-closed travel only, and uses the difference as the delay, only when both kinds have at least two samples and the difference is over about 2 s.

  3. External closes advance the position straight away. For our closes, gdolib holds the start position for the learned delay after the “closing” frame, then runs at the same rate. Opens don’t change.

Setups with no warning, like my toggle-only door, would learn zero and behave as today. Before relying on it I’d want to test pressing stop or breaking the beam during the Merlin’s warning, and closes started by the opener’s own auto-close timer.

Motor: no sign of it

  • HA’s motor entity has never gone on. InfluxDB shows no “on” state for the main door’s motor since I added it on 22 Aug (about 6 weeks of daily use, plus the captures), nor for my second door, which runs in toggle-only mode. Every recorded state is “off”. The blaQ’s own status page also never shows it.

  • Of about 140 decoded frames, every one is STATUS (0x081), the OPENINGS reply (0x48c), or one of our own DOOR_ACTION, LIGHT or GET_STATUS. There is no MOTOR_ON (0x284) and no unknown command number.

  • While the door moves, the only change in STATUS is the door-state nibble (4 opening, 5 closing). byte1 stays 0x68 and byte2 stays 0x02 (light). The Merlin sends one frame when travel starts and one when it ends, and nothing in between.

  • So either this model never reports the motor, or it does so somewhere gdolib doesn’t see (see “What I can’t see” below).

Stops and reversals

  • A stop is reported as STATUS nibble 3 (“stopped”) 0.3 to 0.5 s after a stop from HA, with all other bytes identical to a moving frame.

  • The next press reverses direction: open, stop, then close; close, stop, then open. A close from HA after a stop has the same delay (about 7 to 8 s).

  • The OPENINGS counter ticks only after a full cycle; partial moves don’t count.

What I can’t see (limits of this capture)

  • gdolib reads and discards packets shorter than 19 bytes without logging them. I counted 21 such events since boot (sizes 2, 3, 6, 8, 9, 10, 12, 15, 16, 17), most within about 40 to 115 ms before a state-change frame or around my own transmissions. They could be frame fragments or line noise, but if the Merlin sent anything about the motor in a short message I would never have seen it. A capture that logs those bytes would settle it.

  • Many of my log lines were dropped by ESPHome’s logger (I believe its default task_log_buffer_size of 768 bytes is too small for gdolib’s bursts). The raw RX: frame lines mostly survived, and the opener’s rolling-code steps show no gaps in session 2 (33 steps of 1, 3 repeats, 53 frames). Session 1 had one single-frame gap.

  • Every oversized packet was exactly 20 bytes (break byte plus one frame).

  • Sync after the flash was slow: about 170 s on the capture build (33 s after a restart, 6 s on the rolled-back build). In that first sync, 146 commands were queued within about a second and 9 sent. I also saw one signature error with a resync during each of the first two syncs, and none during the test windows.

One unexplained reset

On the first restart with the capture build the device came back with reboot reason “task watchdog”: crash handler Task wdt, core 1, PC 0x4037D6AE, backtrace 0x4037D6AB 0x420F7AC1 0x420F9A33 (ESPHome couldn’t decode it, toolchain not found). There was no other reset in about 85 minutes of testing, and in the 10 days before, every reboot on PR #36 was OTA or web-server initiated. It might be down to my extra logging, so I’m noting it in case anyone repeats the capture.

Questions

  1. Does the MS105MYQ dialect report motor state anywhere? If not, should the motor entity be expected to stay off on this model?

  2. Would you consider the self-calibrating position change proposed above? I’m happy to test it on my door.

  3. What is byte2 bit 0x04 in STATUS?

  4. Did anything in 1.6.2 (vs 1.6.0) change how obstruction is handled?

  5. Would you like a second capture that logs the discarded short packets and uses larger log buffers, and/or the same capture on the small door?

Data

The decoded frame tables for both sessions (device clock, command, door state, bytes, rolling-code step) are below. A redacted log extract (Wi-Fi, IP, MAC and device ID removed) is here: blaQ / Merlin MS105MYQ capture, 5 Oct 2026 (redacted) - Pastebin.com . I’ve left out the raw hex frames, but I’m happy to send them privately.

Decoded frames (device clock). Command, door state, STATUS bytes and the opener’s rolling-code step. Session 1 is 14:40 to 14:58, session 2 is 15:39 to 15:49 (AEST).

Decoded frames, session 1 
frames decoded: 86   failed to decode: 0

wall          t_ms dir cmd  name               door     par b1  b2  nib roll_step
14:41:29   1024346 RX  081  STATUS             closed   5   28  04  2   
14:41:35   1030394 RX  081  STATUS             closed   5   68  00  2   1
14:41:49   1044352 RX  081  STATUS             closed   5   28  04  2   1
14:41:55   1049947 RX  081  STATUS             closed   5   68  00  2   1
14:42:25   1079978 RX  081  STATUS             closed   5   68  00  2   0
14:42:26   1080991 RX  081  STATUS             opening  1   68  02  4   1
14:42:27   1081930 RX  081  STATUS             opening  1   68  02  4   0
14:42:42   1097073 RX  081  STATUS             open     4   68  02  1   1
14:43:00   1115370 RX  081  STATUS             closing  0   68  02  5   1
14:43:19   1134262 RX  081  STATUS             closed   7   68  02  2   1
14:43:51   1166519 RX  081  STATUS             opening  1   68  02  4   2
14:44:06   1181631 RX  081  STATUS             open     4   68  02  1   1
14:44:25   1200786 RX  081  STATUS             closing  0   68  02  5   1
14:44:44   1219932 RX  081  STATUS             closed   7   68  02  2   1
14:44:45   1220057 RX  48c  OPENINGS                    e   1d  13  0   1
14:47:32   1387892 RX  081  STATUS             closed   5   68  00  2   1
14:47:38   1393733 RX  081  STATUS             closed   5   68  00  2   0
14:48:30   1445272 TX  280  DOOR_ACTION                 b   01  01  1   
14:48:30   1445277 TX  280  DOOR_ACTION                 a   00  01  1   0
14:48:30   1445684 RX  081  STATUS             opening  1   68  02  4   1
14:48:46   1461813 RX  081  STATUS             open     4   68  02  1   1
14:50:23   1558831 TX  280  DOOR_ACTION                 a   01  01  0   1
14:50:23   1558835 TX  280  DOOR_ACTION                 b   00  01  0   0
14:50:24   1559678 RX  081  STATUS             closing  0   68  02  5   1
14:50:50   1585778 RX  081  STATUS             closed   7   68  02  2   1
14:50:50   1585870 RX  48c  OPENINGS                    9   1d  14  0   1
14:51:10   1605260 TX  280  DOOR_ACTION                 b   01  01  1   2
14:51:10   1605263 TX  280  DOOR_ACTION                 a   00  01  1   0
14:51:10   1605944 RX  081  STATUS             opening  1   68  02  4   1
14:51:26   1621058 RX  081  STATUS             open     4   68  02  1   1
14:52:02   1657229 TX  280  DOOR_ACTION                 a   01  01  0   1
14:52:02   1657233 TX  280  DOOR_ACTION                 b   00  01  0   0
14:52:03   1658449 RX  081  STATUS             closing  0   68  02  5   1
14:52:29   1684555 RX  081  STATUS             closed   7   68  02  2   1
14:52:29   1684754 RX  48c  OPENINGS                    8   1d  15  0   1
14:53:09   1724366 TX  280  DOOR_ACTION                 b   01  01  1   2
14:53:09   1724370 TX  280  DOOR_ACTION                 a   00  01  1   0
14:53:09   1724866 RX  081  STATUS             opening  1   68  02  4   1
14:53:26   1740998 RX  081  STATUS             open     4   68  02  1   1
14:54:03   1778438 RX  081  STATUS             open     4   28  06  1   1
14:54:04   1779848 RX  081  STATUS             open     0   68  06  1   1
14:54:20   1795066 RX  081  STATUS             open     4   28  06  1   1
14:54:22   1796981 RX  081  STATUS             open     0   68  06  1   1
14:55:00   1835722 RX  081  STATUS             closing  0   68  02  5   1
14:55:00   1835831 RX  081  STATUS             closing  0   68  02  5   0
14:55:09   1844788 RX  081  STATUS             closing  0   28  06  5   1
14:55:10   1845801 RX  081  STATUS             opening  1   28  06  4   1
14:55:11   1846155 RX  081  STATUS             opening  5   68  06  4   1
14:55:19   1853962 RX  081  STATUS             open     4   68  02  1   1
14:55:30   1865930 TX  281  LIGHT                       b   00  00  0   1
14:55:30   1865933 TX  080  GET_STATUS                  8   00  00  0   1
14:55:31   1866038 TX  281  LIGHT                       b   00  00  0   1
14:55:31   1866042 TX  080  GET_STATUS                  8   00  00  0   1
14:55:31   1866096 RX  081  STATUS             open     6   68  00  1   1
14:55:31   1866493 RX  081  STATUS             open     6   68  00  1   0
14:55:33   1868820 RX  081  STATUS             open     6   68  00  1   0
14:55:39   1874665 RX  081  STATUS             open     6   68  00  1   0
14:56:02   1897186 RX  081  STATUS             closing  0   68  02  5   1
14:56:08   1903082 RX  081  STATUS             closing  0   28  06  5   1
14:56:09   1904296 RX  081  STATUS             opening  1   28  06  4   1
14:56:09   1904598 RX  081  STATUS             opening  5   68  06  4   1
14:56:15   1910443 RX  081  STATUS             open     4   68  02  1   1
14:56:35   1930396 RX  081  STATUS             open     4   28  06  1   1
14:56:36   1931100 RX  081  STATUS             open     0   68  06  1   1
14:56:36   1931403 RX  081  STATUS             open     4   28  06  1   1
14:56:37   1932109 RX  081  STATUS             open     0   68  06  1   1
14:56:37   1932445 RX  081  STATUS             open     4   28  06  1   1
14:56:38   1933016 RX  081  STATUS             open     0   68  06  1   1
14:56:38   1933266 RX  081  STATUS             open     4   28  06  1   1
14:56:39   1933921 RX  081  STATUS             open     0   68  06  1   1
14:56:39   1934324 RX  081  STATUS             open     4   28  06  1   1
14:56:39   1934404 RX  081  STATUS             open     4   28  06  1   0
14:56:40   1935030 RX  081  STATUS             open     0   68  06  1   1
14:57:00   1955233 RX  081  STATUS             open     4   28  06  1   1
14:57:00   1955890 RX  081  STATUS             open     0   68  06  1   1
14:57:01   1956192 RX  081  STATUS             open     4   28  06  1   1
14:57:01   1956897 RX  081  STATUS             open     0   68  06  1   1
14:57:02   1957149 RX  081  STATUS             open     4   28  06  1   1
14:57:02   1957805 RX  081  STATUS             open     0   68  06  1   1
14:57:03   1958056 RX  081  STATUS             open     4   28  06  1   1
14:57:03   1958713 RX  081  STATUS             open     0   68  06  1   1
14:57:04   1959063 RX  081  STATUS             open     4   28  06  1   1
14:57:04   1959720 RX  081  STATUS             open     0   68  06  1   1
14:57:08   1963746 RX  081  STATUS             closing  0   68  02  5   1
14:57:26   1981884 RX  081  STATUS             closed   7   68  02  2   1
14:57:27   1982057 RX  48c  OPENINGS                    b   1d  16  0   1

=== command counts ===
  RX 081 STATUS               68
  TX 280 DOOR_ACTION          10
  RX 48c OPENINGS             4
  TX 281 LIGHT                2
  TX 080 GET_STATUS           2

=== STATUS frames (RX): which bits ever change ===
  b1: values seen ['28', '68']   changing-bit mask 0x40
      bit 0x40 set in door states ['closed', 'closing', 'open', 'opening']; clear in ['closed', 'closing', 'open', 'opening']
  b2: values seen ['00', '02', '04', '06']   changing-bit mask 0x06
      bit 0x02 set in door states ['closed', 'closing', 'open', 'opening']; clear in ['closed', 'open']
      bit 0x04 set in door states ['closed', 'closing', 'open', 'opening']; clear in ['closed', 'closing', 'open', 'opening']
  nib: values seen ['01', '02', '04', '05']   changing-bit mask 0x07
      bit 0x01 set in door states ['closing', 'open']; clear in ['closed', 'opening']
      bit 0x02 set in door states ['closed']; clear in ['closing', 'open', 'opening']
      bit 0x04 set in door states ['closing', 'opening']; clear in ['closed', 'open']
  parity nibble (bits 12-15, masked by gdolib) values seen: ['0', '1', '4', '5', '6', '7']

=== RX rolling-code steps (1 = no frame missing, 0 = repeat, 2+ = frames missing from this log) ===
  step 0: 8
  step 1: 62
  step 2: 1
Decoded frames, session 2 
frames decoded: 53   failed to decode: 0

wall          t_ms dir cmd  name               door     par b1  b2  nib roll_step
15:40:20   4555670 RX  081  STATUS             opening  1   68  02  4   
15:40:26   4561666 RX  081  STATUS             stopped  6   68  02  3   1
15:40:35   4570734 RX  081  STATUS             closing  0   68  02  5   1
15:40:43   4578795 RX  081  STATUS             closed   7   68  02  2   1
15:40:43   4578889 RX  48c  OPENINGS                    b   1d  16  0   1
15:41:11   4606010 RX  081  STATUS             opening  1   68  02  4   1
15:41:16   4611048 RX  081  STATUS             stopped  6   68  02  3   1
15:41:25   4620233 RX  081  STATUS             closing  0   68  02  5   1
15:41:32   4627216 RX  081  STATUS             closed   7   68  02  2   1
15:41:32   4627310 RX  48c  OPENINGS                    b   1d  16  0   1
15:43:20   4735136 TX  280  DOOR_ACTION                 b   01  01  1   
15:43:20   4735139 TX  280  DOOR_ACTION                 a   00  01  1   0
15:43:21   4736075 RX  081  STATUS             opening  1   68  02  4   1
15:43:24   4739636 TX  280  DOOR_ACTION                 9   01  01  3   1
15:43:24   4739639 TX  280  DOOR_ACTION                 8   00  01  3   0
15:43:25   4740105 RX  081  STATUS             stopped  6   68  02  3   1
15:43:37   4752382 TX  280  DOOR_ACTION                 a   01  01  0   1
15:43:37   4752386 TX  280  DOOR_ACTION                 b   00  01  0   0
15:43:38   4753389 RX  081  STATUS             closing  0   68  02  5   1
15:43:51   4766401 RX  081  STATUS             closed   7   68  02  2   1
15:43:51   4766636 RX  48c  OPENINGS                    b   1d  16  0   1
15:45:00   4835317 TX  280  DOOR_ACTION                 b   01  01  1   2
15:45:00   4835321 TX  280  DOOR_ACTION                 a   00  01  1   0
15:45:00   4835853 RX  081  STATUS             opening  1   68  02  4   1
15:45:05   4840638 TX  280  DOOR_ACTION                 9   01  01  3   1
15:45:05   4840643 TX  280  DOOR_ACTION                 8   00  01  3   0
15:45:06   4840944 RX  081  STATUS             stopped  6   68  02  3   1
15:45:17   4852284 TX  280  DOOR_ACTION                 a   01  01  0   1
15:45:17   4852287 TX  280  DOOR_ACTION                 b   00  01  0   0
15:45:18   4853089 RX  081  STATUS             closing  0   68  02  5   1
15:45:33   4868099 RX  081  STATUS             closed   7   68  02  2   1
15:45:33   4868193 RX  48c  OPENINGS                    b   1d  16  0   1
15:46:08   4903385 RX  081  STATUS             opening  1   68  02  4   1
15:46:23   4918492 RX  081  STATUS             open     4   68  02  1   1
15:47:00   4955793 RX  081  STATUS             closing  0   68  02  5   1
15:47:06   4960936 RX  081  STATUS             stopped  6   68  02  3   1
15:47:16   4970985 RX  081  STATUS             opening  1   68  02  4   1
15:47:21   4975944 RX  081  STATUS             open     4   68  02  1   1
15:47:21   4975959 TX  281  LIGHT                       b   00  00  0   2
15:47:21   4975964 TX  080  GET_STATUS                  8   00  00  0   1
15:47:21   4976048 TX  281  LIGHT                       b   00  00  0   1
15:47:21   4976051 TX  080  GET_STATUS                  8   00  00  0   1
15:47:21   4976139 RX  081  STATUS             open     6   68  00  1   1
15:47:21   4976439 RX  081  STATUS             open     6   68  00  1   0
15:47:23   4978813 RX  081  STATUS             open     6   68  00  1   0
15:47:29   4984658 RX  081  STATUS             open     6   68  00  1   0
15:47:36   4991074 RX  081  STATUS             closing  0   68  02  5   1
15:47:40   4995098 RX  081  STATUS             stopped  6   68  02  3   1
15:47:48   5003157 RX  081  STATUS             opening  1   68  02  4   1
15:47:52   5007305 RX  081  STATUS             open     4   68  02  1   1
15:48:06   5021355 RX  081  STATUS             closing  0   68  02  5   1
15:48:24   5039496 RX  081  STATUS             closed   7   68  02  2   1
15:48:24   5039589 RX  48c  OPENINGS                    a   1d  17  0   1

=== command counts ===
  RX 081 STATUS               32
  TX 280 DOOR_ACTION          12
  RX 48c OPENINGS             5
  TX 281 LIGHT                2
  TX 080 GET_STATUS           2

=== STATUS frames (RX): which bits ever change ===
  b1: values seen ['68']   changing-bit mask 0x00
  b2: values seen ['00', '02']   changing-bit mask 0x02
      bit 0x02 set in door states ['closed', 'closing', 'open', 'opening', 'stopped']; clear in ['open']
  nib: values seen ['01', '02', '03', '04', '05']   changing-bit mask 0x07
      bit 0x01 set in door states ['closing', 'open', 'stopped']; clear in ['closed', 'opening']
      bit 0x02 set in door states ['closed', 'stopped']; clear in ['closing', 'open', 'opening']
      bit 0x04 set in door states ['closing', 'opening']; clear in ['closed', 'open', 'stopped']
  parity nibble (bits 12-15, masked by gdolib) values seen: ['0', '1', '4', '6', '7']

=== RX rolling-code steps (1 = no frame missing, 0 = repeat, 2+ = frames missing from this log) ===
  step 0: 3
  step 1: 33