-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
read maintenance messages (e.g. H6) which are not service/error codes #149
Comments
in the console can you do a |
also in 1.9.5 the service code and error are from the boiler, not the thermostat. You may be mixing the two up? |
Hi |
You can read the last errors from the devicelog. But H06 is not a error message and has no errorcode, it's a maintance message, i doubt it is in the errorlog. |
here are the results: |
In message 10 we have only a errors without date (i think from installation: Error In message 11 are the errors: In message 12 from thermostat is a old communication error: |
Hi - Yes flame cutoff is Flamme Abriss in german. |
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
Anyway: Thanks for this great project and the fast support! |
Sorry, that contains nothing new. @proddy: for this it would help if we have a third watch type @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. |
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. |
It is already logged by
|
nice trick. worth documenting somewhere? |
|
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... |
catched additional telegrams between MC10/BC10
not sure if they are really helpfull. |
Have you done something on MC10 to trigger the 05 messages? |
The 05's are because pressing the of RESET button on MC10. |
Hm, on gitter you have catched pos 8 |
No, both on MC10... 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. |
I definitely could deliver more logs - if there would be a working syslog... |
Yep, I can confirm that one. Today I got a "H 4" warning. syslog shows: |
Addentum to the reset codes: |
I believe this has already been implemented. Otherwise we can re-open it. |
Just to have it documented, here's another function in the 0x05 telegram from controller: |
Bug description
Active Error-Message shown on Thermostat RC30 (H6) is not detected with v2.1, but was detected with v1.9.5.
Steps to reproduce
Steps to reproduce the behavior.
Expected behavior
If an error is displayed on RC30 this should also be detected with ems-esp to be able to send a notification.
Screenshots
If applicable, add screenshots to help explain your problem.
Device information
{
"System": {
"version": "2.1.0",
"uptime": "000+04:45:31.631",
"freemem": 40,
"fragmem": 14
},
"Settings": {
"enabled": "on",
"publish_time_boiler": 10,
"publish_time_thermostat": 10,
"publish_time_solar": 10,
"publish_time_mixer": 10,
"publish_time_other": 10,
"publish_time_sensor": 10,
"mqtt_format": 1,
"mqtt_qos": 0,
"mqtt_retain": "on",
"tx_mode": 1,
"ems_bus_id": 11,
"master_thermostat": 0,
"rx_gpio": 13,
"tx_gpio": 15,
"dallas_gpio": 14,
"dallas_parasite": "off",
"led_gpio": 2,
"hide_led": "off",
"api_enabled": "on",
"bool_format": 1,
"analog_enabled": "off"
},
"Status": {
"bus": "connected",
"bus protocol": "Buderus",
"#telegrams received": 20115,
"#read requests sent": 3739,
"#write requests sent": 4,
"#incomplete telegrams": 1,
"#tx fails": 3,
"rx line quality": 100,
"tx line quality": 100,
"#MQTT publish fails": 13,
"#dallas sensors": 0
},
"Devices": [
{
"type": "Boiler",
"name": "GB125/MC10 (DeviceID:0x08, ProductID:72, Version:02.04)",
"handlers": "0x10 0x11 0x14 0x15 0x16 0x18 0x19 0x1A 0x1C 0x2A 0x33 0x34 0x35 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
},
{
"type": "Thermostat",
"name": "RC30 (DeviceID:0x10, ProductID:67, Version:02.08)",
"handlers": "0xA3 0x06 0xA2 0x3E 0x3D 0x48 0x47 0x52 0x51 0x5C 0x5B 0xA5 0x37"
},
{
"type": "Mixer",
"name": "MM10 (DeviceID:0x21, ProductID:69, Version:02.00)",
"handlers": "0xAA 0xAB 0xAC"
},
{
"type": "Controller",
"name": "BC10/RFM20 (DeviceID:0x09, ProductID:68, Version:02.00)",
"handlers": ""
}
]
}
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: