HMS advisories miscategorised as errors.

[edzieba]

New bug in ver. 19.3.24:
LEDs will enter red "error" state on non-serious non-halting advisories. For example "HMS_0C00_0300_0002_0001: Filament exposure metering failed" (https://wiki.bambulab.com/en/x1/troubleshooting/hmscode/0C00_0300_0002_0001).

By testing with the colour setting, this appears to have been categorised under "HMS Severity, SERIOUS". This cannot currently be mitigated without completely disabling Error Detection, as there is no way to set the LED CW/WW state as part of the UI (only RGB state) so the standard illumination (RGB off, CW/WW on) cannot be set.

[wile1411]

An option would be for your to set it to RGB White (255,255,255)

However, note that other errors like the "front cover falling off" or "System state is abnormal needing to factory reset" or "short circuit for motor" would all be classified as "Serious" and would have the same color.

Bambu Labs is a closed system so the full list of errors is not known, some of the list is available of their website.

If you know how to convert the MQTT code and attribute numbers to the error code on the screen, it would help greatly with bringing this functionality into the project that I'm trying to add (just a user like you).
Noting that it would require a lookup list of hundred or so codes to get their descriptions (The name of the error is not supplied via MQTT)

eg:
My research into other people work shows you bitshift the decimal numbers to the right 16 places and view as a Hex number.
First layer inspection code via MQTT = attr: 201327360 code: 196619
That gives the codes of attr: C00 code: 3

Somehow there are extra step that converts it to the specific code of "0C00_0300_0003_000B" (No idea how)
And then that code needs to be looked up via a massive lookup table to get a description of "Inspecting first layer."

Doable - but missing that middle step - any ideas?

[edzieba]

RGB 255,255,255 does not turn on the CC & CW LEDs, so nowhere close to normal illumination (much dimmer, way off in colour temp).

The HMS values appear to map using hex signed 2's complement. e.g on removing the head cover:
"attr": 50336256
"code": 131073
after decimal to hex becomes:
3001200
20001
or 300120020001

Prepend a 0 to make up two full bytes*, then split into nibbles:
0300_1200_0002_0001
Which is the correct HMS code for "toolhead cover has fallen off"

* I suspect that any of the few codes that use all 16 bits rather than just 15 will not need any prepending, but only the A1 series generate those codes and I do not own one to sniff the actual MQTT message contents.

The Wiki lists some (but possibly not all) HMS codes, but it would be entirely reasonable to just categorise the known ones into fatal/serious/advisory (rather than the current fatal/serious) and let all unknown codes fall into fatal as a failsafe (or get their own category to pick a specific colour for).

I don't think - beyond scraping the Bambu wiki articles - there is already any other convenient code mapping database, but if it would be useful I would be happy to spend a few evenings transcribing and categorising them into a .csv?

[wile1411]

perfect - that's what I was missing - I didn't understand the code I was using as reference, but your example that makes sense now. Should be easy enough to add.

[wile1411]

For reference for anyone else searching for method to get Bambu Error codes

From the MQTT elements of Attribute and Code:
uint64_t parsedHMScode = ((uint64_t)hms["attr"] << 32) + (uint64_t)hms["code"];

Printing the error code, formatted with leading zeros: (16 digits)
Serial.printf("%016llX\n", parsedHMScode);

Printing the Code in the format used by Bambu: 0000_0000_0000_0000
int chunk1 = (parsedHMScode >> 48);
int chunk2 = (parsedHMScode >> 32) & 0xFFFF;
int chunk3 = (parsedHMScode >> 16) & 0xFFFF;
int chunk4 = parsedHMScode & 0xFFFF;

char strHMScode[20];
sprintf(strHMScode, "%04X_%04X_%04X_%04X", chunk1, chunk2, chunk3, chunk4);
Serial.println(strHMScode);