search

emsesp / EMS-ESP32

ESP32 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
589 stars 100 forks source link

two unknown telegram types #92

Closed wrohdewald closed 1 year ago

wrohdewald commented 3 years ago

System info see at end

Syslog shows

root@speicher:/var/log# grep -i 'No telegram' kern.log | sed 's/.*emsesp] //' | sort | uniq No telegram type handler found for ID 0x12 (src 0x10) No telegram type handler found for ID 0x255 (src 0x20) No telegram type handler found for ID 0x255 (src 0x21) No telegram type handler found for ID 0x2A7 (src 0x10) No telegram type handler found for ID 0x2A8 (src 0x10) No telegram type handler found for ID 0xBF (src 0x10) No telegram type handler found for ID 0xBF (src 0x20) No telegram type handler found for ID 0xBF (src 0x21) No telegram type handler found for ID 0xE6 (src 0x08) No telegram type handler found for ID 0xEA (src 0x08)

I also wonder why JSON below only mentions device ID 0x21 for MM200, it also has 0x20:

Jul 30 19:39:04 ems-esp - 000+00:00:03.929 D 84: [emsesp] Adding new device MM200 (device ID 0x21, product ID 161, version 29.04) Jul 30 19:39:06 ems-esp - 000+00:00:05.455 D 107: [emsesp] Adding new device MM200 (device ID 0x20, product ID 161, version 29.04)

I suppose you also need raw data for unknown telegram types but I found no way how to enable that.

Two of them with context:

Jul 31 13:08:36 ems-esp - <U+FEFF>000+00:00:47.323 T 405: [emsesp] Mixer(0x21) -> Boiler(0x08), UBASetPoints(0x1A), data: 00 00 00 Jul 31 13:08:37 ems-esp - <U+FEFF>000+00:00:47.348 T 406: [emsesp] Mixer(0x21) -> All(0x00), ?(0x255), data: 00 Jul 31 13:08:37 ems-esp - <U+FEFF>000+00:00:47.348 D 407: [emsesp] No telegram type handler found for ID 0x255 (src 0x21) Jul 31 13:08:37 ems-esp - <U+FEFF>000+00:00:47.551 T 408: [emsesp] Mixer(0x21) -> All(0x00), MMPLUSStatusMessage_HC(0x2D8), data: 00 02 00 00 DC 00 00 00 03 Jul 31 13:08:38 ems-esp - <U+FEFF>000+00:00:48.373 T 409: [emsesp] Mixer(0x20) -> Boiler(0x08), UBASetPoints(0x1A), data: 00 00 00 Jul 31 13:08:38 ems-esp - <U+FEFF>000+00:00:48.396 T 410: [emsesp] Mixer(0x20) -> Boiler(0x08), ?(0x1E), data: 00 F3 Jul 31 13:08:38 ems-esp - <U+FEFF>000+00:00:48.423 T 411: [emsesp] Mixer(0x20) -> All(0x00), ?(0x255), data: 00 Jul 31 13:08:38 ems-esp - <U+FEFF>000+00:00:48.423 D 412: [emsesp] No telegram type handler found for ID 0x255 (src 0x20) Jul 31 13:08:38 ems-esp - <U+FEFF>000+00:00:48.626 T 413: [emsesp] Mixer(0x20) -> All(0x00), MMPLUSStatusMessage_HC(0x2D7), data: 00 00 00 80 00 00 00 00 03 Jul 31 13:08:42 ems-esp - <U+FEFF>000+00:00:52.451 T 420: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorWW(0x34), data: 38 02 15 02 15 A1 00 01 03 00 00 4C 3E 00 09 34 00 80 00 Jul 31 13:08:42 ems-esp - <U+FEFF>000+00:00:52.708 T 421: [emsesp] Boiler(0x08) -> All(0x00), UBAMonitorFast(0x18), data: 05 02 1D 00 00 00 02 00 C0 80 00 02 15 80 00 00 00 FF 00 00 00 CB 00 00 00 Jul 31 13:08:42 ems-esp - <U+FEFF>000+00:00:52.978 T 422: [emsesp] Boiler(0x08) -> All(0x00), MC110Status(0x2A), data: 00 00 00 00 03 00 00 00 B4 00 00 80 00 00 80 00 80 00 80 00 00 Jul 31 13:08:47 ems-esp - <U+FEFF>000+00:00:58.271 T 423: [emsesp] Mixer(0x20) -> Boiler(0x08), ?(0x1E), data: 00 F3 Jul 31 13:08:49 ems-esp - <U+FEFF>000+00:01:00.001 D 424: [emsesp] Fetching values for device ID 0x08 Jul 31 13:08:50 ems-esp - <U+FEFF>000+00:01:00.001 D 430: [emsesp] Fetching values for device ID 0x09 Jul 31 13:08:50 ems-esp - <U+FEFF>000+00:01:00.001 D 431: [emsesp] Fetching values for device ID 0x10 Jul 31 13:08:51 ems-esp - <U+FEFF>000+00:01:00.001 D 444: [emsesp] Fetching values for device ID 0x21 Jul 31 13:08:51 ems-esp - <U+FEFF>000+00:01:00.001 D 446: [emsesp] Fetching values for device ID 0x20 Jul 31 13:08:52 ems-esp - <U+FEFF>000+00:01:00.284 D 452: [emsesp] Last Tx read successful

{ "System": { "version": "3.0.3b2", "uptime": "000+00:00:04.325" }, "Status": { "bus": "connected", "bus protocol": "HT3", "#telegrams received": 11, "#read requests sent": 6, "#write requests sent": 0, "#incomplete telegrams": 0, "#tx fails": 0, "rx line quality": 100, "tx line quality": 100, "#MQTT publish fails": 0, "#dallas sensors": 0, "#dallas fails": 0 }, "Devices": [ { "type": "Boiler", "name": "GBx72/Trendline/Cerapur/Greenstar Si/27i (DeviceID:0x08, ProductID:123, Version:06.03)", "handlers": "0x10 0x11 0x14 0x15 0x1C 0x18 0x19 0x35 0x16 0x33 0x34 0x1A 0x26 0x2A 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA 0x494 0x495" }, { "type": "Thermostat", "name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II (DeviceID:0x10, ProductID:158, Version:18.06)", "handlers": "0xA3 0x06 0xA2 0x12 0x2A5 0x2B9 0x2AF 0x29B 0x2A6 0x2BA 0x2B0 0x29C 0x2A7 0x2BB 0x2B1 0x29D 0x2A8 0x2BC 0x2B2 0x29E 0x2F5 0x31B 0x31D 0x31E 0x23A 0x267 0x240" }, { "type": "Mixer", "name": "MM200 (DeviceID:0x21, ProductID:161, Version:29.04)", "handlers": "0x2D8" }, { "type": "Controller", "name": "Controller (DeviceID:0x09, ProductID:152, Version:03.01)", "handlers": "" } ] }

proddy commented 3 years ago

there are many unknown telegrams, either by design because we're not interested in the data they are carrying or we just don't know what they are. Usually, we start with missing data as seen on a gateway, thermostat or boiler and then work backwards figuring out where it's hiding in the EMS messages.

proddy commented 3 years ago

also see https://emsesp.github.io/docs/#/Troubleshooting?id=ems-esp-is-showing-incorrect-values-from-a-specific-device

you can query a specific telegram on a device and see what comes back using the read command

MichaelDvP commented 3 years ago

@wrohdewald The ems-bus is slow and it takes some time to fetch all information we need. After

"uptime": "000+00:00:04.325"

the devices are not completly registered. You have to give emsesp more time to gather the information from bus.

If you take a look at the system info you'll find the handlers for each device. The telegrams 0xe6 and 0xea are handled by the boiler, 0x12, 0x2a7 and 0x2a8 by thermostat, these are not unknown after device registration. 0xBF is not handled, but known telegram type, it is used for error messages from devices. These errors are logged by boiler and thermostat and republished with date/time and device-source in the telegrams 0x10, 0x11 and 0x12. We read the 0x10/11/12 and skip the BF. 0x255 from mixer is indeed unknown, your log shows only a single null-byte as data. If you can find out what values are published with this telegram, we can add to the mixer, but for now we do not know what it means.

proddy commented 2 years ago

closing, no response.