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.
First activate powershell scripting over the follwoling steps:
Open powershell as admin
Enter Set-ExecutionPolicy RemoteSigned
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.
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.
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
Maybe the info is in the modbus docu? I think i saw the other day sth. like this…
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:
Requestbytes form 01 to FF
Reuestsbytes form 000000 to 00FFFF
Reuestsbytes form 0A0000 to 0AFFFF
Reuestsbytes form 0B0000 to 0BFFFF
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.
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
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… 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
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
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 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.
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…
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.
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.
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