Binding Request : Buderus web gateway

Hello Markus,

as the 2.5.7-Update killed my installation (file system read-only, no way back) I had to reinstall.
(Not caused by the binding !)
Because there are only some bindings configured up to now and the log is very clean, I noticed that there is a warning from the binding stating that the switch programs A and B are not supported.

2020-07-27 17:06:55.144 [INFO ] [internal.handler.KM200GatewayHandler] - Update KM50/100/200 gateway configuration, it takes a minute…
2020-07-27 17:07:00.148 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing ‘km200:kmdevice:817210159’ takes more than 5000ms.
2020-07-27 17:09:05.493 [INFO ] [l.handler.KM200VirtualServiceHandler] - No references for switch service: /heatingCircuits/hc1/switchPrograms/A, this is not supported
2020-07-27 17:09:05.497 [INFO ] [l.handler.KM200VirtualServiceHandler] - No references for switch service: /heatingCircuits/hc1/switchPrograms/B, this is not supported

Maybe this is something you could have a look at.

Greetings Oggerschummer

Hi Markus. Many thanks for creating this. Its working quite well on my IVT heat pump system. Im wondering would it be possible to get the binding to provide the energy consumption from my system? The iphone app shows Total Heat Output, Total Electrical Consumption and Electrical Consumption of The Electrical Booster Heater. Im wondering if these are available to the binding? It shows in the log file I believe as below but I dont see any Things that correspond to these. Apologies if this is a daft oversight as Im quite new to this.

00:15:25.048 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/consumedEnergy: recData.length == 1

00:15:25.050 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:26.288 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/consumedEnergy: recData.length == 1

00:15:26.291 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:27.488 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/outputProduced: recData.length == 1

00:15:27.490 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:28.687 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/outputProduced: recData.length == 1

00:15:28.690 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:29.888 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/eheater: recData.length == 1

00:15:29.890 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:31.088 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/eheater: recData.length == 1

00:15:31.091 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:32.287 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/compressor: recData.length == 1

00:15:32.290 [DEBUG] [nhab.binding.km200.internal.KM200Comm] - Starting receive connection…

00:15:33.487 [DEBUG] [ab.binding.km200.internal.KM200Device] - /heatSources/total/energyMonitoring/compressor: recData.length == 1

Hi,

I think there is an entry point missing, my system is not supporting it. Could you send me a full debug output of the bindings initialization? (remove your password from the log file).

Bye

Hi. Thanks. I have the log file downloaded but cant actually find any of my passwords in it. Can anyone point me to where passwords are in the logfile? interesting messages seem to be at things like

heatsources/sensors/ —> evaporator temperature and compressor temp
/heatSources/Source/Compressor
/heatSources/total/energyMonitoring/

N

I spun up a docker of OH3.0M1 to test if all the bindings I’m using are working and found out that the KM200 binding has problems communicating with the gateway. The message in the log looks like the one I got when the JCE was missing on the “old” java versions:

```[WARN ] [b.binding.km200.internal.KM200Device] - Decoding of the KM200 message is not possible!````

@Markinus Is this a know issue and I just need to wait or should I investigate further and get you some input to get the binding “ready for 3.0”?

Hi @ralle. I installer OH3M1 recently as well but I do not encounter any problems with the KM200 binding (using Zulu 11 64bit).
I had issues before (even with latest OH2 release), but it was solved by restarting the Buderus gateway.
David

@dlaplexurenet Thanks for your reply. I re-read the docker container description and found out that I need to set the ENV CRYPTO_POLICY=unlimited when using the -alpine version of the OH3 container since that one is running on OpenJDK while the -debian flavour is using Zulu. Just in case someone else is coming across this problem, too.

Those values are prohibited to read - just integrated them on the weekend to the code from Markinus… But there is probably another way to calculate those values via the recording path /recording/* this path is readable and you get values. Getting into on the weekend…

1 Like

Did anyone ever fin the endpoints for the IVT heatpump actual enery usages?

Read on path /recordings for energy consumption. You can call with different timeframes and calculate the resulting consumption and also production. The add-on developer is currently very busy so I am using by now a python script for calling/decoding and pushing to a mqtt broker till the path will be available.
Example REST call
GET /recordings/heatSources/total/energyMonitoring/outputProduced?interval=2021-01-11

Just check the debug log for your paths

Thank you BratHuhn but what I am looking at , how do I interpret this result of the GET:

I see the elements are the hours but how do I convert the [y] and [c] values?

[c] = minutes?

[y] = ?

Thank you,

Marc

Just for clarification - example data for

/recordings/heatSources/total/energyMonitoring/outputProduced?interval=2021-01-18

“interval”: “2021-01-18”,
“sampleRate”: “P1H”,
“recording-type”: “actual”,
“recording”: [
{ “y”: 240, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 300, “c”: 60 },
{ “y”: 240, “c”: 60 },
{ “y”: 240, “c”: 60 },
{ “y”: 300, “c”: 60 },
{ “y”: 300, “c”: 60 },
{ “y”: 240, “c”: 60 },
{ “y”: 300, “c”: 60 },
{ “y”: 240, “c”: 60 },
{ “y”: 240, “c”: 59 },
{ “y”: 300, “c”: 60 },
{ “y”: 300, “c”: 60 },
{ “y”: 240, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 180, “c”: 60 },
{ “y”: 1, “c”: 0 },
{ “y”: 1, “c”: 0 },
{ “y”: 1, “c”: 0 },
{ “y”: 1, “c”: 0 }
]

Every line is one hour where y represents kW over timespan c. P1H means c in min is collected for 1 hour ->to get kWh you just need to calculate y/c to get h values. (c is the collection of minutes for that hour. Somehow strange because there are also values like 59, but if you use the table to calculate you are accurate. Hint: There´s also a factor involved which is for me always 1 so I don´t consider it in the calculation. Just check it for your heating device its somewhere on another REST-Path.
Here are my scripts for day and month ->year works like those but I have some changes due to my setup but its appropriate. Those lines with 0 and 1 are lines which are prefilled because the day has not yet arrived at that hour.

In the code “data” is the decrypted-json-object you are getting from the defined path ->like in the example data (which shows just the value part)

# Calculate produced / consumed energy by day
# Params:
#   path - path for endpoint call from KM200
def _calculateProConsumptionDay(self, path):
    # sampleRate P1H
    data = self._get_json(self._get_data(path))["recording"]
    energySum = 0
    for datapoint in data:
        if datapoint["c"] != 0:
            energySum += (datapoint["y"] / datapoint["c"])
    return energySum

# Calculate produced / consumed energy by month
# Params:
#   path - path for endpoint call from KM200
def _calculateProConsumptionMonth(self, path):
    # sampleRate P1D
    data = self._get_json(self._get_data(path))["recording"]
    energySum = 0
    for datapoint in data:
        if datapoint["c"] != 0:
            energySum += (datapoint["y"] / (datapoint["c"] / 24))   # c is the sum of minutes over the day ~ 60 Minutes per Hour
    return energySum

Thank you Brathuhn, that makes sense.

I will try to figure out if the extra factor is 1 or not ny comparing outputProduced with actual meter readings…

Is there any way to get the actual KW usage at any moment?

Currently not, at least for me. There is a REST path existing but not readable… Talked a week ago with a guy from Buderus regarding those closed ones. They will be opened in future also because there comes a law in 2023 which requests this. Hopefully they will update the firmware from the older devices also.

Awesome. Thanks for this hint @BratHuhn. Do you use an own python script for retrieving the recordings or do you use an existing open project for this?

Just build my own systemd script with the decrypt function from the smarthomeN guys because of there licence type…Till probably the author of the plugin has a little bit of time to integrate also the /recordings, then I am directly back to the Addon;-)

I will read your comments and test it on this weekend. Then I can see what changes are needed.

Question: Why do you not record these values with openhab? You could save the currentPower values, like /heatSources/actualPower, with a persistence service in a database, like RRD4j?
If you do it in this way, then you can still calculate your consumption and use the same database for graphs in a UI like cometvisu?

Edit:
I’m asking because for me it’s the right way in openhab. If you’re using a small script only without database capability, then the recording endpoint is very nice. But here, in Openhab, it’s not really needed. It takes a lot of time to implement it and we wouldn’t win something.

This would definitly be my prefered solution but all of those energy values are 0 or not readable at least for me. The only way I can get those values is over recordings. Searching around my finding is that for others also the same “stupid” restriction often exists that it seems currently not possible to get those direkt kWh values from the heating system. The /recordings path is quite different from the other ones because we need a timespan and some kind of calcuation behind. I don´t know if it makes sense to integrate also this path in the addon at least to get those values for a day, month and year. The calculation can be done somewhere else.

Ahh, ok, I’ve understood your problem now. I will think about it, maybe find a nice solution.