read maintenance messages (e.g. H6) which are not service/error codes about ems-esp32

[MichaelDvP]

0Y means burner off due to temperature higher than setpoint, it's common after each burner stop and not related to H6.
The warning messages are stored somewhere else.

[MichaelDvP]

Just to have it documented, here's another function in the 0x05 telegram from controller:
Setting chimney sweeper mode:
controller(0x09) -W-> boiler(0x08), ?(0x05), data: 64 (offset 4)
resetting chimney sweeper mode:
controller(0x09) -W-> boiler(0x08), ?(0x05), data: 00 (offset 4)
I don't think we need a command for that in ems-esp.

[proddy]

in the console can you do a read 10 a2 with logging on so we can see what comes back in the telegram.

[proddy]

also in 1.9.5 the service code and error are from the boiler, not the thermostat. You may be mixing the two up?

[deejaybeam]

Hi
First screenshot is from the boiler. I´m looking also at the boiler messages, but with v2.1.0 I have seen, there is an error code for the thermostat too.
In the meanwhile I have executed a reset on the boiler, so the error is away, but if it accours again I will execute a read 10 a2 and post the result.
Until the update from 1.9.5 I know that "serviceCode" and "serviceCodeNumber" are detected when this happens.

[MichaelDvP]

You can read the last errors from the devicelog.
Boiler errors: read 8 10 and read 8 11
Thermostat/bus errors: read 10 12
It's always first two bytes ascii, next two bytes errornumber, than date of error.

But H06 is not a error message and has no errorcode, it's a maintance message, i doubt it is in the errorlog.

[deejaybeam]

here are the results:
read 8 10 000+17:02:15.836 N 1: [emsesp] Boiler(0x08) -> Me(0x0B), UBAErrorMessage1(0x10), data: 33 43 02 1C 00 5F EE 30 00 06 D0 4B 33 43 02 1C 00 5F EE 30 00 00 01 4B 33 43
read 8 11 000+17:02:49.753 N 2: [emsesp] Boiler(0x08) -> Me(0x0B), UBAErrorMessage2(0x11), data: 36 4C 02 05 94 0B 09 10 38 00 01 4B 36 4C 02 05 94 0B 06 10 3B 00 01 4B 36 4C
read 10 12 000+17:03:36.413 N 3: [emsesp] Thermostat(0x10) -> Me(0x0B), ?(0x12), data: 35 4C 02 1E 92 04 11 13 10 00 01 70 35 4C 02 1F 92 04 11 13 0F 00 01 70 41 30 03 000+17:03:36.783 N 4: [emsesp] Thermostat(0x10) -> Me(0x0B), ?(0x12), data: 30 03 30 92 04 0F 13 30 00 50 08 37 50 02 25 92 04 0F 13 30 00 57 70 (offset 25)

[MichaelDvP]

In message 10 we have only a errors without date (i think from installation: Error
3C(540) no date -> fan to fast, check PWM

In message 11 are the errors:
6L(517) 2020/11/16 09:56 -> flame cutoff
6L(517) 2020/11/16 06:59
I think this was also in boiler statuscode. Have you refreshed the webpage? Te webpage has no liveupdate.

In message 12 from thermostat is a old communication error:
5L(542) 2018/04/19 17:16 -> communication error with SAFe

[deejaybeam]

Hi - Yes flame cutoff is Flamme Abriss in german.
The webpage is not the (my) source. I work with mqtt messages and see all the updates in the topics but no error-message.
The error-message appears on the RC30, so I was wondering why I don receive a notification from hass. I checked mqtt messages and see there is no error. Additional I opened the ems-esp webportal to check if there is something.
Then I used the screen from webportal, to share the view of the system itself without mqtt, .... in between.
regards chris

[MichaelDvP]

Do you use publish on change or fixed intervalls?
Error 517 may vanish after automatic restart of the burner (SAFe).

I dont find where the maintenance messages are published on the ems-bus.

[deejaybeam]

Current situation after arriving home Boiler (and RC30) shows this:

But in mqtt:

Updates are published every 60 seconds.

read 8 10 000+23:46:10.976 N 1: [emsesp] Boiler(0x08) -> Me(0x0B), UBAErrorMessage1(0x10), data: 33 43 02 1C 00 5F EE 30 00 06 D0 4B 33 43 02 1C 00 5F EE 30 00 00 01 4B 33 43

read 8 11 000+23:46:22.082 N 2: [emsesp] Boiler(0x08) -> Me(0x0B), UBAErrorMessage2(0x11), data: 36 4C 02 05 94 0B 0E 10 01 00 01 4B 36 4C 02 05 94 0B 0D 10 1B 00 01 4B 36 4C

[MichaelDvP]

As written before, H06 is not an error code, it's a maintenance code. It's not logged and published by the error telegrams. Try with watch on if you can catch the telegram.

[deejaybeam]

OK - thought that if such a message appears, it should be visible in ems-esp too. Last messages where detected and notified. So I report that as an issue. Additional this happes right after the update from 1.9.5 to 2.1.0.

I have captured some messages with watch on:

001+00:43:11.185 N 0: [emsesp] Thermostat(0x10) -> All(0x00), RC35Monitor(0x48), data: 04 02 35 00 F4 00 00 2F 3A 41 00 00 64 11 33 001+00:43:11.792 N 1: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 2B 64 3C 89 01 35 01 02 57 83 00 80 00 02 17 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:12.072 N 2: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5B 00 00 38 00 (offset 27) 001+00:43:12.793 N 3: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 2D 64 3C 89 01 35 01 02 57 83 00 80 00 02 17 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:13.073 N 4: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5B 00 00 38 00 (offset 27) 001+00:43:15.657 N 5: [emsesp] Thermostat(0x10) -> Boiler(0x08), UBAFlags(0x35), data: 01 11 001+00:43:15.894 N 6: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 2D 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:16.174 N 7: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BF 5B 00 00 38 00 (offset 27) 001+00:43:16.582 N 8: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 0A 02 57 83 00 20 00 00 03 00 04 DE F5 00 32 3E 001+00:43:17.795 N 9: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 2E 64 3C 89 01 35 01 02 57 83 00 80 00 02 13 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:18.075 N 10: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5C 00 00 38 00 (offset 27) 001+00:43:19.784 N 11: [emsesp] Boiler(0x08) -> All(0x00), UBADevices(0x07), data: 0B 01 00 02 00 00 00 00 00 00 00 00 00 00 00 001+00:43:23.798 N 12: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 2F 64 3C 89 01 35 01 02 57 83 00 80 00 02 17 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:24.078 N 13: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 C0 5C 00 00 38 00 (offset 27) 001+00:43:25.699 N 14: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 30 64 3C 89 01 35 01 02 57 83 00 80 00 02 15 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:25.980 N 15: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5B 00 00 38 00 (offset 27) 001+00:43:26.387 N 16: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 0A 02 57 83 00 20 00 00 03 00 04 DE F5 00 32 3E 001+00:43:26.800 N 17: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 31 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:27.079 N 18: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5C 00 00 38 00 (offset 27) 001+00:43:29.060 N 19: [emsesp] Thermostat(0x10) -> All(0x00), RC35Monitor(0x3E), data: 04 02 2A 7D 00 00 00 26 32 3E 00 00 64 11 2A 001+00:43:35.705 N 20: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 31 64 3C 89 01 35 01 02 57 83 00 80 00 02 15 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:35.987 N 21: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5B 00 00 38 00 (offset 27) 001+00:43:36.392 N 22: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 0A 02 57 83 00 20 00 00 03 00 04 DE F5 00 32 3E 001+00:43:36.805 N 23: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 32 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:37.084 N 24: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BC 5C 00 00 38 00 (offset 27) 001+00:43:37.806 N 25: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 33 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:38.084 N 26: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BF 5C 00 00 38 00 (offset 27) 001+00:43:38.422 N 27: [emsesp] Thermostat(0x10) -> All(0x00), RCTime(0x06), data: 14 0B 11 10 27 21 00 00 001+00:43:43.809 N 28: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 35 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:44.088 N 29: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BF 5B 00 00 38 00 (offset 27) 001+00:43:44.709 N 30: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 36 64 3C 89 01 35 01 02 57 83 00 80 00 02 19 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:44.990 N 31: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BE 5B 00 00 38 00 (offset 27) 001+00:43:45.609 N 32: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 36 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:45.889 N 33: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BD 5B 00 00 38 00 (offset 27) 001+00:43:46.307 N 34: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorSlow(0x19), data: 00 43 02 36 02 B1 FF FF FF 64 01 CD 80 10 FB C3 08 5E 85 0C 1B B8 01 9B 3A 001+00:43:46.597 N 35: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 0A 02 57 83 00 20 00 00 03 00 04 DE F5 00 32 3E 001+00:43:46.912 N 36: [emsesp] Thermostat(0x10) -> All(0x00), RCOutdoorTemp(0xA3), data: 07 00 01 001+00:43:47.209 N 37: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 35 64 3C 89 01 35 01 02 57 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:47.490 N 38: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BE 5C 00 00 38 00 (offset 27) 001+00:43:47.885 N 39: [emsesp] Boiler(0x08) -> All(0x00), UBATotalUptime(0x14), data: 6C 3F 0F 001+00:43:48.406 N 40: [emsesp] Thermostat(0x10) -> Mixer(0x21), MMSetMessage(0xAC), data: 33 64 01 001+00:43:48.710 N 41: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 36 64 3C 89 01 35 01 02 57 83 00 80 00 02 15 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:48.992 N 42: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BF 5B 00 00 38 00 (offset 27) 001+00:43:53.407 N 43: [emsesp] Thermostat(0x10) -> Boiler(0x08), UBASetPoints(0x1A), data: 38 64 64 00 001+00:43:55.614 N 44: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 36 64 3C 89 01 35 01 02 56 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52 001+00:43:55.894 N 45: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 01 BE 01 BC 5B 00 00 38 00 (offset 27) 001+00:43:56.302 N 46: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 0A 02 56 83 00 20 00 00 03 00 04 DE F5 00 32 3E 001+00:43:57.715 N 47: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 38 02 37 64 3C 89 01 35 01 02 56 83 00 80 00 02 14 FF 2D 48 00 00 FF 00 10 01 52
Don´t know if there is something useful, or if I should watch for a specific entry...

Anyway: Thanks for this great project and the fast support!

[MichaelDvP]

Sorry, that contains nothing new.
I think the maintenance messages is only send once on change, like the errorlogs 10/11.
You have to catch the telegram in this moment the message is shown on the display.
And it's a unknown message, indicated by a ? as messagetype, i.e. [emsesp] Boiler(0x08) -> All(0x00), ?(0x__), data:
and the 0x__we need to know.

@proddy: for this it would help if we have a third watch type watch unknown or watch ? to catch only unknown telegrams.

@deejaybeam: anyway, the errorlog 0x11 shows that there was an error 6L(517) 16.11.2020 14:01, i'm sure this was also in the servicecode, but cleared before next fetch.

[proddy]

@proddy: for this it would help if we have a third watch type watch unknown or watch ? to catch only unknown telegrams.

or we could log these unknowns as WARNING or ALERT level so they could be filtered by the log command, also in syslog. Maybe also create a list of known telegram IDS that we just want to ignore.

[MichaelDvP]

It is already logged by process_telegram and LOG_DEBUG(F("No telegram type handler found for ID 0x%02X (src 0x%02X)"), telegram->type_id, telegram->src);
But to search for unknown telegrams i think a selective watch is better than WARNING log, cause it can be switched off.
A simple trick is to use watch on FF which should always catch nothing else.

    if (!found) {
        LOG_DEBUG(F("No telegram type handler found for ID 0x%02X (src 0x%02X)"), telegram->type_id, telegram->src);
        if ((watch() == WATCH_ON) && (watch_id_ == 0xFF)) {
            LOG_NOTICE(pretty_telegram(telegram).c_str());
        }
    }

[proddy]

nice trick. worth documenting somewhere?

[susisstrolch]

The "H 6" is visible as ServiceCode "0Y", Service Code number 0.

[susisstrolch]

I'll investigate during the day, because I currently (exactly: since the last maintenance) have the problem with the reoccuring H6 warning and Service code 513...

[susisstrolch]

catched additional telegrams between MC10/BC10

Nov 17 11:02:03 192.168.254.81 1 - ems-esp - - - - 002+16:06:29.724 N 547013: [telegram] Rx: 09 08 05 00 5A 9E
Nov 17 22:11:36 192.168.254.81 1 - ems-esp - - - - 003+03:16:03.457 N 663658: [telegram] Rx: 09 08 05 00 5A 9E
Nov 18 20:40:40 192.168.254.81 1 - ems-esp - - - - 000+11:24:24.426 N 147893: [telegram] Rx: 09 08 05 00 5A 9E
Nov 18 22:30:21 192.168.254.81 1 - ems-esp - - - - 000+13:14:05.419 N 171698: [telegram] Rx: 09 08 05 00 5A 9E

Nov 15 13:17:54 192.168.254.81 1 - ems-esp - - - - 000+18:22:19.273 N 167556: [telegram] Rx: 08 09 1C 05 06 B4
Nov 17 13:54:27 192.168.254.81 1 - ems-esp - - - - 002+18:58:54.264 N 580863: [telegram] Rx: 08 09 1C 05 06 B4
Nov 18 13:31:30 192.168.254.81 1 - ems-esp - - - - 000+04:15:14.456 N 60080: [telegram] Rx: 08 09 1C 05 06 B4
Nov 18 16:44:52 192.168.254.81 1 - ems-esp - - - - 000+07:28:36.242 N 98145: [telegram] Rx: 08 09 1C 05 06 B4

not sure if they are really helpfull.

[MichaelDvP]

Have you done something on MC10 to trigger the 05 messages?
The 1C seems to be the command from boiler for MC10 to show H06. (1C = maintenance message) https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme#ubawartungsmeldung

[susisstrolch]

The 05's are because pressing the of RESET button on MC10.

[MichaelDvP]

Hm, on gitter you have catched pos 8 Rx: 09 08 05 08 FF 2B, now in pos 0 Rx: 09 08 05 00 5A 9E
The same reset key, or one time reset on MC10, the other on SAFe?

[susisstrolch]

No, both on MC10...
05 08 FF: resets the H6 warning, but not the 6L.
05 00 5A: resets the 6L. Must be testet for the Hx warning.

My impressions is that MC10 generates those messages based on system status. Because (at least according to the buderus doc) it won't issue a reset if you neither have error or warning.

[susisstrolch]

I definitely could deliver more logs - if there would be a working syslog...

[susisstrolch]

The 1C seems to be the command from boiler for MC10 to show H06.

Yep, I can confirm that one. Today I got a "H 4" warning. syslog shows:
Nov 20 09:42:20 192.168.254.81 1 - ems-esp - - - - 000+16:30:16.487 T 143531: [telegram] Rx: 08 09 1C 05 04 B6
So, 08 09 1C 05 is the warning message "H", last data byte is the warning code itself.

[susisstrolch]

Addentum to the reset codes:
05 08 FF: only resets the warnings, nothing else
05 00 5A: only resets the errors (6x?), but not the warning.
In addition, if you issue a "reset" in any non error/non warning state you may end up with locking error 5P - too much reset requests.
At least I got that one yesterday when playing around with reset codes.
Unfortunatelly syslog wasn't patched at this time, so I don't have the telegrams for this case.
Will try it later during the day.

[proddy]

I believe this has already been implemented. Otherwise we can re-open it.