S-Przybylski commented 5 years ago

Is your feature request related to a problem? Please describe. I want to investigate the EMS and EMS-Plus messages for my solar module SM100 device in future.

Describe the solution you'd like Can you please update the device table for my SM100? ... 0x30 -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25), #data=3 <--- Version(0x02) received Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04

Additional context I assume that the implementation of SM10 is not true generic one. My current log shows messages of a SM10, but in opposite direction the device is unknown... (i do not have a SM10 connected): (00:25:56.914) 0x09 -> SM10, type 0x96 telegram: 09 B0 96 00 07 (CRC=00), #data=1 (00:25:56.967) 0x30 -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5), #data=7 (00:25:56.979) 0x09 -> SM10, type 0x00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C), #data=3

The autodetect shows the following: Started scan on EMS bus for known devices Boiler found. Model Buderus GB172/Nefit Trendline (TypeID:0x08 ProductID:123 Version:04.09) Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04

proddy commented 5 years ago

could you try the latest dev build (under dev branch) and do a autodetect deep to see if your SM is correctly detected and configured?

S-Przybylski commented 5 years ago

Connected to: EMS-ESP version 1.7.0b5
autodetect deep Started scan on EMS bus for known devices Boiler found. Model Buderus GB172/Nefit Trendline (TypeID:0x08 ProductID:123 Version:04.09) Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04 Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04 Read operations not yet supported for this model thermostat Read operations not yet supported for this model thermostat

proddy commented 5 years ago

Can you pull and try again? It didn’t look like a deep scan was performed

On Tue, 16 Apr 2019 at 08:22, S-Przybylski notifications@github.com wrote:

Connected to: EMS-ESP version 1.7.0b5

autodetect deep Started scan on EMS bus for known devices Boiler found. Model Buderus GB172/Nefit Trendline (TypeID:0x08 ProductID:123 Version:04.09) Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04 Unrecognized device found. TypeID 0x02, ProductID 163, Version 21.04 Read operations not yet supported for this model thermostat Read operations not yet supported for this model thermostat

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/proddy/EMS-ESP/issues/96#issuecomment-483527114, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLHeIkzPpWM-Ui3OvmLhqoqupYITf6nks5vhWwdgaJpZM4cwvs1 .

S-Przybylski commented 5 years ago

Connected to: EMS-ESP version 1.7.0b6
autodetect deep System Logging set to None Starting a deep EMS device scan. This will take about 1 minute. Please wait... Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Finished the deep EMS device scan.

These 4 EMS devices were detected: Buderus GB172/Nefit Trendline (TypeID:0x08 ProductID:123 Version:04.09) SM100 Solar Module (TypeID:0x30 ProductID:163 Version:21.04) RC310 (TypeID:0x64 ProductID:158 Version:11.07) BC25 Base Controller (TypeID:0x09 ProductID:125 Version:01.06)

The log shows the following:

It seems that if the solar module is addressed the value SM is used, but the 0x30 address will not be identified as SM100 (00:09:14.444) 0x30 -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0), #data=1 <--- UBAParameterWW(0x33) received (00:09:14.472) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9), #data=7 <--- UBAParameterWW(0x33) received (00:09:14.500) 0x30 -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB), #data=1 (00:09:14.625) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 62 01 9F 01 5D 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=2A), #data=26 (00:09:15.061) 0x30 -> all, type 0x18 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE), #data=4 (00:09:15.277) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74), #data=15 (00:09:15.724) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 0C 64 00 00 00 00 (CRC=B8), #data=19 (00:09:15.929) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73), #data=6

info shows:

Solar Module stats: Collector temperature: 0.0 C Bottom temperature: 0.0 C Pump modulation: 0 % Pump active: off

In my installation a RC300 is installed. It seems to use the same identication like the RC310

proddy commented 5 years ago

I see your SM100 is based on the EMS+ protocol so not compatible with the existing SM10 logic. I’ll add it to the wish list for version 1.8

On Tue, 16 Apr 2019 at 09:59, S-Przybylski notifications@github.com wrote:

Connected to: EMS-ESP version 1.7.0b6

autodetect deep System Logging set to None Starting a deep EMS device scan. This will take about 1 minute. Please wait... Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Device found. Model BC25 Base Controller with TypeID 0x09, ProductID 125, Version 01.06 Finished the deep EMS device scan.

These 4 EMS devices were detected: Buderus GB172/Nefit Trendline (TypeID:0x08 ProductID:123 Version:04.09) SM100 Solar Module (TypeID:0x30 ProductID:163 Version:21.04) RC310 (TypeID:0x64 ProductID:158 Version:11.07) BC25 Base Controller (TypeID:0x09 ProductID:125 Version:01.06)

The log shows the following:

It seems that if the solar module is addressed the value SM is used, but the 0x30 address will not be identified as SM100 (00:09:14.444) 0x30 -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0), #data=1 <--- UBAParameterWW(0x33) received (00:09:14.472) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9), #data=7 <--- UBAParameterWW(0x33) received (00:09:14.500) 0x30 -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB), #data=1 (00:09:14.625) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 62 01 9F 01 5D 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=2A), #data=26 (00:09:15.061) 0x30 -> all, type 0x18 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE), #data=4 (00:09:15.277) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74), #data=15 (00:09:15.724) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 0C 64 00 00 00 00 (CRC=B8), #data=19 (00:09:15.929) 0x30 -> all, type 0x00 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73), #data=6

info shows:

Solar Module stats: Collector temperature: 0.0 C Bottom temperature: 0.0 C Pump modulation: 0 % Pump active: off

In my installation a RC300 is installed. It seems to use the same identication like the RC310

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/proddy/EMS-ESP/issues/96#issuecomment-483553874, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLHeE2sfFQn6sBoOh_Oo0GofYIcgJghks5vhYLtgaJpZM4cwvs1 .

proddy commented 5 years ago

@S-Przybylski we can start to implement this but I need you to decode the messages. Look at the telegrams your getting

30 00 FF 00 02 62 01 9F 01 5D 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00
30 00 FF 18 02 62 80 00
30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00
30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 0C 64 00 00 00 00

The types sent from the Solar module are x0262, x0263 and x0264

See if you can correlate the temperature settings you see on your boiler/thermostat/mobile app to any of these values.

proddy commented 5 years ago

I added support for type x0262 but need your help to decypher the data. We'll be looking for two temperatures and single byte modulation %

S-Przybylski commented 5 years ago

Hi @proddy, i will check this out

S-Przybylski commented 5 years ago

My first try: 30 0 FF 0 2 62 1 FB 1 9E 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 2B --> Solar Kollektor ist 50,7 gradC --> 1FB --> Databyte 1+2 --> Wasserspeicher unten ist 41,4 gradC --> 19E -->Databyte 3+4 30 0 FF 0 2 64 0 0 0 4 0 0 FF 0 0 1E 0C 20 64 0 0 0 0 E9 --> my collector area (Fläche) is 4 m2 --> possible Databyte 4 ? --> current solar pump modulation ratio is 30% --> hex 1E --> Databyte 10 ? My (other) current settings are - i can't identify by now: Hysterese: on 10.0 K; 0ff 5.0 K Max Speichertemp. 80grad C Max Kollektortemp 120grad C Min Kollektortemp 20grad C

proddy commented 5 years ago

Nice work. It’ll be easy to add this in code. Shall I do this or do you want to try?

I expect the max/min temps will be in a separate telegram type as it seems this x0262 is the SM100 monitor.

Also which if these data values do you think are important to report out via mqtt?

S-Przybylski commented 5 years ago

Please do it for me, then i will learn on this example how to integrate new functions (Can you please provide the changes to me?) First of all i am interrested in Temperatures and the Solarpump. Perhaps the daily sum of provided engery in KWH. The rest is nice to know, but not critical for me...

proddy commented 5 years ago

ok. So those two telegrams 0x262 and 0x264. Can you tell me if they are broadcast telegrams, i.e. sent out automatically every 10-60 seconds?

S-Przybylski commented 5 years ago

Investigation today 22:25 CET time (no sun active):

0x262, 0x263, 0x264, 0x266, 0x268 and 0x26a is send every 60 seconds, but not excactly. The negative drift is 200ms - 500ms. In addition to that, the protocol 0x266 is send 30 seconds later twice.
I found the energy earnings of today and in total (from beginning) in protocol 28E (which occured only one time in 15 minutes (not quite sure what the interval realy is): 0x519 =1305 --> 1,3 kwh (display) - factor 1/1000 (is the todays value) and 0x75D3 = 30163 --> 3016,3 kwh (display) - factor 1/10 is the total value (over all) !

(06:03:15.579) 0x30 -> all, type 0x00 telegram: 30 0 FF 0 2 8E 0 0 0 0 0 0 5 19 0 0 75 D3 (CRC=77), #data=14

Could you please also put the energy earnings into the mqtt message?

I rechecked the protocol 0x262 and 0x264: 0x262 all values seems to match 0x264 databyte four (EMS+) is currently null - i expect 4 square meter - so i was wrong: (05:55:19.676) 0x30 -> all, type 0x00 telegram: 30 0 FF 0 2 64 0 0 0 0 0 0 FF 0 0 0 0 0A 64 0 0 0 0 (CRC=54), #data=19
I just wonder that the 'log v' mode print in case of an EMS+ message the offset as the type. That seems to be wrong: (05:55:18.531) 0x30 -> all, type 0x00 telegram: 30 0 FF 0 2 62 0 75 1 9C 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 (CRC=2B), #data=26 For me it should be something like type 'EMS+ (FF) --> 0x262 ' (05:55:18.922) 0x30 -> all, type 0x18 telegram: 30 0 FF 18 2 62 80 0 (CRC=AE), #data=4
For me it should be something like type 'EMS+ (FF) --> 0x262 ' and not '0x18'! Here you can see that the offset is '0x18' due to the fact, that the maximum transmit size is fixed but the protocol 0x262 needs more characters.

proddy commented 5 years ago

thanks. As for point 4, I fixed this a few days ago in the dev branch and also added the SM100 support as defined by you. Could you do a quick check?

S-Przybylski commented 5 years ago

First of all thanks for your efforts! Great. Currently the SM-MQTT Messages toogles between a good and at least two bad states - see investigation below...

I was surprised that today the 0x262 protocol seems to update also a single value at the beginning without repeating the all other values: (00:24:18.020) SM -> all, type 0x0262 telegram: 30 0 FF 0 2 62 1 CA (CRC=E6) It seems that your routine wait for a full message but only get this short one and send out: {"temp":45.8,"bottomtemp":-665.6,"pumpmodulation":0,"pump":"off"}
Cosmetic: If the EMS+ message is null byte, the data cannot be 255 byte length: (00:23:35.979) SM -> 0x09, type 0x0001 telegram: 30 9 FF 0 0 1 (CRC=70), #data=255
The SM10Monitor(0x97) seems to interfere with the SM100 monitor: (00:23:36.916) SM -> me, type 0x97 telegram: 30 0B 97 0 (CRC=82)
<--- SM10Monitor(0x97) received
Publishing SM10 data via MQTT {"temp":0,"bottomtemp":0,"pumpmodulation":0,"pump":"off"}

Note: I just create a long term logfile to make a more statisical and useful interpretation of the protocol... hopefully i will get some additional benefits out of it (if so i provide them later here)

More detailed SM-Protocol: (00:23:35.863) SM -> 0x09, type 0x02 telegram: 30 9 2 0 A3 15 4 (CRC=25)
SM10 Solar Module support enabled.
(00:23:35.931) SM -> 0x09, type 0x96 telegram: 30 9 96 0 FF 18 1E 0A 2 50 28 (CRC=B5), #data=7
(00:23:35.979) SM -> 0x09, type 0x0001 telegram: 30 9 FF 0 0 1 (CRC=70), #data=255
(00:23:36.916) SM -> me, type 0x97 telegram: 30 0B 97 0 (CRC=82)
<--- SM10Monitor(0x97) received
Publishing SM10 data via MQTT {"temp":0,"bottomtemp":0,"pumpmodulation":0,"pump":"off"} (00:23:48.629) SM -> 0x09, type 0x02 telegram: 30 9 2 0 A3 15 4 (CRC=25)
SM10 Solar Module support enabled.
(00:23:48.682) SM -> 0x09, type 0x96 telegram: 30 9 96 0 FF 18 1E 0A 2 50 28 (CRC=B5), #data=7
(00:23:48.737) SM -> 0x09, type 0x0001 telegram: 30 9 FF 0 0 1 (CRC=70), #data=255
(00:23:49.353) SM -> all, type 0x0266 telegram: 30 0 FF 0 2 66 1 62 0 12 (CRC=73)
(00:23:50.112) SM -> me, type 0x97 telegram: 30 0B 97 0 (CRC=82)
<--- SM10Monitor(0x97) received

(00:24:18.020) SM -> all, type 0x0262 telegram: 30 0 FF 0 2 62 1 CA (CRC=E6)
<--- SM100Monitor(0x262) received
Publishing SM10 data via MQTT {"temp":45.8,"bottomtemp":-665.6,"pumpmodulation":0,"pump":"off"}

(00:24:19.171) SM -> all, type 0x0262 telegram: 30 0 FF 0 2 62 1 CA 1 93 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 (CRC=BE), #data=23
<--- SM100Monitor(0x262) received
Publishing SM10 data via MQTT {"temp":45.8,"bottomtemp":40.3,"pumpmodulation":0,"pump":"off"}
(00:24:19.601) SM -> all, type 0x0262 telegram: 30 0 FF 18 2 62 80 0 (CRC=AE)
<--- SM100Monitor(0x262) received
Publishing SM10 data via MQTT {"temp":"?","bottomtemp":-2099.2,"pumpmodulation":0,"pump":"off"}

(00:24:19.832) SM -> all, type 0x0263 telegram: 30 0 FF 0 2 63 80 0 80 0 0 0 80 0 80 0 80 0 0 (CRC=74), #data=12
Publishing SM10 data via MQTT {"temp":"?","bottomtemp":-2099.2,"pumpmodulation":0,"pump":"off"}

(00:24:20.280) SM -> all, type 0x0264 telegram: 30 0 FF 0 2 64 0 0 0 4 0 0 FF 0 0 1E 0B 9 64 0 0 0 0 (CRC=6D), #data=16
<--- SM100Status(0x264) received
Publishing SM10 data via MQTT {"temp":"?","bottomtemp":-2099.2,"pumpmodulation":30,"pump":"off"}

(00:24:20.482) SM -> all, type 0x0266 telegram: 30 0 FF 0 2 66 1 62 0 12 (CRC=73)
(00:24:21.237) SM -> all, type 0x0268 telegram: 30 0 FF 0 2 68 0C 0 (CRC=1E)
(00:24:21.451) SM -> all, type 0x026A telegram: 30 0 FF 0 2 6A 3 3 3 0 3 3 3 3 3 0 4 3 (CRC=EB), #data=11

S-Przybylski commented 5 years ago

Details about states of the pump and changes: Conclusion: Type 0x026a databyte 0A: "03" solar pump off and "04" solar pump on Short messages are send when the status of the pump changes And as already said: The temperature of the collector is send in addition as short message only if the pump is on

Details:

Status pump is off: see penultimate data byte "03" of 0x026a and data byte 9 of 0x264 = "00" SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5), #data=11 SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 0C 0A 64 00 00 00 00 (CRC=53), #data=16
Status pump is on; see penultimate data byte "04" of 0x026a and data byte 9 of 0x264 = "1E" SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 04 03 (CRC=EB), #data=11 SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 1E 09 08 64 00 00 00 00 (CRC=CD), #data=16 Note: If on, you get additional status updates of the collector temp as a short message: SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 02 1A (CRC=30)
Solar pump changes from off --> on: type 0x0264 data byte 09 set first to "64" and type 0x026a byte 0A is set to "04" SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 64 (CRC=37) SM -> all, type 0x026A telegram: 30 00 FF 0A 02 6A 04 (CRC=53) less then 10 seconds later the pump is throttled to 30% 0x1E: SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 1E (CRC=4D)
Solar pump changes from on --> off: type 0x0264 data byte 09 set to "00" and type 0x026a byte 0A is set to "03" SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 00 (CRC=53) SM -> all, type 0x026A telegram: 30 00 FF 0A 02 6A 03 (CRC=54)

proddy commented 5 years ago

Questions so I can implement these changes:

The energy values (e.g. 1,3 kwh for today and 3016,3 kwh for total). What shall I call these variables?
For the pump on/off I'll just listen to 0x26A and the 9th byte for a 03 or 04 ?

S-Przybylski commented 5 years ago

Hi proddy, my suggestions to questions: 1.) ENERGYToday and ENERGYTotal. If you have better namings thats also fine for me! 2.) In deed, thats what i found out. I saw that protocol changes when the pump goes on/off at least 3-4 times in the past days. In the night the protocol shows always "03"... Therefore i belive that this value shows up the pump status. I never saw other values for data byte 9 (0x26A) in my configuration.

Could you solve the issue with the toggling values? Thanks for your patience and support!

Addititional observation: Yesterday a also saw that the 0x262 protocol updates the second value bottomtemp in a "short" protocol: 30 00 FF 02 02 62 01 B3 (CRC=BF). I rechecked the protocols and found also situations where the pump was "off" and then both bottomtemp and collectortemp was updated in a short message independently (so i have to withdraw my last statement, that the collectortemp will send out additionally in a short protocol when the pump is on).

S-Przybylski commented 5 years ago

Hi @Proody regarding an additional protocol 0x028E: I have identified three values in the EMS+ 0x028E Protocol which cover the Solar energy earnings - repeated every hour

last hour / 10 in Wh --> databyte 2+3
todays in Wh --> databyte 6+7
total / 10 in kWh --> databyte 10+11

Protocol: (01:07:35.738) SM -> all, type 0x028E telegram: 30 00 FF 00 02 8E 00 00 0C F3 00 00 06 02 00 00 76 33 (CRC=8A), #data=11 (02:07:31.416) SM -> all, type 0x028E telegram: 30 00 FF 00 02 8E 00 00 07 9E 00 00 06 C5 00 00 76 35 (CRC=27), #data=11 (03:07:26.818) SM -> all, type 0x028E telegram: 30 00 FF 00 02 8E 00 00 00 00 00 00 06 C5 00 00 76 35 (CRC=82), #data=11

Example 1:07:

last hour --> 0x0CF3 = 3315 --> / 10 = 331,5Wh
todays --> 0x0602 = 1538Wh
total --> 0x7633 = 30259 --> / 10 = 3025,9 kWh

Example 2:07:

last hour --> 0x079E = 1950 --> / 10 = 195Wh
todays --> 0x06C5 = 1733Wh
total --> 0x7635 = 30261 --> / 10 = 3026,1 kWh

Example 3:07 (pump was of since 2:07):

last hour --> 0x0000 = 0000 --> / 10 = 0Wh
todays --> 0x06C5 = 1733Wh
total --> 0x7635 = 30261 --> / 10 = 3026,1 kWh

Evidence: 1733Wh - 1538Wh = 195Wh

I could also make sense to send the last hour value (the resolution of the value is higher than the total value) for individual analytic purposes. The value represents the average power of the solar panels

Does it make sense to put this information like the ones i found out up to now into a EMS+ Protocol datasheet?

Any news regarding my last post ?

proddy commented 5 years ago

yes it would be good to add to the Wiki under the SM100 section. https://github.com/proddy/EMS-ESP/wiki/SM100

I haven't had time to look into implementing this yet, its still changing and I want to figure out how the EMS+ works for all devices.

proddy commented 5 years ago

Added to 1.7. MQTT is like {"temp":"?","bottomtemp":"?","pump":"?","energylasthour":331.5,"energytoday":1538,"energytotal":3025.9}

S-Przybylski commented 5 years ago

Hi @proddy i have just tested your new release b12. I do not get the protocol in total sync, but its close. The mqtt event toggles: {"temp":"?","bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":22.8,"bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":"?","bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":"?","bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":21.8,"bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":"?","bottomtemp":43,"pumpmodulation":0,"pump":"?"} {"temp":"?","bottomtemp":43,"pumpmodulation":0,"pump":"?"}

(00:01:56.837) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:01:56.867) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9) #data=7 (00:01:56.895) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:01:57.013) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 E7 01 AE 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=C9) #data=24 <--- SM100Monitor(0x262) (00:01:57.390) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:01:57.611) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:01:58.150) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:01:58.364) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:01:58.800) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:01:59.024) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) Publishing SM data via MQTT

(00:02:26.955) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:02:46.920) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 E4 (CRC=CA) #data=2 <--- SM100Monitor(0x262) Publishing SM data via MQTT (00:02:56.862) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 E3 01 AE 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=9E) #data=24 <--- SM100Monitor(0x262) (00:02:57.275) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) Publishing SM data via MQTT (00:02:57.493) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:02:57.989) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:02:58.195) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:02:58.578) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:02:58.811) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A)

Requesting type SM10Monitor(0x97) from dest 0x30

(00:03:10.628) 0x09 -> SM, type 0x02 telegram: 09 B0 02 00 03 (CRC=66) #data=1 (00:03:10.655) SM -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25) #data=3 (00:03:10.667) 0x09 -> SM, type 0x96 telegram: 09 B0 96 00 07 (CRC=00) #data=1 (00:03:10.715) SM -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5) #data=7 (00:03:10.736) 0x09 -> SM, type 0xFF00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C) #data=1 (00:03:10.775) SM -> 0x09, type 0x0001 telegram: 30 09 FF 00 00 01 (CRC=70)

(00:03:11.168) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:03:11.202) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82)

(00:03:23.421) 0x09 -> SM, type 0x02 telegram: 09 B0 02 00 03 (CRC=66) #data=1 (00:03:23.456) SM -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25) #data=3 (00:03:23.474) 0x09 -> SM, type 0x96 telegram: 09 B0 96 00 07 (CRC=00) #data=1 (00:03:23.507) SM -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5) #data=7 (00:03:23.524) 0x09 -> SM, type 0xFF00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C) #data=1 (00:03:23.556) SM -> 0x09, type 0x0001 telegram: 30 09 FF 00 00 01 (CRC=70)

(00:03:26.036) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4

(00:03:56.094) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:03:56.146) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:03:56.267) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 E0 01 AE 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=E6) #data=24 <--- SM100Monitor(0x262) (00:03:56.698) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:03:56.930) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:03:57.375) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:03:57.579) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:03:58.038) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:03:58.264) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) Publishing SM data via MQTT

(00:04:11.586) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:04:11.648) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:04:26.196) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4

(00:04:56.383) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 DC 01 AE 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=D0) #data=24 <--- SM100Monitor(0x262) (00:04:56.843) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:04:57.082) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:04:57.528) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:04:57.735) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:04:58.185) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:04:58.400) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A)

For me it seems that the pump doesn't function, the collectors temp (here it began to rain, therefore it often updates the 0x262 protocol (long and short) to reflect the falling temperatures.

Do you have an Idea, why the "?" and "0" comes up? I do not get the above protocol. Its still the old one. The topic switched to "sm_data"

proddy commented 5 years ago

I will supress the ? values and check why the pump on/off is not working. It works with the previous test date you provided. The pump modulation is missing for SM100 as I don't know where it is stored.

proddy commented 5 years ago

made a fix in b13. I had to change some of the MQTT topic names as there are multiple solar modules (sm10, sm100, junkers, nefit etc)

pump modulation is in, i forgot. "test 15" shows it working based on your research,

S-Przybylski commented 5 years ago

Hi @proddy here by my test with the Version b13. I put the mqtt events and comments into it (shortend):

Device found. Model SM100 Solar Module with DeviceID 0x30, ProductID 163, Version 21.04 SM10 Solar Module support enabled. ... Publishing SM data via MQTT {"bottomtemp":40.6,"pumpmodulation":0}

(00:02:11.146) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:02:11.214) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:02:33.376) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:02:33.402) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9) #data=7 (00:02:33.432) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:02:33.542) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 3A 01 96 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=E3) #data=24 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"temp":5.8,"bottomtemp":40.6,"pumpmodulation":0}
Comment: temp and bottomtemp correct! pumpmodulation from log file perspective unknown

(00:02:33.961) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"bottomtemp":40.6,"pumpmodulation":0}
Comment: no need to repeat value; no new value or update given; missing temp

(00:02:34.186) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:02:34.697) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 00 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=AD) #data=17 <--- SM100Status(0x264) (00:02:34.900) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:02:35.335) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:02:35.554) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) (00:03:03.573) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 Requesting type SM10Monitor(0x97) from dest 0x30 (00:03:12.572) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:03:12.629) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:03:33.674) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 00 3A 01 96 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=E3) #data=24 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"temp":5.8,"bottomtemp":40.6,"pumpmodulation":0}
Comment: all three values ok; missing pump (refer to 0x26A)

(00:03:34.173) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"bottomtemp":40.6,"pumpmodulation":0}
Comment: no need to repeat value; no new value or update given; missing temp and pump (both from older values)

(00:03:34.393) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:03:34.863) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 00 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=AD) #data=17 <--- SM100Status(0x264) (00:03:35.067) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:03:35.471) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:03:35.685) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) (00:04:02.808) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4

Publishing SM data via MQTT {"bottomtemp":40.6,"pumpmodulation":0}
Comment: missing temp (from older value) and pump (refer to 0x26A)

What is the operational mode to store the solar values?

Do you store all known values and updates these accordingly? or
Do you store some values and others are volatile? For my it seems that the program currently act as described in 2. I would prefer 1. Benefit: All values are send to HomeAssistant even if some of them are not updated. And you don't get update error in the HA log file (while mode 1. produces errors)...

proddy commented 5 years ago

thanks for checking. I'll use your telegrams and simulate the behaviour here so I can debug.

It is #1, all values are stored and updated but sometimes I've noticed you get partial telegrams so values are overwritten sometimes incorrectly. I'll fix that.

proddy commented 5 years ago

made the changes. please test

S-Przybylski commented 5 years ago

Hi @proddy thanks for the fast update! I have tested the todays version. For me it seems that three things are not working correctly:

pumpmodulation isn't set up correctly - the short message was ignored SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 64 (CRC=37) #data=1
pump status isn't set up correctly - the long message was wrongly interpreted; 04 is on while 03 is off SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 04 03 (CRC=EB) #data=12
Strange thing: The last mqtt messages show negative values for "bottomtemp" while no SM-update occurred. Do you have an idea why this value is overwritten by an other process?

Commented Logfile incl. mqtt messages: ... (00:01:38.719) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 Publishing SM data via MQTT Requesting type SM10Monitor(0x97) from dest 0x30 (00:02:07.941) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:02:07.972) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9) #data=7 (00:02:07.999) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:02:08.117) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 AB 01 4E 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=FB) #data=24 <--- SM100Monitor(0x262) Publishing SM data via MQTT (not taken) (00:02:08.971) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:02:09.187) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:02:10.032) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:02:10.240) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:02:10.849) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:02:11.035) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 (00:02:12.055) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:02:14.938) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 AC (CRC=80) #data=2 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"collectortemp":42.8,"pumpmodulation":0,"pump":"off"}

Comment: Status seems to be ok; missing protocol details

(00:02:38.974) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:02:41.949) SM -> all, type 0xBF telegram: 30 00 BF 00 30 A3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=45) #data=24 (00:03:08.120) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 B1 01 4E 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=B7) #data=24 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"collectortemp":43.3,"bottomtemp":33.4,"pumpmodulation":0,"pump":"off"}

Comment: OK

(00:03:08.725) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:03:08.949) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:03:09.487) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 00 05 64 00 00 00 00 (CRC=81) #data=17 <--- SM100Status(0x264) (00:03:09.699) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:03:12.485) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:03:19.860) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:03:20.077) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) (00:03:20.834) 0x09 -> SM, type 0x02 telegram: 09 B0 02 00 03 (CRC=66) #data=1 (00:03:20.866) SM -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25) #data=3 (00:03:20.878) 0x09 -> SM, type 0x96 telegram: 09 B0 96 00 07 (CRC=00) #data=1 (00:03:20.926) SM -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5) #data=7 (00:03:20.948) 0x09 -> SM, type 0xFF00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C) #data=1 (00:03:20.986) SM -> 0x09, type 0x0001 telegram: 30 09 FF 00 00 01 (CRC=70) (00:03:28.890) SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 64 (CRC=37) #data=1 <--- SM100Status(0x264) (00:03:29.346) SM -> all, type 0x026A telegram: 30 00 FF 0A 02 6A 04 (CRC=53) #data=1 <--- SM100Status2(0x26A)

Publishing SM data via MQTT {"collectortemp":43.3,"bottomtemp":33.4,"pumpmodulation":0,"pump":"on"}

Comment: pump goes to on - ok; wrong - pumpmodulation goes to "0x64" = 100% - message 0x264 offset 09 0x64

(00:03:32.908) SM -> all, type 0x0264 telegram: 30 00 FF 09 02 64 1E (CRC=4D) #data=1 <--- SM100Status(0x264) (00:03:38.049) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4

Publishing SM data via MQTT {"collectortemp":43.3,"bottomtemp":33.4,"pumpmodulation":0,"pump":"on"}

Comment: wrong - pumpmodulation switched to 1E = 30% - message 0x264 offset 09 0x1E

(00:04:07.258) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:04:07.292) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9) #data=7 (00:04:07.325) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:04:07.430) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 B1 01 4E 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=B7) #data=24 <--- SM100Monitor(0x262) (00:04:08.108) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:04:08.339) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:04:08.804) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 1E 00 05 64 00 00 00 00 (CRC=06) #data=17 <--- SM100Status(0x264)

Publishing SM data via MQTT {"collectortemp":43.3,"bottomtemp":33.4,"pumpmodulation":30,"pump":"on"}

Comment: now status ok; the full 0x0264 protocol seems to be interpreted correctly

(00:04:09.008) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:04:09.412) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:04:09.626) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 04 03 (CRC=EB) #data=12 <--- SM100Status2(0x26A)

Publishing SM data via MQTT {"collectortemp":43.3,"bottomtemp":33.4,"pumpmodulation":30,"pump":"off"}

Comment: pump status wrong - 0x026A databyte 0A reports (again) x04 - that means pump is and here stays on (status x03 is off)

(00:04:30.820) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 A1 (CRC=8D) #data=2 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"collectortemp":41.7,"bottomtemp":-2944,"pumpmodulation":30,"pump":"off"}

Comment: Collectortemp update ok! WRONG - Why bottomtemp says suddenly "-2944" ????????????????????????????

(00:04:38.164) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:04:46.709) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 95 (CRC=B9) #data=2 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"collectortemp":40.5,"bottomtemp":-1817.6,"pumpmodulation":30,"pump":"off"}

Comment: Collectortemp update ok! WRONG - Why is bottomtemp says now "-1817.6" ????????????????????????????

S-Przybylski commented 5 years ago

Hi @proddy, regarding to the problem of the toogling bottomtemp value, is set up a compete trace and combined it with the mqtt events. Perhaps you can find where the problem comes from. By the way: Is was surprised that my Gb172 presents the pressure with 25.5 - in the past i never had a value for pressure and i am not sure, if thats correct. My heating pressure is between 1,2 and 2 bar...

(00:51:10.646) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:51:10.681) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:51:11.247) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=12) #data=13 (00:51:12.014) Thermostat -> all, type 0x01AF telegram: 10 00 F7 00 FF 01 AF E5 (CRC=2E) (00:51:12.298) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 (CRC=DA) #data=13 (00:51:13.376) SM -> Boiler, type 0x33 telegram: 30 88 33 02 07 (CRC=C0) #data=1 (00:51:13.410) Boiler -> SM, type 0x33 telegram: 08 30 33 02 33 FB 00 1E FF 06 46 (CRC=C9) #data=7 (00:51:13.443) SM -> Boiler, type 0x35 telegram: 30 08 35 02 00 (CRC=BB) #data=1 (00:51:13.547) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 3F 01 44 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=B7) #data=24 <--- SM100Monitor(0x262)

Publishing SM data via MQTT {"collectortemp":31.9,"bottomtemp":32.4,"pumpmodulation":0,"pump":"off"}
Comment: OK

(00:51:13.756) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 01 00 00 00 00 00 00 00 (CRC=5A) #data=13 (00:51:13.984) 0x09 -> SM, type 0x02 telegram: 09 B0 02 00 03 (CRC=66) #data=1 (00:51:14.029) SM -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25) #data=3 (00:51:14.037) 0x09 -> SM, type 0x96 telegram: 09 B0 96 00 07 (CRC=00) #data=1 (00:51:14.082) SM -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5) #data=7 (00:51:14.104) 0x09 -> SM, type 0xFF00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C) #data=1 (00:51:14.146) SM -> 0x09, type 0x0001 telegram: 30 09 FF 00 00 01 (CRC=70) (00:51:14.256) Thermostat -> all, type 0x01AF telegram: 10 00 F7 00 FF 01 AF ED (CRC=26) (00:51:14.580) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:51:14.796) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:51:15.252) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 01 05 64 00 00 00 00 (CRC=C1) #data=17 <--- SM100Status(0x264) (00:51:15.454) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:51:15.898) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:51:16.113) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) (00:51:18.795) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 32 00 00 00 00 04 40 80 00 02 15 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=76) #data=25 <--- UBAMonitorFast(0x18) (00:51:19.028) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:51:19.246) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 15 02 15 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=81) #data=19 <--- UBAMonitorWWMessage(0x34) (00:51:28.780) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 32 00 00 00 00 04 40 80 00 02 16 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=F4) #data=25 <--- UBAMonitorFast(0x18) (00:51:28.998) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:51:29.305) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 16 02 16 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=53) #data=19 <--- UBAMonitorWWMessage(0x34) (00:51:34.298) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 45 (CRC=69) #data=2 <--- SM100Monitor(0x262)

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.9,"wWCurTmp":53.4,"wWCurFlow":0,"curFlowTemp":81.8,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing SM data via MQTT {"collectortemp":32.5,"bottomtemp":2688,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp not ok

(00:51:38.075) Thermostat -> Boiler, type 0x35 telegram: 10 08 35 00 11 11 (CRC=30) #data=2 (00:51:38.766) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 01 00 00 00 00 00 00 00 (CRC=5A) #data=13 (00:51:39.090) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 30 00 00 00 00 04 40 80 00 02 17 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=DA) #data=25 <--- UBAMonitorFast(0x18) (00:51:39.301) Boiler -> all, type 0x19 telegram: 08 00 19 00 00 3B 80 00 80 00 00 00 00 00 03 51 0A 0C 5A 3C 00 00 00 06 BE 54 02 60 31 80 00 (CRC=6F) #data=27 <--- UBAMonitorSlow(0x19) (00:51:39.562) Boiler -> all, type 0x1C telegram: 08 00 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=4B) #data=25 (00:51:39.838) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:51:40.153) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 17 02 17 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=1D) #data=19 <--- UBAMonitorWWMessage(0x34) (00:51:40.523) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:51:43.845) Thermostat -> all, type 0x06 telegram: 10 00 06 00 13 05 0B 04 39 00 05 01 10 FF 00 (CRC=D4) #data=11 <--- RCTime(0x06) (00:51:46.543) Thermostat -> all, type 0x01A5 telegram: 10 00 FF 0D 01 A5 02 97 01 65 (CRC=60) #data=4 <--- RCPLUSStatusMessage(0x1A5) (00:51:48.699) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 2F 00 00 00 00 04 40 80 00 02 18 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=A6) #data=25 <--- UBAMonitorFast(0x18) (00:51:48.913) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:51:49.166) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 18 02 18 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=AC) #data=19 <--- UBAMonitorWWMessage(0x34) (00:51:52.889) Thermostat -> all, type 0x01A5 telegram: 10 00 FF 00 01 A5 80 00 00 30 2C 00 30 28 02 97 03 03 01 02 97 01 65 00 00 11 01 03 FF FF 00 (CRC=FB) #data=25 <--- RCPLUSStatusMessage(0x1A5) (00:51:53.297) Thermostat -> all, type 0x01A5 telegram: 10 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 37 00 3C 01 FF 01 (CRC=C3) #data=14 <--- RCPLUSStatusMessage(0x1A5) (00:51:53.508) Thermostat -> all, type 0x021D telegram: 10 00 FF 00 02 1D 00 00 0A 04 (CRC=01) #data=4 (00:51:53.993) Thermostat -> Boiler, type 0x1A telegram: 10 08 1A 00 00 00 00 (CRC=C4) #data=3 (00:51:54.041) Thermostat -> all, type 0x0167 telegram: 10 00 FF 00 01 67 00 00 (CRC=AB) #data=2 (00:51:58.645) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 2D 00 00 00 00 04 40 80 00 02 19 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=88) #data=25 <--- UBAMonitorFast(0x18) (00:51:58.863) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:51:59.154) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 19 02 19 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=E2) #data=19 <--- UBAMonitorWWMessage(0x34) (00:52:02.408) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 4F (CRC=63) #data=2 <--- SM100Monitor(0x262)

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.9,"wWCurTmp":53.7,"wWCurFlow":0,"curFlowTemp":81.3,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing SM data via MQTT {"collectortemp":33.5,"bottomtemp":2534.4,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp not ok

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.9,"wWCurTmp":53.7,"wWCurFlow":0,"curFlowTemp":81.3,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing hot water and heating states via MQTT 0 Publishing thermostat data via MQTT {"thermostat_hc":"1","thermostat_seltemp":24,"thermostat_currtemp":-3276.8,"thermostat_mode":"auto"}

Publishing SM data via MQTT {"collectortemp":33.5,"bottomtemp":2534.4,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp not ok

Requesting scheduled EMS device data Requesting type RCTime(0x06) from dest 0x10 Requesting type UBAMonitorFast(0x18) from dest 0x08 Requesting type UBAMonitorSlow(0x19) from dest 0x08 Requesting type UBAParameterWW(0x33) from dest 0x08 Requesting type UBAParametersMessage(0x16) from dest 0x08 Requesting type UBATotalUptimeMessage(0x14) from dest 0x08 Requesting type SM10Monitor(0x97) from dest 0x30 (00:52:07.103) Sending read of type 0x06 to 0x10: telegram: 0B 90 06 00 20 (CRC=6C) (00:52:07.193) Thermostat -> me, type 0x06 telegram: 10 0B 06 00 13 05 0B 04 39 17 05 01 10 FF 00 (CRC=43) #data=11 <--- RCTime(0x06) (00:52:08.695) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 2C 00 00 00 00 04 40 80 00 02 19 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=57) #data=25 <--- UBAMonitorFast(0x18) (00:52:08.898) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:52:09.200) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 1A 02 1A 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=30) #data=19 <--- UBAMonitorWWMessage(0x34) (00:52:09.490) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 52 01 44 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 (CRC=16) #data=24 <--- SM100Monitor(0x262) Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.9,"wWCurTmp":53.8,"wWCurFlow":0,"curFlowTemp":81.2,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing SM data via MQTT {"collectortemp":33.8,"bottomtemp":32.4,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp ok

(00:52:09.783) SM -> all, type 0x0262 telegram: 30 00 FF 18 02 62 80 00 (CRC=AE) #data=2 <--- SM100Monitor(0x262) (00:52:10.022) SM -> all, type 0x0263 telegram: 30 00 FF 00 02 63 80 00 80 00 00 00 80 00 80 00 80 00 00 (CRC=74) #data=13 (00:52:10.497) SM -> all, type 0x0264 telegram: 30 00 FF 00 02 64 00 00 00 04 00 00 FF 00 00 00 01 05 64 00 00 00 00 (CRC=C1) #data=17 <--- SM100Status(0x264) (00:52:10.698) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:52:11.041) SM -> all, type 0x0268 telegram: 30 00 FF 00 02 68 0C 00 (CRC=1E) #data=2 (00:52:11.267) SM -> all, type 0x026A telegram: 30 00 FF 00 02 6A 03 03 03 00 03 03 03 03 03 00 03 03 (CRC=E5) #data=12 <--- SM100Status2(0x26A) (00:52:12.308) Sending read of type 0x18 to 0x08: telegram: 0B 88 18 00 20 (CRC=D4) (00:52:12.389) Corrupt telegram: telegram: 0B 88 18 00 20 D4 08 0B 18 00 05 03 2C 00 00 00 00 04 40 80 00 02 1A 80 00 00 00 FF 30 48 00 CB 25 00 00 (CRC=66) #data=31 (00:52:12.706) Boiler -> all, type 0x07 telegram: 08 00 07 00 0B 00 00 00 00 01 00 00 00 00 00 00 00 (CRC=BE) #data=13 (00:52:12.985) Sending read of type 0x19 to 0x08: telegram: 0B 88 19 00 20 (CRC=D0) (00:52:13.063) Boiler -> me, type 0x19 telegram: 08 0B 19 00 00 39 80 00 80 00 00 00 00 00 03 51 0A 0C 5A 3C 00 00 00 06 BE 54 02 60 31 80 00 (CRC=D4) #data=27 <--- UBAMonitorSlow(0x19) (00:52:13.229) Sending read of type 0x33 to 0x08: telegram: 0B 88 33 00 20 (CRC=78) (00:52:13.301) Boiler -> me, type 0x33 telegram: 08 0B 33 00 08 FF 33 FB 00 1E FF 06 46 00 FF FF 00 (CRC=15) #data=13 <--- UBAParameterWW(0x33)

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.7,"wWCurTmp":53.8,"wWCurFlow":0,"curFlowTemp":81.2,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

(00:52:13.506) Boiler -> all, type 0x07 telegram: 08 00 07 00 0B 01 00 00 00 01 00 00 00 00 00 00 00 (CRC=76) #data=13 (00:52:13.827) Sending read of type 0x16 to 0x08: telegram: 0B 88 16 00 20 (CRC=EC) (00:52:13.859) Corrupt telegram: telegram: 88 16 00 20 (CRC=EC) (00:52:13.918) Boiler -> me, type 0x16 telegram: 08 0B 16 00 00 46 64 00 02 FE 05 01 03 64 0A 04 00 00 00 00 00 00 00 00 00 00 00 00 23 00 23 (CRC=1D) #data=27 <--- UBAParametersMessage(0x16) (00:52:15.179) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=12) #data=13 (00:52:16.247) Sending read of type 0x14 to 0x08: telegram: 0B 88 14 00 20 (CRC=E4) (00:52:16.273) Boiler -> me, type 0x14 telegram: 08 0B 14 00 24 59 6F (CRC=5F) #data=3 <--- UBATotalUptimeMessage(0x14) (00:52:16.475) Boiler -> all, type 0x07 telegram: 08 00 07 00 0B 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=3E) #data=13 (00:52:16.540) Sending read of type 0x97 to 0x30: telegram: 0B B0 97 00 20 (CRC=03) (00:52:16.595) SM -> me, type 0x97 telegram: 30 0B 97 00 (CRC=82) (00:52:17.050) Thermostat -> all, type 0x01AF telegram: 10 00 F7 00 FF 01 AF E5 (CRC=2E) (00:52:17.304) Boiler -> all, type 0x07 telegram: 08 00 07 00 0B 01 00 00 00 00 00 00 00 00 00 00 00 (CRC=F6) #data=13 (00:52:17.561) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 00 00 00 00 00 (CRC=DA) #data=13 (00:52:18.570) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 2A 00 00 00 00 04 40 80 00 02 1A 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=25) #data=25 <--- UBAMonitorFast(0x18) (00:52:18.822) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:52:19.029) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 1A 02 1A 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=30) #data=19 <--- UBAMonitorWWMessage(0x34) (00:52:21.720) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 01 00 00 00 00 00 00 00 (CRC=5A) #data=13 (00:52:21.958) Thermostat -> all, type 0x01AF telegram: 10 00 F7 00 FF 01 AF ED (CRC=26) (00:52:22.225) 0x09 -> SM, type 0x02 telegram: 09 B0 02 00 03 (CRC=66) #data=1 (00:52:22.257) SM -> 0x09, type 0x02 telegram: 30 09 02 00 A3 15 04 (CRC=25) #data=3 (00:52:22.270) 0x09 -> SM, type 0x96 telegram: 09 B0 96 00 07 (CRC=00) #data=1 (00:52:22.318) SM -> 0x09, type 0x96 telegram: 30 09 96 00 FF 18 1E 0A 02 50 28 (CRC=B5) #data=7 (00:52:22.346) 0x09 -> SM, type 0xFF00 telegram: 09 B0 FF 00 FF 00 01 (CRC=0C) #data=1 (00:52:22.371) SM -> 0x09, type 0x0001 telegram: 30 09 FF 00 00 01 (CRC=70) (00:52:26.250) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 59 (CRC=75) #data=2 <--- SM100Monitor(0x262)

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.7,"wWCurTmp":53.8,"wWCurFlow":0,"curFlowTemp":81,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing SM data via MQTT {"collectortemp":34.5,"bottomtemp":2995.2,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp not ok

(00:52:27.530) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 29 00 00 00 00 04 40 80 00 02 1B 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=D4) #data=25 <--- UBAMonitorFast(0x18) (00:52:28.518) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:52:28.854) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 1B 02 1B 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=7E) #data=19 <--- UBAMonitorWWMessage(0x34) (00:52:29.137) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 29 00 00 00 00 04 40 80 00 02 1B 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=D4) #data=25 <--- UBAMonitorFast(0x18) (00:52:38.550) Boiler -> all, type 0x19 telegram: 08 00 19 00 00 3B 80 00 80 00 00 00 00 00 03 51 0A 0C 5A 3C 00 00 00 06 BE 54 02 60 31 80 00 (CRC=6F) #data=27 <--- UBAMonitorSlow(0x19) (00:52:38.822) Boiler -> all, type 0x1C telegram: 08 00 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=4B) #data=25 (00:52:39.026) Boiler -> all, type 0x2A telegram: 08 00 2A 00 00 00 00 00 00 00 00 00 DC 00 DC 80 00 00 80 00 80 00 80 00 00 (CRC=35) #data=21 (00:52:39.285) Boiler -> all, type 0x34 telegram: 08 00 34 00 33 02 1C 02 1C 21 00 01 03 00 05 9B E8 00 F0 D9 00 80 00 (CRC=8D) #data=19 <--- UBAMonitorWWMessage(0x34) (00:52:39.597) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 01 00 00 00 00 00 00 00 (CRC=5A) #data=13 (00:52:39.829) SM -> all, type 0x0266 telegram: 30 00 FF 00 02 66 01 62 00 12 (CRC=73) #data=4 (00:52:39.915) Boiler -> all, type 0x18 telegram: 08 00 18 00 05 03 27 00 00 00 00 04 40 80 00 02 1C 80 00 00 00 FF 30 48 00 CB 00 00 00 (CRC=1E) #data=25 <--- UBAMonitorFast(0x18) (00:52:44.102) Thermostat -> all, type 0x06 telegram: 10 00 06 00 13 05 0B 04 3A 00 05 01 10 FF 00 (CRC=14) #data=11 <--- RCTime(0x06) (00:52:45.927) Thermostat -> all, type 0x01A5 telegram: 10 00 FF 0D 01 A5 02 96 01 66 (CRC=67) #data=4 <--- RCPLUSStatusMessage(0x1A5) (00:52:46.208) SM -> all, type 0x0262 telegram: 30 00 FF 00 02 62 01 64 (CRC=48) #data=2 <--- SM100Monitor(0x262)

Publishing boiler data via MQTT {"wWComfort":"Hot","wWSelTemp":51,"selFlowTemp":5,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"outdoorTemp":5.9,"wWCurTmp":54,"wWCurFlow":0,"curFlowTemp":80.7,"sysPress":25.5,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"on","ignWork":"off","wWCirc":"off","wWHeat":"off","ServiceCode":"0H","ServiceCodeNumber":203}

Publishing SM data via MQTT {"collectortemp":35.6,"bottomtemp":1843.2,"pumpmodulation":0,"pump":"off"}
Comment: bottomtemp not ok

proddy commented 5 years ago

ok, made more changes. It's getting quite tricky! 1.7.0b14

proddy commented 5 years ago

also fixed the sys pressure bug, thanks

S-Przybylski commented 5 years ago

quick test: i seems to be much better then before! The four solar collector values are updated as the expected. I can see that the solar pump goes on, adapt the pumpmodulation several times and goes off (the weather today here is good to test). Wow! That quite good!

Do you had time to think about the engergy earnings? Perhaps we can split them into a different topic...

Then it will be a very good first version! Thank you for your support

S-Przybylski commented 5 years ago

Update: I got the energy earnings: {"collectortemp":39.8,"bottomtemp":38.8,"pumpmodulation":0,"pump":"off","energylasthour":136.5,"energytoday":447,"energytotal":3029.4} Cool!

S-Przybylski commented 5 years ago

Hi @proddy regarding the documentation: how could i help to write some details down? I am not familiar with github wiki. Am I able to edit the page https://github.com/proddy/EMS-ESP/wiki/SM100?

proddy commented 5 years ago

I will give you access to the wiki so you can edit the SM100 page, that'll be great. Check your github notifications for the request.

So for the SM100 are we good to go or is there still some more fixes needed?

S-Przybylski commented 5 years ago

Dear @proddy i suggest to document based on the following content structure:

General SM100 EMS+ Device
Link to Buderus official link to Buderus Homepage / Device guides - if available
Decoded Messages table with details of known protocols and examples
Home Assistant / [optional Grafana/InfluxDB] simple Example

Is that OK for you? I try to work on that the next days Status SM100 EMS+ - coding finished (Version 1.0); documentation: open

proddy commented 5 years ago

that'll be very helpful for others, thanks.

S-Przybylski commented 5 years ago

Dear @proddy i just finished the SM100 EMS+ documentation in version 1. Please have a look at it.

I have one question to you: Could you please change the implementation to always send all json elements? When the ESP8266 starts some json elements are not part of the mqtt message. Then Home Assistant throws an warning. A better solution could be, that instead of nothing a "0" or in case of the pump an "off" could be send.

proddy commented 5 years ago

That's awesome @S-Przybylski , nice job! Very clear. Thanks for taking the time to document it.

As for the MQTT I changed all the logic in version 1.7 to only send json elements if there was actual data. Before it sent everything and systems like Home Assistant would complain about elements with values of "?". Also some users feed the MQTT data into other systems like Gafana so it's important to send real data in their correct format (e.g. as floating point numbers). In your example of the pump it would be misleading to send an 'off' value when we don't really no if it is really on or off right?

Which elements are giving you errors in HA?

S-Przybylski commented 5 years ago

Dear @proddy I checked the warnings. It seems that only the binary-sensors have problems with that. That means that only the pump is affected. Due to the fact that the pump will be updated every minute, the issue is more or less of cosmetic nature. Please leave it as is! Should we close the issue now?

proddy commented 5 years ago

yes we can close this issue, but before you do I'm still interested in what error you see in HA and see he we can resolve it

S-Przybylski commented 5 years ago

Here are the messages after a reboot of the ESP: 2019-05-11 12:43:51 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Solar Pump with state_topic: home/ems-esp/sm_data 2019-05-11 12:43:52 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Solar Pump with state_topic: home/ems-esp/sm_data

HA binary sensor definition: value_template: '{{ value_json.pump }}' Perhaps a additional check in the HA binary sensor template could avoid the warning. Do you have an example to check that?

proddy commented 5 years ago

i think you would need to add some conditional logic to the value_template. Something like

- platform: mqtt
  name: 'Solar Pump'
  state_topic: 'home/ems-esp/sm_data'
  value_template: >
    {% if value_json is defined %} {{ value_json.pump }}
    {% else %} {{ false }}
    {% endif %}

but haven't checked if it works. If you post a question on the HA forum I'm sure you'll get lots of useful advice.

S-Przybylski commented 5 years ago

Dear @proddy update: I played with your example a little bit, but without success. The warning appeared again... I tried several different variants, like: value_template: >- {%- if value_json.pump is defined %} {{ value_json.pump }} {%- else %} {{ false }} {% endif %}

Could it be better (faster and more reliable) to set up only one MQTT sensor to catch the whole json and derive template sensors for all attributes?

proddy commented 5 years ago

not sure what you mean. There is one topic and one payload. There must be a general pattern that others used but haven't looked into it.

S-Przybylski commented 5 years ago

Dear @proddy My idea was to get all values by one mqtt sensor and then use a template to act on needed attributes (example history graph). Note: One value is double in the SM100 sensor. First as an state and second as an attribute. For my test i used the collector temp, because its a value which will is updated every minute:

sensors.yaml:
- platform: mqtt
  state_topic: 'home/ems-esp/sm_data'
  name: 'SM100'
  unit_of_measurement: '°C'
  value_template: '{{ value_json.collectortemp }}'
  json_attributes_topic: 'home/ems-esp/sm_data'
  qos: 1
  payload_available: "online"
  payload_not_available: "offline"

binary_sensors.yaml:
- platform: template
  sensors:
    sm100pump:
      friendly_name: "SM100 Pump"
      value_template: >-
       {% if is_state_attr('sensor.SM100','pump', 'on') %} {{ true }}
       {% elif is_state_attr('sensor.SM100','pump', 'off') %} {{ false }}
       {% endif %}

Its working fine without any warnings. On the con side a missing pump value is interpreted as "off".

DarthMob commented 5 years ago

Hi guys,

first off all thanks - i tried the latest (1.7.1) version on my SM50 and ihr works! However in mqttt i get a minus value for the energytotal "home/ems-esp/sm_data: {"collectortemp":16.8,"bottomtemp":57,"pumpmodulation":0,"pump":"off","energylasthour":0,"energytoday":14611,"energytotal":-1263.5} "

in telnet mode - info however it shows up correct:

Solar Module stats: Collector temperature: 19.4 C Bottom temperature: 57.3 C Pump modulation: 0 % Pump active: off Energy Last Hour: 0.0 Wh Energy Today: 14611 Wh Energy Total: 1263.5 kWH

What am I doing wrong?

proddy commented 5 years ago

@DarthMob looks like a bug. Can you do a log v and capture a few telegrams that start with 30 00 FF 00 02 8E so I can reproduce.

DarthMob commented 5 years ago

Thanks for the fast reply @proddy Please find attached the log. Hope this can clear things up...? log.txt

S-Przybylski commented 5 years ago

Dear @DarthMob
i just tried a quicktest using EMS-ESP version 1.8.0b9. With my SM100 everything works as expected. All values are positive:

{"collectortemp":19.7,"bottomtemp":40.3,"pumpmodulation":0,"pump":"off","energylasthour":0,"energytoday":1616,"energytotal":3137.7}

Regarding your logfile: I do not find any EMS+ 0x28E message in your logfile. Perhaps you should capture the log more than one hour to get that message.

emsesp / EMS-ESP

Add SM100 EMS-Plus device #96

Comment: temp and bottomtemp correct! pumpmodulation from log file perspective unknown

Comment: no need to repeat value; no new value or update given; missing temp

Comment: all three values ok; missing pump (refer to 0x26A)

Comment: no need to repeat value; no new value or update given; missing temp and pump (both from older values)

Comment: missing temp (from older value) and pump (refer to 0x26A)

Comment: Status seems to be ok; missing protocol details

Comment: OK

Comment: pump goes to on - ok; wrong - pumpmodulation goes to "0x64" = 100% - message 0x264 offset 09 0x64

Comment: wrong - pumpmodulation switched to 1E = 30% - message 0x264 offset 09 0x1E

Comment: now status ok; the full 0x0264 protocol seems to be interpreted correctly

Comment: pump status wrong - 0x026A databyte 0A reports (again) x04 - that means pump is and here stays on (status x03 is off)

Comment: Collectortemp update ok! WRONG - Why bottomtemp says suddenly "-2944" ????????????????????????????

Comment: Collectortemp update ok! WRONG - Why is bottomtemp says now "-1817.6" ????????????????????????????

Comment: OK

Comment: bottomtemp not ok

Comment: bottomtemp not ok

Comment: bottomtemp not ok

Comment: bottomtemp ok

Comment: bottomtemp not ok

Comment: bottomtemp not ok