starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #443] [Bug]: HMS error notifications re-trigger due to flapping error codes #273

New issue

Closed

opened 2026-05-07 00:08:18 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-07 00:08:18 +02:00

Owner

Originally created by @sbcrumb on GitHub (Feb 18, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/443

Originally assigned to: @sbcrumb on GitHub.

Bug Description

HMS error notifications fire repeatedly for the same error when the printer's HMS codes
flicker on and off. Newer printers (e.g. H2S) send transient HMS conditions that briefly
clear (hms: []) and reappear every few seconds. Each time the error reappears after a
brief gap, bambuddy treats it as a new error and sends another notification.

Example: During PETG printing, the chamber temperature regulation HMS code
(0300A70000030001) toggles on/off as temps fluctuate around the threshold, causing
repeated "HMS errors detected" / "HMS errors cleared" notification cycles.

MQTT log showing the flapping pattern:
15:43:42 HMS data received: []
15:43:43 HMS data received: [{'attr': 50374400, 'code': 196609}]
...
15:44:14 HMS data received: []
15:44:16 HMS data received: []
15:44:23 HMS data received: [{'attr': 50374400, 'code': 196609}]
...
15:44:31 HMS data received: []
15:44:36 HMS data received: [{'attr': 50374400, 'code': 196609}]

Expected Behavior

A single notification should be sent when an HMS error first appears. If the same error
briefly clears and reappears (flapping), it should not trigger additional notifications.
The notification tracking should only reset after the error has been genuinely cleared
for a sustained period (e.g. 30 seconds).

Steps to Reproduce

Connect a Bambu Lab printer (observed on H2S) to bambuddy
Print with PETG or any material that raises chamber temperature near the threshold
Observe HMS error notifications being sent repeatedly as the printer's HMS codes
flicker on/off in the MQTT stream (e.g. hms: [{...}] → hms: [] → hms: [{...}]
cycling every few seconds)
Each cycle triggers a new "HMS errors detected" notification

Printer Model

H2S

Bambuddy Version

0.2.0

Printer Firmware Version

01.01.02.00

Installation Method

Manual (git clone)

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Screenshots

No response

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode

Originally created by @sbcrumb on GitHub (Feb 18, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/443 Originally assigned to: @sbcrumb on GitHub. ### Bug Description HMS error notifications fire repeatedly for the same error when the printer's HMS codes flicker on and off. Newer printers (e.g. H2S) send transient HMS conditions that briefly clear (`hms: []`) and reappear every few seconds. Each time the error reappears after a brief gap, bambuddy treats it as a new error and sends another notification. Example: During PETG printing, the chamber temperature regulation HMS code (0300A70000030001) toggles on/off as temps fluctuate around the threshold, causing repeated "HMS errors detected" / "HMS errors cleared" notification cycles. MQTT log showing the flapping pattern: 15:43:42 HMS data received: [] 15:43:43 HMS data received: [{'attr': 50374400, 'code': 196609}] ... 15:44:14 HMS data received: [] 15:44:16 HMS data received: [] 15:44:23 HMS data received: [{'attr': 50374400, 'code': 196609}] ... 15:44:31 HMS data received: [] 15:44:36 HMS data received: [{'attr': 50374400, 'code': 196609}] ### Expected Behavior A single notification should be sent when an HMS error first appears. If the same error briefly clears and reappears (flapping), it should not trigger additional notifications. The notification tracking should only reset after the error has been genuinely cleared for a sustained period (e.g. 30 seconds). ### Steps to Reproduce 1. Connect a Bambu Lab printer (observed on H2S) to bambuddy 2. Print with PETG or any material that raises chamber temperature near the threshold 3. Observe HMS error notifications being sent repeatedly as the printer's HMS codes flicker on/off in the MQTT stream (e.g. `hms: [{...}]` → `hms: []` → `hms: [{...}]` cycling every few seconds) 4. Each cycle triggers a new "HMS errors detected" notification ### Printer Model H2S ### Bambuddy Version 0.2.0 ### Printer Firmware Version 01.01.02.00 ### Installation Method Manual (git clone) ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package ```shell ``` ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode

BreizhHardware

2026-05-07 00:08:18 +02:00

closed this issue
added the
bug

contrib
labels

BreizhHardware commented

2026-05-07 00:08:18 +02:00

Author

Owner

@sbcrumb commented on GitHub (Feb 18, 2026):

@maziggy assign this to me, I have actually already fixed it and will open a PR for it.

@sbcrumb commented on GitHub (Feb 18, 2026): @maziggy assign this to me, I have actually already fixed it and will open a PR for it.

BreizhHardware commented

2026-05-07 00:08:18 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 19, 2026):

https://github.com/maziggy/bambuddy/issues/443

@maziggy commented on GitHub (Feb 19, 2026): https://github.com/maziggy/bambuddy/issues/443

BreizhHardware referenced this issue

2026-05-07 00:15:20 +02:00

[PR #274] [MERGED] Fix/print-queue-time #987