OpenHab 2 and Stiebel Eltron

Dries_V · May 21, 2020, 10:30am

Hi, I’m having a LWZ504 7.59. Testing the latest jar at this moment. I was really looking forward to a binding so really happy this exist now! Thanks for all the energy and effort you and others are putting into this.

I noticed some errors:

“Operation counter heating mode” shows me the value of the DHW
“Operation counter DHW mode” is actually the value of the booster used for DHW

I was wondering. How can I help? Not a die-hard IT’er but I would be happy to help. Maybe I can try to match some data, position, length … with values I can read from the control screen on my pump? That’s how I could see the errors above. Is something like that possible? Other suggestions? I’m certainly willing to invest the time to improve this binding and helping others with the same pump. I just think I will need some help to start up the proces. Let me know!

Ow, I’m also wondering if “amount of heat” and “power consumption” could be read by the binding? Is that something for the future?

kreutzer_peter · May 21, 2020, 10:37am

this are exactly the things you can do.
in the binding there are xml files per thingtype in which the parsing rules for the data are described.
Yours is here.
LWZ_THZ504_7_59.xml

the basic description you can find here OpenHab 2 and Stiebel Eltron

the xml is embedded in the jar and you can replace this easy in the jar and test your own configuration.
when doing that please enable debug in the karaf console.

Dries_V · May 21, 2020, 5:23pm

Hi @kreutzer_peter

Question 1: matching channel-group types
Just to be sure, there is no other way than to look at the logs, for example

2020-05-21 18:38:51.304 [DEBUG] [.stiebelheatpump.protocol.DataParser] - Parse bytes: (00)01 00 57 09 (04)08 C5 00 00 (08)00 ED 00 05 (12)00 00 00 00 (16)05 89 10 03

and then search for groups of bytes to see which data is inside that group and match it? No problem if that’s the case, but just to be sure because it’s a painstaking proces would hate to find out later if that was not necessary

Question 2: spelling in the binding
I noticed that there are mixes English and German: for example outsideTemperatur <-> condenserTemperature. I think it’s better to do everything in English. Offcourse this will be breaking, so not sure if we want to do this. What do you think?

Question 3: New channel-group types
I think I found a new value, not existing at this moment in the channelgroup-types.xml (Heatpump -> Compressor starts). How do we want to do this? Do I pass this information to you, do I make a pull request on your fork?

kreutzer_peter · May 21, 2020, 5:56pm

1:
the data you see ate the raw byte[] you receive from the heatpump before the parse tries to decode.
i remember that 4 years ago i dumped it to excel and played around to see which data could be in .

what i can offer is to take the current xml, parse it also log the parsed data. would that help?

oh yes i am sure that there are many
if you are familiar with git you could also do a PR on my git repository.
you can also edit the file and send it to my, then i merge the changes.
thanks you

this is no problem.
if the channel groups are different per version we can make a copy of the existing channelgroup type and give it a new meaningful name. you can see similar approach in FHEM.
we can add the channe group type into the existing file of add a new file.

PR would be best
many thanks for your support.

Dries_V · May 21, 2020, 6:12pm

Aha! Yes I did the same, I prepared an Excel with some formulas to make some combinations.

Yes, Git is not a problem, PR’s will come Thanks Peter

kreutzer_peter · May 21, 2020, 8:50pm

Here a short comparison how to read the parse tables in the FHEM code and in the OH2 binding

This is a typical parsing definition in FHEM for request byte 17

“17pxx206” => [["p01RoomTempDay: “, 4, 4, “hex”, 10], [” p02RoomTempNight: “, 8, 4, “hex”, 10],
[” p03RoomTempStandby: “, 12, 4, “hex”, 10], [” p04DHWsetTempDay: “, 16, 4, “hex”, 10],
[” p05DHWsetTempNight: “, 20, 4, “hex”, 10], [” p06DHWsetTempStandby: “, 24, 4, “hex”, 10],
[” p07FanStageDay: “, 28, 2, “hex”, 1], [” p08FanStageNight: “, 30, 2, “hex”, 1],
[” p09FanStageStandby: “, 32, 2, “hex”, 1], [” p10HCTempManual: “, 34, 4, “hex”, 10],
[” p11DHWsetTempManual: “, 38, 4, “hex”, 10], [” p12FanStageManual: ", 42, 2, “hex”, 1],

This is a parse definition in OH2 for request byte 17

<record channelid="p01RoomTemperatureStandardMode" requestByte="17" dataType="Settings" position="4" length="2"
	scale="0.1" bitPosition="0" min="10" max="30" step="0.1"></record>
<record channelid="p02RoomTemperatureSetbackMode" requestByte="17" dataType="Settings" position="6" length="2"
	scale="0.1" bitPosition="0" min="10" max="30" step="0.1"></record>
<record channelid="p03RoomTemperatureStandby" requestByte="17" dataType="Settings" position="8" length="2"
	scale="0.1" bitPosition="0" min="10" max="30" step="0.1"></record>
<record channelid="p04DHWTemperatureStandardMode" requestByte="17" dataType="Settings" position="10" length="2"
	scale="0.1" bitPosition="0" min="10" max="55" step="0.1"></record>
<record channelid="p05DHWTemperaturSetbackMode" requestByte="17" dataType="Settings" position="12" length="2"
	scale="0.1" bitPosition="0" min="10" max="55" step="0.1"></record>
<record channelid="p06DHWTemperatureStandby" requestByte="17" dataType="Settings" position="14" length="2"
	scale="0.1" bitPosition="0" min="10" max="55" step="0.1"></record>
<record channelid="p07FanStageStandardMode" requestByte="17" dataType="Settings" position="16" length="1"
	scale="1.0" bitPosition="0" min="0" max="3" step="1.0"></record>
<record channelid="p08FanStageSetbackMode" requestByte="17" dataType="Settings" position="17" length="1"
	scale="1.0" bitPosition="0" min="0" max="3" step="1.0"></record>
<record channelid="p09FanStageStandby" requestByte="17" dataType="Settings" position="18" length="1" scale="1.0"
	bitPosition="0" min="0" max="3" step="1.0"></record>
<record channelid="p10HeatingCircuitTemperatureManual" requestByte="17" dataType="Settings" position="19"
	length="2" scale="0.1" bitPosition="0" min="10" max="65" step="0.1"></record>
<record channelid="p11DHWTemperatureManual" requestByte="17" dataType="Settings" position="21" length="2"
	scale="0.1" bitPosition="0" min="10" max="65" step="0.1"></record>
<record channelid="p12FanStageManual" requestByte="17" dataType="Settings" position="23" length="1" scale="1.0"
	bitPosition="0" min="0" max="3" step="1.0"></record>

["p01RoomTempDay: ", 4, 4, “hex”, 10]

p01RoomTempDay : is equivalent to the channelid and must be unique in the XML
4 (1st): position of byte in the responds of the heatpump,
4 (2nd): count in char and the OH2 in bytes. in FHEM 1 byte is represented a 2 characters, that why in OH binding is half , length is 2 bytes
hex: conversion of the bytes in FHEM , this is currently not necessary in the OH 2
10: is the the divider of the decoded value, in OH2 this is the scale → 0.1 as multipliers

i hope that helps to map these parsing rules to ours

cheers

Dries_V · May 21, 2020, 9:17pm

Whats the purpose of typeID in channelgroup-types.xml?

I would expect speed instead of exhaustFanSpeed. With a narrow minded view and without checking out the code, this seems like a copy paste error. Or does it have a special meaning?

...
			<channel id="extractFanSpeed" typeId="speed">
				<label>Extract fan speed</label>
				<description>Extract fan speed</description>
			</channel>
			<channel id="supplyFanSpeed" typeId="speed">
				<label>Supply fan speed</label>
				<description>Supply fan speed</description>
			</channel>
			<channel id="exhaustFanSpeed" typeId="exhaustFanSpeed">
				<label>Exhaust fan speed</label>
				<description>Exhaust fan speed</description>
			</channel>
...

kreutzer_peter · May 21, 2020, 9:32pm

typeId id in a separate file defined , see here for more detail.

github.com

kreutpet/openhab-addons/blob/StiebelBinding/bundles/org.openhab.binding.stiebelheatpump/src/main/resources/ESH-INF/thing/channel-types.xml

<?xml version="1.0" encoding="UTF-8"?>
<thing:thing-descriptions bindingId="stiebelheatpump"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:thing="http://eclipse.org/smarthome/schemas/thing-description/v1.0.0"
	xsi:schemaLocation="http://eclipse.org/smarthome/schemas/thing-description/v1.0.0 http://eclipse.org/smarthome/schemas/thing-description-1.0.0.xsd">

	<channel-type id="version">
		<item-type>String</item-type>
		<label>Version</label>
		<description>Firmware version of heat pump.</description>
		<state readOnly="true" />
	</channel-type>
	<channel-type id="dumpResponse" advanced="true">
		<item-type>Switch</item-type>
		<label>Dump heat pump response </label>
		<description>Takes standard request bytes and asks for a heat pump response, which is logged in the log.</description>
	</channel-type>
    <channel-type id="dateTime">
        <item-type>String</item-type>
        <label>Last refresh</label>

This file has been truncated. show original

the thing type references channelgrouptypes and channels reference channel types .

Dries_V · May 21, 2020, 9:44pm

Damn, I just saw it myself and wanted to delete my comment It’s clear for me now! Different type as it has other properties.

Dries_V · May 22, 2020, 1:47am

@kreutzer_peter

I found in E8, and I will use the stiebel the terms from the manual in English: “Supply air actual” and “Extract air actual” both in Hz, “Supply air set” and “Extract air set” in m3/h.

Are these values already defined in the channel group types? I’m confused by “exhaustFanSpeed”, “supplyFanSpeed” and “extractFanSpeed”. These are defined as ‘speed’, those things must be something different but I can’t link those to something I saw on my thermostat control screen. Can’t wind my head around speed…?!

Do you or somebody else have an idea?

(https://www.openhab.org/docs/concepts/units-of-measurement.html hz and m3/h are both supported)

Hogan · May 22, 2020, 11:56am

Thanks!

I notice that my e.g. P07 Fan stage is -NaN now. I created the Link via the default settings.

Splitting up the requests was a really good idea imo. My queries are extremly fast:
log.txt (3.3 KB)

Zony · May 22, 2020, 12:33pm

Hello everyone,

Here are the two logs from my FHEM setup.
Maybe it helps to understand the code. In case I need to test something or extend the log, let me know.

Unfortunately I have very little time to deal with this topic at the moment but I will try to answer as soon as possible. Hopefully it will be better next week…

Edit: Logs missing
fhem-2020-05.log (273.5 KB) Mythz-2020.log (14.5 KB)

kreutzer_peter · May 22, 2020, 12:39pm

yes i think you are right. this should be speed as the referenced type is a setting , will change

kreutzer_peter · May 22, 2020, 12:41pm

the Pxx are settings , they will be loaded at start.
please disable and enable the thing and have a look at the log if the setting are loaded.

Hogan · May 22, 2020, 7:13pm

Hmm… i switched the USB-Ports back an forth and i found this in the log.

log.txt (6.4 KB)

What is the best way to enable/disable the binding to get the full readings?

kreutzer_peter · May 22, 2020, 7:29pm

during testing i did disable-enable the device in the thingconfiguration

kreutzer_peter · May 22, 2020, 8:49pm

i am currently working on some data that are not yet considered in the readout.
i today finalized the decoded of error list in my 2.06 heatpump

now i staarted with the request EE which i found in FHEM.
here my debug log

22:40:11.184 [WARN ] [ing.stiebelheatpump.protocol.Requests] - Could not find valid request definition for EE, please verify thing definition.
22:40:11.185 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Could not find request for EE in the thingtype definition.
22:40:11.186 [DEBUG] [eatpump.internal.CommunicationService] - RequestByte → EE
22:40:11.186 [DEBUG] [eatpump.internal.CommunicationService] - Sending start communication
22:40:11.199 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Send request message : (00)01 00 EF EE (04)10 03
22:40:11.305 [DEBUG] [eatpump.internal.CommunicationService] - reached end of response message.
22:40:11.306 [DEBUG] [g.stiebelheatpump.protocol.DataParser] - Parse bytes:
(00)01 00 81 EE (04)01 8E 01 01 (08)02 02 00 00 (12)0B F2 00 00 (16)00 00 00 00 (20)00 00 00 10 (24)03

here the FHEM configuration.

“EEprg206” => [["opMode: “, 4, 2, “opmode2”, 1], [” ProgStateHC: “, 10, 2, “opmodehc”, 1], [” ProgStateDHW: “, 12, 2, “opmodehc”, 1],
[” ProgStateFAN: “, 14, 2, “opmodehc”, 1], [” BaseTimeAP0: “, 16, 8, “hex”, 1], [” StatusAP0: “, 24, 2, “hex”, 1],
[” StartTimeAP0: “, 26, 8, “hex”, 1], [” EndTimeAP0: ", 34, 8, “hex”, 1]

does somebody know if this information can also be seen in the local HMI? i guess the operation modes are the blinking block below the symbols right?

kreutzer_peter · May 24, 2020, 9:04am

new version 9 upload

changelog:

merged PR Dries_V … many thanks
added Absence program setting changes
added operationmode EE request, here the operationmode should b show as value option, e.g. Setback , but paperUI is not showing it. will need to ask in dev section why not showing
fine tuning of the different schedulers setting, sensor/status , especially during startup of binding
added parsing during dump responds when parsing definition is available.
added error code readings and parsing, e.g. you can now trigger email notification when a new error is created , e.g

rule “React on FA00 Number of errors (FA00NumberOfErrors) change/update”
when
Item FA00NumberOfErrors changed
then
logInfo("notifications", "Sending notification via mail.")
sendMail("<openhab@mail.com>", "Neue Fehlermeldung in Wärmepumpe!", 
    "Neuer Fehler!!")
end

the communication to the heatpump seems quiet stable in my case. Hope it is the same for you.

As the channel groups and types are changing in the current status you need the recreate the thing.
you can copy the thingid of the old to the new , e.g. cc78eac2 to make sure you do not loose linked item.
In some cases the channe-types are changing here you need to re-link the item again.

Happy testing

Dries_V · May 24, 2020, 6:07pm

I have something weird I can not explain.

2020-05-24 20:02:17.744 [DEBUG] [.stiebelheatpump.protocol.DataParser] - Parse bytes: (00)01 00 F7 FD (04)02 F7 10 03 

2020-05-24 20:02:17.749 [DEBUG] [.stiebelheatpump.protocol.DataParser] - Parsed value version#version -> 7.59 with pos: 4 , len: 2

But

Everything seems correct, parses ok, but I see a date in PaperUI.

Zony · May 24, 2020, 6:18pm

The problem is known
Have we already talked about it above, but I’m not sure if the reason has been found yet.
It’s the same for me.