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.
What do you think, would be it enough to calculate the consumption/day inside of this binding and create a channel for it? Does someone realy need the consumption/hour?
Consumption per day in my opinion is completely enough. This value can be updated/summed up every hour as you get then the new values from km200 see the example data a little bit above. (c=0-> hour not completed, requesting every hour) more granularly values are from my perspective not needed. Every other step can then be done with OH itself from that point of time. When someone wants to have the value for every hour he just calculates the delta.
I am just thinking about past days/months/year. Those values are present from the day when km200 got initial communication. I am unsure about the timespan it stores. Maybe it would be helpful to have also the consumption per month and year available and update them accordingly (daily/monthly). For sure this can also be achieved manually by the user initially for all past values and summarised in future with all day values but maybe a nice feature which is not that much effort to implement when the day consumption is integrated. Just an additional factor.
What do you think?
Personally I think per hour could be nice, especially if you access the recordings for solar yield or in general to have a daily overview.
In case you do not want to integrate it into a channel, would it be possible to retrieve the recordings through actions in rules? Just by returning the json and the rest can be done be the ones who want more detailed views.
Ok, I will think about this. Maybe it would be the best solution to intergrate this functionality completly.
Hi,
I did some tests yesterday and I’ve integrated a support for recordings inside of the binding.
Here you can download a test version.
You will find a new thing called “recordings”. Inside of this recording are 5 channels for every recording endpoint:
- interval: Input, String, interval for data, year or year-month or year-month-day e.g. 2020-12-24
- element: Input, Integer, select a element of this interval. In case the interval is a year then it’s the month, In case the interval is a month then it’s a day, In case the interval is a day then it’s a hour.
- sumInterval: Output, the sum of all elements y/c inside of the interval.
- meanInterval: Output,the mean value of all elements y/c inside of the interval
- elementValue: Output, the y/c value of the selected element
The mean interval is intresting for such recordings like the temperature.
The results inside the data in my system are a bit strange. The sum of all dey elements of a month is unequal to the element value of this month if you get the data for the whole year. So it have to be analyzed.
1 Like
hi @Markinus, I have run into an issue with a KM200 and wonder how I could help debug it?
I’m able to run rest queries against the device, i.e.
I just don’t get what to do with the result. Seems encrypted or so. Any suggestions?
UPDATE: after some painful setup/configuration experience I’m able to run OpenHAB and the binding locally in Eclipse in debug mode, horray! Now I see what’s going on and wonder:
this is where it fails. The garbage is the content of the dectypted response to /gateway/DateTime.
What does that mean? Wrong private key, unable to decrypt properly?
Thanks,
Jens
Hey guys!
Thanks for the great plugin.
Works perfectly out of the box.
Has there been any progress regarding the energy-meetering?
Thanks,
KR,
Michael
Hey BratHun!
Could you please give some hints on how you achieved this?
Thanks!
@Markinus did a great job with the plugin based on the limits we all have with KM200. It is really to bad for all smart Home enthusiastic people out there how closed such useful information could be even in just a read mode! I now changed to esp-ems that offers quite all information you can read manually on your device including all energy based elements in real time. You get also some really simple information like what this stu++I’d thing is doing currently or even if it is active. You just need a ESP32 or 8266 / Arduino / RPI and a EMS extension board + a cable into your heating system to connect to the EMS bus ~ summed up around 50 bucks and that’s it. You get all you need pretty simple over mqtt whenever a value changes.
Here the references
- EMS-ESP Documentation
- EMS Board or ready to use product https://bbqkees-electronics.nl/shop/?lang=de
2 Likes
Hi,
it looks nice! I have to take a closer look to this project 
thx!
Dear all,
my goal is to compute the Coefficient of Performance(COP) so I need the total energy consumed and the total energy produced.
Under the /heatSources/total/energyMonitoring I find the following options:
{
"id": "/heatSources/total/energyMonitoring",
"references": [
{
"id": "/heatSources/total/energyMonitoring/consumedEnergy",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/consumedEnergy"
},
{
"id": "/heatSources/total/energyMonitoring/outputProduced",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/outputProduced"
},
{
"id": "/heatSources/total/energyMonitoring/eheater",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/eheater"
},
{
"id": "/heatSources/total/energyMonitoring/compressor",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/compressor"
},
{
"id": "/heatSources/total/energyMonitoring/workingTime",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/workingTime"
},
{
"id": "/heatSources/total/energyMonitoring/numberOfStarts",
"uri": "http://192.168.1.2/heatSources/total/energyMonitoring/numberOfStarts"
}
],
"type": "refEnum"
}
Given that I want to compute the total energy consumed and the total energy produced, the data I need is contained in the first two options, however if I try to query /heatSources/total/energyMonitoring/consumedEnergy and /heatSources/total/energyMonitoring/outputProduced I am getting in both cases an empty response {}.
Do you know why?
In addition I found that under /heatSources/cumulatedHeatEnergySecondBurner I find the cumulative energy produced by the second burner(the heat pump) for the underfloor heating. However I also need the cumulative energy produced for the domestic hot water. Do you know where I can find also the last one?
You missed the interval parameter. Those endpoints are calculated based on a selected date like for which day, month or year. A short example
"/recordings/heatSources/total/energyMonitoring/consumedEnergy?interval=" + day
# example for day
day = self._getTimeContext("year") + "-" + self._getTimeContext("month") + "-" + self._getTimeContext("day")
def _getTimeContext(self, context):
year, month, day, hour, min = map(int, time.strftime("%Y %m %d %H %M").split())
if context == "year":
return '{:04d}'.format(year)
elif context == "month":
return '{:02d}'.format(month)
elif context == "day":
return '{:02d}'.format(day)
elif context == "week":
return date(year, month, day).strftime("%V").strip("0")
elif context == "now":
return datetime.now().strftime("%d/%m/%Y %H:%M:%S")
return "error"
I have build a python script to call most of the REST endpoints especially for what you want to achieve it may be enough. I can share it if you want.
Also take care of the response itself. I have written here somewhere the kind of definition what you are getting back and how to interpret.
1 Like
This is a snippet extracted from the code that I have written.
class Buderus:
... # omitted
def buderusRequest(self, requestUrl):
headers = {
'User-Agent': 'TeleHeater',
'Connection': 'Close'
}
requestUrl = self.gateway_ip + requestUrl
encryptedResponse = requests.get(requestUrl, headers=headers, verify=False)
print("Encryped response: \n" + encryptedResponse)
decryptedResponse = self.decrypt(encryptedResponse.text) # decodes the response
print("Decrypted response: \n" + decryptedResponse)
return decryptedResponse
I am utilizing the code above and self.decrypt function to decode the response output. The function is invoked as shown below:
buderus = Buderus()
buderus.buderusRequest("/recordings/heatSources/total/energyMonitoring/consumedEnergy?interval=2023-03-10")
The output returned for the above request:
Encryped response:
Decrypted response:
To show that the interval parameter is really passed to the request, here is an example of request to another endpoint, i.e. /recordings/dhwCircuits/dhw1/actualTemp?interval=2023-03-10
buderus = Buderus()
buderus.buderusRequest("/recordings/dhwCircuits/dhw1/actualTemp?interval=2023-03-10")
The output returned for the above request:
Encryped response: ..... omitted .....
Decrypted response:
{"id":"/recordings/dhwCircuits/dhw1/actualTemp?interval=2023-03-10","interval":"2023-03-10","recordable":0,"recordedResource":{"id":"/dhwCircuits/dhw1/actualTemp","uri":"http://192.168.1.2/dhwCircuits/dhw1/actualTemp"},"recording":[{"c":60,"y":3607},{"c":60,"y":3600},{"c":60,"y":3600},{"c":60,"y":3567},{"c":60,"y":3540},{"c":60,"y":3540},{"c":60,"y":3527},{"c":60,"y":3480},{"c":59,"y":3422},{"c":60,"y":3480},{"c":60,"y":3428},{"c":60,"y":3420},{"c":60,"y":3420},{"c":60,"y":3388},{"c":60,"y":3360},{"c":60,"y":3360},{"c":60,"y":3348},{"c":60,"y":3300},{"c":60,"y":3300},{"c":60,"y":3300},{"c":60,"y":3248},{"c":60,"y":3240},{"c":60,"y":3240},{"c":60,"y":3208}],"recording-type":"actual","sampleRate":"P1H","type":"yRecording","writeable":0}
Hm strange, should Look like
{ "id": "/recordings/heatSources/total/energyMonitoring/consumedEnergy?interval=2021", "type": "yRecording", "writeable": 0, "recordable": 0, "recordedResource": { "id": "/heatSources/total/energyMonitoring/consumedEnergy", "uri": "http://192.168.178.13/heatSources/total/energyMonitoring/consumedEnergy" }, "interval": "2021", "sampleRate": "P31D", "recording-type": "actual", "recording": [ { "y": 17220, "c": 13257 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 }, { "y": 0, "c": 0 } ] }
{ "id": "/recordings/heatSources/total/energyMonitoring/outputProduced?interval=2021-01-18", "type": "yRecording", "writeable": 0, "recordable": 0, "recordedResource": { "id": "/heatSources/total/energyMonitoring/outputProduced", "uri": "http://192.168.178.13/heatSources/total/energyMonitoring/outputProduced" }, "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 } ] }
I know that buderus is changing their endpoints / remove some of them when the km200 is connected to Internet. Which Version are you running?
/gateway/versionFirmware returns:
{
"id": "/gateway/versionFirmware",
"recordable": 0,
"type": "stringValue",
"value": "04.08.02",
"writeable": 0
}
/gateway/versionHardware returns:
{
"id": "/gateway/versionHardware",
"recordable": 0,
"type": "stringValue",
"value": "iCom_Low_NSC_v1",
"writeable": 0
}