OpenHab 2 and Stiebel Eltron

First throw for the script…

If you want to try this out you have to use a machine that runs windows and has powershell installed. For the common PC with Win10 this script should work.

The script (pump_analyser.ps1) is here: https://1drv.ms/u/s!AnvMFS-QVBppjtlNrTXNUkczTr77TQ?e=fTTe7R

What do you need?

First activate powershell scripting over the follwoling steps:

  1. Open powershell as admin
  2. Enter Set-ExecutionPolicy RemoteSigned
  3. Confrim with yes to all

This will allow scripts to be run that are created on this specific machine. So to get the pump_analyser.ps1 runnig, open it up with an editor and copy the text to a new *.ps1 file.

Next you need a list of commands in a text file. See the link for Commands.csv.

Last step… navigate in powershell to the folder where you stored everything and exceute your created *.ps1 file. The output should be stored in results.txt and should look like this results.txt (86.7 KB) (done on my THZ 303 Eco Protocol V 5.09)

Ahhh and you have to alter the uri’s in the script to match your things in openhab.

…For the script… set the sleep command to 2 (2 Secs) otherwise the result is “stange”

@kreutzer_peter: Just to read the XML right:

request FD gives me:

FD (00)01 00 FC FD (04)01 FD 10 03

In the XML FD is definded as follows:

<record channelid="version" requestByte="FD" dataType="Status" position="4" length="2" scale="0.01" bitPosition="0" min="0" max="0" step="0.0"></record>

So position 4 is (04) (frome here we gonna read)… abd length 2 is how much bytes ro read? Here it is 01 FD ? Which results in 509 so 5.09

That differs from FHEM where the substrings are based on chars without the ()-stuff.

Apllyling this to 0B0005:

E.g. we have (00)01 00 E3 0B (04)00 05 00 D2 (08)10 03 as response this will result in

<record channelid="p01RoomTemperatureStandardMode" requestByte="0B0005" dataType="Settings" position="6" length="2"
	scale="0.1" bitPosition="0" min="10" max="30" step="0.1"></record>``

which gives me 00 D2 wich is 210 -> 21.0

In the FHEM PM 0B0005 is p01RoomTempDayHC1 … is p01RoomTemperatureStandardMode the sane?

My main question is… How can i be sure that the parsed bytes in the response is the value im looking for? I think noone - aside of Stiebel Eltron Devs - can tell me hmm?

yes FHEM is not counting the start and end bytes, which has nothing to do with the ()
the () is just indicating the position to make it easy for you to read the position
it is coming every 4 bytes

the decoding in the system will not count the ().
These are only shown in debug.

If you want i can remove them from the new channel i created.
The channel was not really intended to be used like you are using it now.

Practically you can easily make that xml by hand as the principle is always the same.

well the easiest way to do is to send the request with the channel and then lookup the value on the local HMI.
So you see 21.0 Celsius on the HMI and then look for the bytes that represent that value.
by that you will identity the position and scale .
in case of decoded bits it is the same just additionally identify the bit representing your data.

I think the “byte-count” improves the reading and parsing.

The channel was not really intended to be used like you are using it now.

:slight_smile:yep…i was quite surprised that i can use it that way.

The problem is guessing the requestbytes… I found out that the p07FanStageDay is in response to request 0A056C. That was only the case because it is definded in the 439common im FHEM.
That is the reason i built these XLSX’s…the other way would be to interate from 000000 to FFFFFF.
With a 2 sec wait between the requests tis will take over a year :wink:

Maybe the info is in the modbus docu? I think i saw the other day sth. like this…

Hi Hogan,

have you modified the time between request property of the binding and try to improve the time?

Concerning time , this is the reason the separate the request for different data types.

BR
peter

For the time… no i didn’t … will have a look at this.

I think i can cut down the “brute-force” requests to a quite maller subset.

Looking at the reuqest found so far one can assume:

  1. Requestbytes form 01 to FF
  2. Reuestsbytes form 000000 to 00FFFF
  3. Reuestsbytes form 0A0000 to 0AFFFF
  4. Reuestsbytes form 0B0000 to 0BFFFF
  5. Reuestsbytes form 0C0000 to 0CFFFF

Maybe one can step over the 0AA*, 0AB* and so on too as most requestbyte sequnces have no byte set on the thid place.

I found no 0D* requestbyte sequence.

I also fiddled around with the XML for 5.09. I had to change the ChannelIDs as in v5.09 most readings seem to be in seperate requestbytes. Maybe you can have a look at the XML if that matches your coding? I built a new jar but my additional channelids are not showing up.

Here is the XML LWZ_THZ303_5_09.xml (10.8 KB)

I will put that in a PR if things are starting to look good, so that we don’t have to much overhead. OK?
(Aim only one PR for this)

For testing i got FanStage Standard now in PaperUI.

We could test setting the fanstage? I’ll work on the LWZ_THZ303_5_09.xml further on.

great to see thing are getting resolved.
keep in mind that the channelid in you xml need to match the channelID in the thing type definition.
i see that the current thing type definition only has 5 channel groups activated

		<channel-group id="version" typeId="channelGroupTypeVersion" />
		<channel-group id="time" typeId="channelGroupTypeTime" />
		<channel-group id="currentValues" typeId="channelGroupTypeCurrentValues" />
		<channel-group id="operationCounters" typeId="channelGroupTypeOperationCounters" />
		<channel-group id="nominalValues" typeId="channelGroupTypeNominalValues" />

if you like to activate more we need to add the other channelgroups.

Hello all,

I stopped testing new commands three weeks ago. When I had almost 100° C flow temperature in the morning I lost the desire to test… :confused: A reset of the electronics fixed the problem but I’m still worried about breaking something.

I would be happy if the binding would remain and the already working functions of the 705 would be preserved. I still use them without any problems.

Hi @kreutzer_peter, @Hogan,
You’ve made a great job on this topic. thank you :+1:
Could you give me an advice on my home config? My installation has the Stiebel heatpump WPL-13 with the manager WPM III and the ISG. What would be the best approach to integrate the ISG into my openhab config? thank you for your help :slight_smile:

looks like that ISG provide web page which can be integrated in openhab via http binding

hi Pierre,

binding is working well for me. Have it in operation since months.
the issue reported, could you provide a debug log of the setting change you did?

btw i think soon when OH3 is out will make an attempt to get the binding migrated

Dear Peter (an all others involved),

migrating the serial StiebelEltron connection to OH2 is awesome. For now I have made a “poor mans solution” working: I had Robert Penz’s python code running and grabbed the JSON data to OH. It works but I prefer the fully integrated solution.
Unfortunately my THZ 304 runs on firmware 7.09 and this means I need to make a new version-.xml (might be not a big deal as I can use the data from my current solution).
My questions:

  • Is there a folder on the OH where to put this .xml?
  • Or do I have to integrate it in the source code and generate a .jar-file of it? I am not super familiar with OH and just took the available SNAPSHOT-jar file for now. Any help on how to generate the .jar file from the source code would be appreciated.

hi ,
best would be to add you file to the current github

Here can can find some examples.
And of course you can clone and make a pull request as others have done her in the this topic.

maybe this file is a good
LWZ_THZ504_7_59.xml

Hi Peter,
thanks for the hint. If cloned your fork of openhab-addons. Unfortunately I do not get a -jar file generated with maven. stiebelheatpump was not in the pom-file. I have tried to modify the pom-file but without any luck yet.
Any help or advice how to get a .jar-file compiled or what needs to be edit? (sorry, I am a bloody novice in that)

one way could be to add the xml to the jar.
with
jar tf org.openhab.binding.stiebelheatpump-2.5.4-SNAPSHOT200512.jar
you can view the jar content
jar uf org.openhab.binding.stiebelheatpump-2.5.4-SNAPSHOT200512.jar ESH-INF/thing/LWZ_THZ504_7_09.xml
should add the newly created file.

i never tried it but it should work

Hello,
I am new to openhab and following this discussion regarding the inclusion of the stiebel heatpump, quite a long time and I see many experienced people talking here.
I am thinking of of geting OH started quite a long time and a few days ago I found the time to install the Raspi and start the system.
Installing bindings for modbus and homematic was quite simple and the homematic CCU2 connection works quite well.
My problem is the connection to the heatpump.
I tried it in myself but without succes and hopefully somebody can give me assistance on getting the heatpumt connection started.
After reading the introduction of the Stiebel Eltron ISG binding my first thought was: should be no problem. But now after many trials I am coming back to reality: getting started with openhab is not easy…

What is my situation:

  • heatpump Stiebel Eltron LWZ 304 Trend
  • ISG running (latest SW; Modbus running)
  • OH running on a Raspi
  • all in the same network :wink:

What I tried:
(Stiebel Eltron ISG - Bindings | openHAB)

  • Creating a thing file in the folder \openHAB-conf\things\
  • Name: stiebel.thing

Code:
Bridge modbus:tcp:bridge “Stiebel Modbus TCP”[ host=“192.168.178.21”, port=502, id=1 ] {
** Thing heatpump stiebelEltron “StiebelEltron” (modbus:tcp:modbusbridge) @“Room” [ ]**
}

Looking at the Log Viewer is see the following:
2021-01-20 15:53:54.264 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:heatpump:lwz’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Bridge is offline

What am I doing wrong? Would be great if somebody can give me assistance to get this started.

I am not sure but the example in the docs looks a bit off. Especially the stuff in parentheses seems to be extra.

Looking at things config docs Things | openHAB . html

I suggest to try the following

Bridge modbus:tcp:bridge "Stiebel Modbus TCP" [ host="192.168.178.21", port=502, id=1 ] {
    Thing heatpump stiebelEltron "StiebelEltron" @ "Room" [ ]
}

You can also try to create things using MainUI in openHAB3 to skip the error-prone text configuration. Opening up the thing in the UI might reveal more details as well.

Hello and thanks for the quick help.
I got the system running, but not by the use of the binding (it only brought mistakes) but with the use if *.things file and +.item file from a different forum:
https://knx-user-forum.de/forum/supportforen/openhab/42226-neues-stiebel-eltron-wärmepumpen-binding/page2

What is still not running is the transformation to correct values:
Code example:
Thing data LWZ_Aussentemperatur “LWZ304 Außentemperatur” [ readStart=“6”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]

Log says:
2021-01-24 20:53:31.996 [WARN ] [nding.modbus.internal.Transformation] - couldn’t transform response because transformationService of type ‘JS’ is unavailable

Sorry to hear the binding did not work for you, I wonder what was the issue. Did you try my suggestion by the way? Would be nice to fix errors in docs

You need to install the javascript transformation. You can do this via openHAB3 MainUI