New boiler and thermostat (Bosch CW400/Condens GC9000/Solar Module)

[suysh]

Hello,

I just got my ems-esp interface working, after a scan I received the following text:

These device IDs are on the EMS Bus: 0x08 0x10 0x16 0x20 0x21
and 5 were recognized by EMS-ESP as:
 Buderus Logamax plus/GB192 (DeviceID:0x08 ProductID:208 Version:01.04)
 RC300/RC310/Moduline 3000 (DeviceID:0x10 ProductID:158 Version:18.06)
 unknown? (DeviceID:0x16 ProductID:220 Version:01.05)
 MM100 Mixing Module (DeviceID:0x20 ProductID:160 Version:24.05)
 MM100 Mixing Module (DeviceID:0x21 ProductID:160 Version:24.05)

You have a device is that is not known by EMS-ESP. Please report this as a GitHub issue so we can expand the EMS device library.

There is also an unknown device, don't know what and how to discover, but I have the following installation. Not all are active, the sunboiler will be installed next weeks.

Thermostat = Bosch CW400 Boiler=Bosch Condens GC9000iWM SB 30kW/150L Solar=HDS RO 40C 400L Solar=FT V 226

Let me know if you want more information about my installation. Happy if I can help :-) Kind regards, Hans

[proddy]

Hi @suysh, welcome and thanks for reporting this info. I've updated the database (in the dev 1.9.2 branch for now). The unknown device must be either one of the dormant devices. When its all connected lets have a look again and see if we extract the solar data from them.

I'll leave this issue open so we can track it.

[suysh]

Hi @proddy . I'm running version 1.9.1 and get in the dashboard for the boiler temperature an "undefined °C". And when looking in the mqtt payload there is no value coming close to what is displayed on my thermostat. Shall I first try with your latest beta version? Can you reply with the download link for the compiled bin ? Kind regards, Hans

[proddy]

You can always try the 1.9.2 nightly build although I expect the behavior is the same. We may need to fine tune for your boiler.

Can you try 1.9.2, then in telnet do an log v and send me a couple of the telegrams, like types 0x18 and 0x19 so we can decipher the data.

thanks for helping out

[suysh]

Downloaded 1.9.2 , but same behaviour. Let me know if you need more data. Regards, Hans (00:01:48.577) Boiler -> all, type 0x18, telegram: 88 00 18 00 19 01 A9 64 00 01 01 C0 40 01 8B 02 20 01 06 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=E5) #data=27 <--- UBAMonitorFast(0x18) (00:01:48.785) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (00:01:57.977) Boiler -> all, type 0x18, telegram: 88 00 18 00 19 01 A9 64 00 01 01 C0 40 01 8B 02 22 01 05 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=4B) #data=27 <--- UBAMonitorFast(0x18) (00:01:58.210) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (00:02:08.252) Boiler -> all, type 0x18, telegram: 88 00 18 00 19 01 A8 64 00 01 01 C0 40 01 8B 02 20 01 05 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=30) #data=27 <--- UBAMonitorFast(0x18) (00:02:08.560) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (00:02:12.795) Sending read of type 0x18 to 0x08, telegram: 8B 88 18 00 20 (CRC=1C) (00:02:12.852) Boiler -> me, type 0x18, telegram: 88 0B 18 00 19 01 A8 64 00 01 01 C0 40 01 8A 02 20 01 06 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=14) #data=27 <--- UBAMonitorFast(0x18) (00:02:13.194) Sending read of type 0x19 to 0x08, telegram: 8B 88 19 00 20 (CRC=18) (00:02:13.252) Boiler -> me, type 0x19, telegram: 88 0B 19 00 00 BC 80 00 80 00 00 00 00 00 00 04 1C 00 4A B0 00 00 00 00 43 58 00 03 24 00 DD (CRC=07) #data=27 <--- UBAMonitorSlow(0x19) (00:02:18.002) Boiler -> all, type 0x18, telegram: 88 00 18 00 19 01 A8 64 00 01 01 C0 40 01 8A 02 20 01 05 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=68) #data=27 <--- UBAMonitorFast(0x18) (00:02:18.235) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (00:02:28.252) Boiler -> all, type 0x18, telegram: 88 00 18 00 19 01 A8 64 00 01 01 C0 40 01 8A 02 20 01 05 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=68) #data=27 <--- UBAMonitorFast(0x18) (00:02:28.485) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) `

[proddy]

can you also give example values of what is shown on the boiler? Let's fix that first and then move on to the CW400 Thermostat which has different device telegrams. So 0x18 and 0x19 are important for now (which you provided)

[suysh]

The thermostat reads 54.9°C for boiler temperature.

(23:28:04.295) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 98 00 00 00 00 40 40 01 88 02 24 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=B7) #data=27 <--- UBAMonitorFast(0x18) (23:28:04.578) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (23:28:12.920) Boiler -> me, type 0x18, telegram: 88 0B 18 00 05 01 98 00 00 00 00 40 40 01 88 02 25 00 F5 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=D6) #data=27 <--- UBAMonitorFast(0x18) (23:28:13.188) Sending read of type 0x19 to 0x08, telegram: 8B 88 19 00 20 (CRC=18) (23:28:13.245) Boiler -> me, type 0x19, telegram: 88 0B 19 00 00 8D 80 00 80 00 00 00 00 00 00 04 1E 00 4A BE 00 00 00 00 43 58 00 03 24 01 01 (CRC=E1) #data=27 <--- UBAMonitorSlow(0x19) (23:28:14.370) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 98 00 00 00 00 40 40 01 88 02 25 00 F5 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=28) #data=27 <--- UBAMonitorFast(0x18) (23:28:14.678) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (23:28:14.945) Boiler -> all, type 0x19, telegram: 88 00 19 00 00 8D 80 00 80 00 00 00 00 00 00 04 1E 00 4A BE 00 00 00 00 43 58 00 03 24 01 01 (CRC=1F) #data=27 <--- UBAMonitorSlow(0x19) (23:28:24.071) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 98 00 00 00 00 40 40 01 88 02 25 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=A1) #data=27 <--- UBAMonitorFast(0x18) (23:28:24.354) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (23:28:34.796) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 98 00 00 00 00 40 40 01 86 02 25 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=9A) #data=27 <--- UBAMonitorFast(0x18) (23:28:35.004) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (23:28:44.646) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 98 00 00 00 00 40 40 01 86 02 24 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=8C) #data=27 <--- UBAMonitorFast(0x18) (23:28:44.904) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18)

[suysh]

With the latest firmware, the mqtt payload structure is changed (=improved, thanks for this) and also new parameters added (great work). I'm using OpenHAB as smarthome interface. All parameters are not completely clear what they mean, but I'm logging/charting now all to figure out understanding the functions.

[suysh]

Just to verify, boiler temp = 54.8°C

(23:48:14.001) Sending read of type 0x18 to 0x08, telegram: 8B 88 18 00 20 (CRC=1C) (23:48:14.059) Boiler -> me, type 0x18, telegram: 88 0B 18 00 05 01 8E 00 00 00 00 40 40 01 85 02 24 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=7C) #data=27 <--- UBAMonitorFast(0x18) (23:48:14.376) Sending read of type 0x19 to 0x08, telegram: 8B 88 19 00 20 (CRC=18) (23:48:14.433) Boiler -> me, type 0x19, telegram: 88 0B 19 00 00 8D 80 00 80 00 00 00 00 00 00 04 1E 00 4A BE 00 00 00 00 43 58 00 03 24 01 01 (CRC=E1) #data=27 <--- UBAMonitorSlow(0x19) (23:48:14.834) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 8F 00 00 00 00 40 40 01 85 02 24 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=D5) #data=27 <--- UBAMonitorFast(0x18) (23:48:15.117) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18) (23:48:15.334) Boiler -> all, type 0x19, telegram: 88 00 19 00 00 8D 80 00 80 00 00 00 00 00 00 04 1E 00 4A BE 00 00 00 00 43 58 00 03 24 01 01 (CRC=1F) #data=27 <--- UBAMonitorSlow(0x19) (23:48:24.609) Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 8F 00 00 00 00 40 40 01 85 02 24 00 F4 00 00 12 00 00 00 CB 00 00 00 00 00 (CRC=D5) #data=27 <--- UBAMonitorFast(0x18) (23:48:24.867) Boiler -> all, type 0x18, telegram: 88 00 18 1B 00 00 00 00 00 00 00 00 00 00 00 (CRC=5C) #data=11 <--- UBAMonitorFast(0x18)

[suysh]

In the dashboard the selected flow temperature is as 5°C displayed. Probably this is wrong. Below I uploaded my logs for today. Maybe this helps understanding my system. selFlowTemp: wWCurTmp: curFlowTemp: retTemp:

[suysh]

Graphs are always showing more than single values. Let me know if you want more information. Your improvements and work is highly appreciated !!!

[proddy]

this looks all good at first glance. If you go to telnet and type info which values don't have values?

[proddy]

BTW the boiler temp is the 3rd byte of the data block from a 0x19 telegram. in your examples it has the value 0x80 which literally means "unsupported". So its worked as expected. Why there is no boiler temp, I don't know. I've seen this before where Bosch Worcester don't use the standard Buderus formats.

[suysh]

The telnet shows no values for "Boiler temperature: ? C". All the others have values. I'm also trying to understand my boiler operation. It's one system that combines solar+gas for floor heating+radiators+tap water, all in one system.

[proddy]

Ok, thanks for checking. Do you see System Pressure ?

[suysh]

yes, pressure is OK.

[proddy]

let's get CW400 working. Can you confirm it shows up as (DeviceID:0x10 ProductID:158 Version:18.06) when doing an autodetect with the latest 1.9.3 or 1.9.4.

[proddy]

The CW400 is EMS+ and we're still working out the telegrams and using the Wiki to capture out findings. See here.

For HC1 we know the telegram type ID is 0x01B9. I suspect HC2 is 0x01BA but cannot confirm.

Could you do a manual test and check? set verbose logging, use thermostat temp to set the temp on HC1. Look at the telegram that is sent (in light blue). Replace the 01 B9 with 01 BA and see if that works for HC2.

report back in this github issue.

[proddy]

CW400 also requested in https://github.com/proddy/EMS-ESP/issues/222

[moustic999]

I confirm that hc1 is 01B9, hc2 is 01BA.... till hc4 01BC for 01BA, format is same than 01B9....

That's also what is in ht3 code ;-)

[proddy]

great, thanks @moustic999 for confirming. This is how I just coded it.

@suysh please try again with thermostat temp 2 22 to see if the setpoint temp on HC2 changes to 22.0 degrees

[suysh]

The thermostat temp 2 22 is now working. Thanks for updating. Same error effect when I try thermostat mode 2 1 then HC1 changes to manual instead of HC2.

[proddy]

@suysh can you see if mode works now. take the latest dev, either directly from github or use the Web UI

[suysh]

@proddy I'm still looking for my boiler temperature in the telegrams. The EMS+ telegram structure looks very interesting and I want to dive in, but have some related questions. Am I right if I can say that every device has a list of registers (types) that can be updated starting from offset 0 or any other value, and can write/read any amount of data ?

Does the code keeps somewhere the latest status of all these registers for all devices ? Can I lookup these registers somewhere ? Maybe better already splitted in the known and unknown usable parameters. I ask this because I stared at my screen and all telegrams are scrolling continiously and so it's difficult to keep track of changing values in certain telegrams to find what I'm looking for. Do I need to manually copy paste the telegram data in a text editor and try to unpack and search for unknown parameters ?

[proddy]

each device has telegram messages that are used to either send information, write information or both. For example if you try and send to type ID 0x02 (version) the UBA master will either respond with an echo or nothing at all.

The code keeps the latest status of specific values extracted from known telegram messages. These are only the values that I know mean something. This code is in ems.cpp and the idea is to keep the raw data and leave the post-processing up to other parts of the code later. For example temperatures are typically sent as two-bytes and multiplied by 10. The rendering the division is only done during MQTT payload generation.

I think we have must of the known telegrams covered already. Is there something specific you're looking into?

Currently I'm adding more type IDs which I listed in https://github.com/proddy/EMS-ESP/wiki/MC110-controller

[suysh]

I just tested the thermostat mode 1 1 and it worked as expected ! Thanks for fixing.

I think I found my boiler temp in the type 0x18 telegram. Boiler -> all, type 0x18, telegram: 88 00 18 00 05 01 BC 00 00 00 00 40 40 01 91 [02 2E] 01 0C 00 00 11 00 00 00 CB 00 00 00 00 00 (CRC=31) #data=27 The double byte 02 2E = 558 divided by 10 corresponds to my boiler temp on my thermostat. I checked a few times and it always is correct. Can you add this value?

I'm also looking for my heating pumps. None of the existing parameters matches when my floorheating pump or radiator pump is active. This is a bit harder to check because they don't switch that frequently.

[proddy]

before I do that can you post a few 0x19 telegrams. This is where the boiler temp is for other boilers and I don't want the value to conflict. do boiler read 19

I get:

UBAMaster -> Me, type 0x19, telegram: 08 0B 19 00 80 00 [01 B8] 80 00 00 00 00 3C 03 91 78 05 B8 1E 00 00 00 04 92 94 00 5E ED 80 00 (CRC=E7) #data=27

and the temp is bytes 3 & 4 of the data block, 0x01B8, 44.0 degrees in my case

If you get 0x8000 thats good news

[suysh]

If you can port it to a testing variable it's also good for me to test. I can log and see if it is always correct for my boiler type. When looking closer to the part of that telegram that is not specified in you docs, it seems that the 2 bytes before and after the boiler temp also changes. Can you also add to a test variable ?

The boiler temp is always a big value = n.a. (21:21:55) Sending read of type 0x19 to 0x08, telegram: 8B 88 19 00 20 (CRC=18) (21:21:55) Boiler -> me, type 0x19, telegram: 88 0B 19 00 00 42 80 00 80 00 00 00 00 00 00 04 E1 00 57 6A 00 00 00 00 4D CC 00 03 B4 01 2D (CRC=B9) #data=27 (21:21:52) Boiler -> all, type 0x19, telegram: 88 00 19 00 00 42 80 00 80 00 00 00 00 00 00 04 E1 00 57 6A 00 00 00 00 4D CC 00 03 B4 01 2F (CRC=45) #data=27 <--- UBAMonitorSlow(0x19) (21:20:56) Sending read of type 0x19 to 0x08, telegram: 8B 88 19 00 20 (CRC=18) (21:20:56) Boiler -> me, type 0x19, telegram: 88 0B 19 00 00 42 80 00 80 00 00 00 00 00 00 04 E1 00 57 6A 00 00 00 00 4D CC 00 03 B4 01 2F (CRC=BB) #data=27 <--- UBAMonitorSlow(0x19)

[suysh]

Is there a way to only print telegrams of a specific type, and by preference only the telegram data without any other text. Just to search for changing data (or missing information).

[proddy]

log j or log r but both probably not what you're looking for. i can add a new log mode.

[proddy]

see if you get boiler temps now with the latest dev

[suysh]

That should be very practical if you can add a log mode that only displays a certain type and only the raw data.

[suysh]

Yes, boiler temp is now present and correct ! Thanks

[proddy]

That should be very practical if you can add a log mode that only displays a certain type and only the raw data.

like watch 18 ?

[suysh]

The log watch mode is working as expected, but the verbose logging is printing as in watch mode with filtering the last passed watch parameter. You can try to log w 18. Then try log v and see that the output is filtered by telegram type 18. After reboot the parameter is empty and with log v there is no printing. Can you check the code change ?

[suysh]

How can I print the EMS+ telegrams existing of 4bytes? log w 18 prints all type 18 log w BF prints all type BF log w FF 0F 01 is not working

[proddy]

lol. wise guy! I thought of this when implementing it but hoped no one would notice. I need to adjust the code to support 2-byte shorts for EMS+. I'll do it tomorrow

[suysh]

No problem ! ;-) Is there a way to get out data from a telegram to mqtt? I'm thinking of a way to log/test some data to find slowly changing parameters.

[proddy]

How can I print the EMS+ telegrams existing of 4bytes? log w 18 prints all type 18 log w BF prints all type BF log w FF 0F 01 is not working

I looked at the code and tested for EMS+ and it works. e.g. log w 1b9. The argument is the the type ID in hex. In your example FF 0F 01 is not a type ID.

[proddy]

No problem ! ;-) Is there a way to get out data from a telegram to mqtt? I'm thinking of a way to log/test some data to find slowly changing parameters.

It'll be some work and extra code to send out the the whole telegram via MQTT, and it will create a lot of data. But I'm not sure how you're going to capture all the data on the other side? Perhaps a better idea is to use the event log?

[proddy]

@susisstrolch created a nifty script (he called it a torture script!) to capture telegrams to a file back in the old ages. So you could do something similar with:

#!/bin/bash
COUNT=0

while true; do
LOGFILE="emsbus-$(date +'%Y%m%d-%H%M%S').log"
touch $LOGFILE
ln -sf $LOGFILE emsbus.log
echo "monitor loop $COUNT - $LOGFILE"
cat <<EOC|nc -w 30 192.168.1.10 telnet >$LOGFILE
log w 1B9
EOC
stripansi -i $LOGFILE
let "COUNT++"
done

then replace the IP address obviously.

[proddy]

@suysh log w and log r will send telegrams to a syslog. If you need help setting up a syslog server let me know. On Linux there is usually one running, either rsyslog or ng-syslog.

[suysh]

@proddy Some help would be appreciated. I'm running OpenHABian on a Raspberry Pi. I'm looking for my 2 heating pumps connected to my floorheating and radiators. Yesterday I also searched for the energy consumption with the values shown on my thermostat. Tried to find same values or x10 or x1000 to retrieve in the telegrams. But still no luck, maybe this is only transmitted with a long interval.

[proddy]

This page shows how to enable syslog on a RPI. You could capture a few logs over 20 mins and then do some searching for patterns.

[suysh]

rsyslog is installed. But how to configure and catch the telegrams ? Do you have an example of the config file ? I copy/paste it from your link, changed IP-adres. Then start telnet and enable log r. Then the .log file should be created where also the other log files are ?

[proddy]

yes, log r should send all the logs to syslog. I just checked the code and realized I made a typo, so will have to fix that this weekend. Sorry.

[suysh]

The webinterface from 1.9.4b18 is now running smoothly in my system. But the boiltemp is not in the mqtt any more. Can you check? It was there in the previous version. I get it from another telegram location, see some posts above.

[proddy]

think I fixed it. I made a change for someone else that had problems with boiltemp (apparently its reported on multiple telegram types)

[suysh]

In the log from mqttlog I see the following: (compared to the "info" information in Telnet Possibly there are } missing at the end of some Payload strings ? The boilTemp is rounded to 1 degree now. I get following error:

[MQTT] Error publishing to ems-esp/mixing_data with payload {"hc1":{"flowTemp":3276.8,"pumpMod":0,"valveStatus":0},"hc2":{"flowTemp":22.8,"pumpMod":0,"valveStatus":0}} [error 0]

[suysh]

Update : seen from the mqtt log in the webpage all looks correct.

[proddy]

I see that too. Looking into it.