map data and command structure to km200's semantic taxonomy

[proddy]

From discord @tp1de requested to map the fields closer to the naming used on the km200 interface, which uses a path-like taxonomy.

I agree the names in the MQTT keys and the commands should match, so will fix that, but not sure about changing the complete structure. I don't want to change the MQTT topic names (boiler, thermostat...) or the command structure (temp) and the MQTT payloads need to remain short so using long paths wouldn't work. Then there's the restful API which takes a single cmd too. What would help is a real-life use case example to work through.

---

Also to create a table in the wiki to show: (a) is the field writable? (b) what is the datatype of the field (boolean, number,char) (c) what are valid entries / number ranges? (d) what is the unit of measure?

In the buderus km200 rest-api interface I get this information back (encrypted) and it looks like this:

object id: "/heatSources/actualPower" type: "floatValue" writeable: 0 recordable: 1 value: 4.4 unitOfMeasure: "kW" ... ...... and with allowed values for example:

object id: "/heatingCircuits/hc1/operationMode" type: "stringValue" writeable: 1 recordable: 0 value: "auto" allowedValues: array[2] 0: "auto" 1: "manual"

[proddy]

https://github.com/emsesp/EMS-ESP32/issues/30

[tp1de]

From discord @tp1de requested to map the fields closer to the naming used on the km200 interface, which uses a path-like taxonomy.

My recommended priorities are:

(1) use field names wich are as close to km200 and are self explanatory and unique. E.g.:

hc2.actualSupplyTemperature vs hc2.flowTempHc (from mixer) hc2.supplyTemperatureSetpoint vs hc2.flowSetTemp

The field names for command should be the same for read / write. If unique then no device has to be selected for command mode.

(2) Integrate hc datafields from mixer into the respective datafields of thermostat (see above) and pump status (hc active) Just keep valveStatus and id in mixer

(3) There could be more and more hybrid systems (gas and heatpump) in the future. Therefore just using "boiler" is not good enough. In km200: heatsources.hs1 .....hs2 is better. The same for hot water - more then one dhw-system is possible (I was thinking about it because I have one system for 2 houses)

Anyhow heatsources and domestic hot water (dhw) are seperate entities and should not just be together in "boiler".

(4)

Also to create a table in the wiki to show: (a) is the field writable? (b) what is the datatype of the field (boolean, number,char) (c) what are valid entries / number ranges? (d) what is the unit of measure?

By best case these info is replied by web api (info command per field). Then it could be seamless integrated into an ha adapter (ioBroker or simimilar) which reads availabe datafields and attributes. If this is not posssible a respective data-file (csv) should be available for integration to avoid mistakes and supports future changes and additions.

[MichaelDvP]

I agree the names in the MQTT keys and the commands should match, so will fix that

This was the only part i fully agree.

• the mentioned structure is NOT from KM200, it is the object-structure from ioBroker, only the url-path is from KM200.
• KM200 is very rare for ems-esp-users, it's not a good reference
• KM200 only supports RC3x0 thermostats and only a small subset of commands. For all other systems it's not a reference.
• as read somewhere else Bosch changes KM200 parameters and fields with updates often.
• nearly all information (writable/unit/range) are mentioned in the wiki (hopefully people know that percent ranges 0-100). Some valid ranges differ for different boilers/thermostats and can not be fixed to a single range.

[tp1de]

@MichaelDvP @proddy I think I shall stop trying to convince you about making changes, since you do not want to follow. That's a fair statement and I will not add value if I continue to do so.

But please give me a last chance to comment:

I agree the names in the MQTT keys and the commands should match, so will fix that

• good to see that MQTT key names should match for read and write. What about of making them unique, so that no device name is needed on command?

the mentioned structure is NOT from KM200, it is the object-structure from ioBroker, only the url-path is from KM200.

• NOT TRUE. This structure and the respective datafields (definition and values) are the responses from km200 rest api get requests - nothing to do with ioBroker. Same data for symcon, loxone, openhab, etc. system integration by reading km200.

KM200 is very rare for ems-esp-users, it's not a good reference

• NOT TRUE. Since about 3-4 years most boilers from Bosch group brands have IP-inside (km200 functionality) by standard. Older system can be equipped with km50,km100,km200 or km300 interfaces ....... or ems-esp!

KM200 only supports RC3x0 thermostats and only a small subset of commands. For all other systems it's not a reference.

• The enduser interface of the km200 is done by web or respective app. App functionality is lower then on Bosch / Junkers Homecon Portal. To use the portal or app an internet connection of the boiler is needed. The polling by http get commands to km200 is done on local network - like ems-esp. All enduser control commands are on the km200 available. Key functions are changing of timeswitch programs per hc and dhw and respective temp settings, holiday modes and followup on energy consumption and temp-levels. Not all of this functionality is available on ems-esp yet. Additionally ems-esp is able to change ww-circulation (will be added to km200 in 2021) and changing of control parameters.
• I believe that ems-esp has the potential to become the better km200 interface in sense of responsiveness, functionality and ease of use (no data encryption) for home automation systems. **If this is a target of ems-esp to be an end-user ready interface then stability and foolproof to avoid wrong data entry needs to be build in.** Otherwise it should only be used by experts who know and accept the consequences up to stillstand of heating system.

as read somewhere else Bosch changes KM200 parameters and fields with updates often.

• Yes I made the comment. Not often since updates come every 2-3 months. Compared to ems-esp the changes are much less frequently.

nearly all information (writable/unit/range) are mentioned in the wiki (hopefully people know that percent ranges 0-100). Some valid ranges differ for different boilers/thermostats and can not be fixed to a single range.

• You are certainly aware that the wiki is not 100% up to date. I do have 2 remarks:

1. It is technically possible to send commands with wrong values out of defined range. This brings the heating system to error mode or stop. This happend to me with wrong values for boiler hysteresis. The ems-esp software should do some checks for value ranges and reply with errors if wrong values are send.
2. If valid ranges would be available by rest-api like on km200, then this check can be done already by the home-automation frontend (ioBroker, Loxone, Openhab). I just recommend not to be dependend on wiki to secure stable operation while using the mighty ems-esp functionality.

I strongly believe in the capabilities of the ems-esp software to have the possibility to give better functionality to endusers compared to Bosch group interfaces. So why not using existing km200 datafield names and inventing new ones?

[MichaelDvP]

I think I shall stop trying to convince you about making changes, since you do not want to follow.

I think you get something wrong. Proddy opend this issue because he seems to be always open minded to changes. It's only my opinion to this suggestion. But it's proddys project, he decide and may have other opinions.

his structure and the respective datafields (definition and values) are the responses from km200 rest api get requests - nothing to do with ioBroker.

Maybe, i've only seen the structure in #30, which was from ioBroker. If you have a documentation about the api i will look into.

Older system can be equipped with km50,km100,km200 or km300 interfaces

https://www.buderus-connect.de/connect-check/ say that i also have to buy a RC310 and my RC35 is not compatible.

You are certainly aware that the wiki is not 100% up to date.

No, i think it's up date, if you find something worng, there is a Improve this article on every page.

It is technically possible to send commands with wrong values out of defined range

Yes, but my experience is, that boiler and thermostat do not accept values out of range. The possible ranges are different on different boilers, and not always known. Also write commands not working on every system the same way. There are a lot of discussions about wwonetime, circulation, wwactivated, etc. I think that's also one reason why Bosch limits KM200 to RC310 and only few parameters, it has to be fool-proof, or Bosch gets sued.

My opinion is, keep ems-esp open for all ems/ems+/ht3 systems. Improve parameter names, but keep them as translation of the paper-handbook names. The device oriented data-structure allows to add future devices. Like MC400 in #739 as boiler, where we will add heatingsources to the boiler device in the same way mixers are matched to hcs.

[proddy]

I think you get something wrong. Proddy opend this issue because he seems to be always open minded to changes. It's only my opinion to this suggestion. But it's proddys project, he decide and may have other opinions.

That is true! I'm sometimes too optimistic and like to say yes to everything. Michael is my "common sense" and keeps me real. Thing is, I have an old Nefit boiler and an old RC20 so I'm no expert when it comes to km200 gateways, solar modules and mixers. This is where Michael comes in. Another thing to remember is although EMS-ESP was my hobby project I would love if it could be something more and help more people. This idea behind GitHub was to bring in various contributors (not just users) with their ideas and own code to enhance it. But it needs to keep everyone happy.

My opinion is, keep ems-esp open for all ems/ems+/ht3 systems. Improve parameter names, but keep them as translation of the paper-handbook names. The device oriented data-structure allows to add future devices. Like MC400 in #739 as boiler, where we will add heatingsources to the boiler device in the same way mixers are matched to hcs.

This is my opinion too. Aligning the naming of the API commands and MQTT names makes sense and we should do that.

For your specific 'problem' @tp1de perhaps it could be new format at some point, similar to how I added the Home Assistant work. But then I think there are probably better tools for this like node-red.

[proddy]

we can adopt some of these suggestions in #50