OpenHab 2 and Stiebel Eltron

Hardware Home Automation
142

Hmm, tue log Shows that the data are not loaded.
When linking a channel to item there should be the corresponding requested to heat pump added. Could you send me a debug log of the unlink and link activities to see if the request are send to the heat pump.
Actually these also should happen during initial phase. All setting are loaded in the beginning. Please also sen debug log when you disable and enable the thing

i had a closer look in the look and saw that during initializing you do get an error

org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpException: invalid response on request of data, response is neither get nor set: (00)01 03 1B 17 (04)10 03

so the code does what i mentioned. after identifying the version and loading time it continues with loading the setting request. I the case of 5.09 version on request 17 is defined a setting request.

Not sure why the heatpump is doing that. I do not face this behavior on my version (2.06).
Somebody else here in the thread discussion has similar error messages on request 17?
here is what is loaded for my version.

grafik
grafik473×902 43.5 KB

143

Yes there is a problem un/linking the channel to the item.

Logs

log_disable_enable.txt (43.9 KB) log_unkink_link.txt (4.7 KB)

I think it ws I an earlier version - maybe v8- of the binding… I got values for P0*

144

ohh yes , there is a line of code which needs to be made ready for dealing with multiple bytes in the request.will fix it today evening and provide a new version.
Still i am not sure why we see in the original log the issue how the heat pump is responding on the request 17.

145

upload version 12 which should fix the unlink.
still we do not know why the responds to request 17 is not working

146

I don’t get any nominal values at all. I think that the 5.09 FW does not respond to a separate request. I hab values in the former versions of the binding. I think hat somehow 5.09 only delivers “everything at once”

147

do you have FHEM running and could see which request are supported?
to my understanding the request of that firmware is different as indicated in this post
when you look at the THZ.pm file

my %sets439539common = (
“pOpMode” => {cmd2=>“0A0112”, type => “2opmode”}, # 1 Standby bereitschaft; 11 in Automatic; 3 DAYmode; SetbackMode; DHWmode; Manual; Emergency
“p01RoomTempDayHC1” => {cmd2=>“0B0005”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},
“p02RoomTempNightHC1” => {cmd2=>“0B0008”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},
“p03RoomTempStandbyHC1” => {cmd2=>“0B013D”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},
“p01RoomTempDayHC1SummerMode” => {cmd2=>“0B0569”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},
“p02RoomTempNightHC1SummerMode” => {cmd2=>“0B056B”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},
“p03RoomTempStandbyHC1SummerMode” => {cmd2=>“0B056A”, argMin => “12”, argMax => “30”, type =>“5temp”, unit =>" °C"},…

you see that the request are byte arrays, this is why i asked you to translate the above configuration into the configuration for this binding. It looks like this version allow to read out single values instead of a register which contains multiple values at the same time.
i gave some explanations how to translate it here, would be great if you could do this .
just take this file and add your data .
e.g.:

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

the position should seen when we do have the byte respond in the debug log
Pierre die some log here . it is just about to get the position of the bytes to read.

2020.05.26 19:49:00 5: THZ_Get: Try to get ‘p01RoomTempDayHC1’
2020.05.26 19:49:00 5: THZ_Get_Comunication: Check if port is open. State = ‘(opened)’
2020.05.26 19:49:00 5: Mythz sending 02
2020.05.26 19:49:00 5: SW: 02
2020.05.26 19:49:00 5: Mythz start Function THZ_ReadAnswer
2020.05.26 19:49:00 5: THZ_ReadAnswer: uc unpack: ‘10’
2020.05.26 19:49:00 5: Mythz sending 0100110B00051003
2020.05.26 19:49:00 5: SW: 0100110B00051003
2020.05.26 19:49:00 5: Mythz start Function THZ_ReadAnswer
2020.05.26 19:49:00 5: THZ_ReadAnswer: uc unpack: ‘10’
2020.05.26 19:49:00 5: Mythz start Function THZ_ReadAnswer
2020.05.26 19:49:00 5: THZ_ReadAnswer: uc unpack: ‘02’
2020.05.26 19:49:00 5: Mythz sending 10
2020.05.26 19:49:00 5: SW: 10
2020.05.26 19:49:00 5: Mythz start Function THZ_ReadAnswer
2020.05.26 19:49:00 5: THZ_ReadAnswer: uc unpack: ‘0100D40B000500C31003’
2020.05.26 19:49:00 5: Mythz sending 10
2020.05.26 19:49:00 5: SW: 10
2020.05.26 19:49:00 5: Parse message: D40B000500C3
2020.05.26 19:49:00 5: Message length: 12
2020.05.26 19:49:00 5: (OH) Parsing Command: 0B0005
2020.05.26 19:49:00 5: (OH) Parsing Rule: ARRAY(0x18401f0) | Msg Type: 5temp}
2020.05.26 19:49:00 5: (OH) THZ_Parsing: offset(8) + length(4) | message : ‘D40B000500C3’ | value : ‘00C3’
2020.05.26 19:49:00 5: (OH) THZ_Parsing: ParsedMsg(19.5) | value : ‘19.5’

Are you able to bring this together or anybody who has similar version available and can test?

As an improvement i could imagine we define a text channel on which we can write the request bytes and get output in the log. What do you think?

148

Thanks for hinting at the different posts. I will have a look at this. Aside of that, I will setup a FHEM instance and see what I get from there.

The text channel would be interesting though. I think that it would be worth it for debugging purposes or for ppl with other FW versions.

149

hi Hogan,
as a small improvement and to make this process hopeful a bit better i added to new channels for debug only.

grafik
grafik505×590 24 KB

you type your bytes in the request channel and get the responds on the responds channel.
version 13 uploaded
changelog :

  • allow to send individual request to heat pump
  • receive the responds on the responds channel
  • adapted initialize process to only consider request that have channel linked

please try with 0B0005

151

With 0B0005

I get
(00)01 00 E3 0B (04)00 05 00 D2 (08)10 03

152

Great, semse to work. Now we have everything for reading.
Your value is 00 D2 , which are decimal 210 and 21.0 celsius.
Now we only need to convert the configuration in the FHEM Perl script to our xml format
That is straight forwards

Can you do that?
Next step would be writing back a value.
As soon as i get the xml from you i can give you a jar and you can test the write.

@dries, could you facilitate. i have seen you making PR for the configuration files. I guess you firmware version also requires the byte array request and would have similar configuration as Hogan. Your expertise would be great value here.

I cannot test this in my environment , sorry.
BTW, is great to see that you all help getting this done. Many thanks

153

Yes I will look at it tonight.
I will make a PR when I have some conversions ready.

Without the work you did so far Peter we weren’t so far. :).

Aa Stiebel/Tecalor is commonly used in Germany this binding will be quite interesting for some. :wink:

154

Hello everyone,

Unfortunately I am not quite sure how to use the new Request\Response function.
I have added both as items and set the value of the requestBytes item e.g. to “0B0005” via a rule.
In OH log I see that the value is set, but nothing else happens after that.

155

Hi,

you can set it directly over PaperUI by clicking on the Text. It should auto-refresh and you see the response.

I am working on a little script that uses the rest API of these 2 items. As I have only little time atm but I think I have ready srh in 2-3 days.

I had to remove the thing to get the new channels and I have the “Debug” switch on.

156

Hi Pierre an Hogan,
please keep in mind that beside the rules and rest API we finally need the heap pump configuration filled up and match the channelgroup types and channel types of the heat pump version.
if you send the the heat pump configuration as PR of mail i can easy put them in the jar.
thx

157

Yes, that I why I am working on a script that can hopefully speed things up by querying the commands via Rest.

Will it make sense to keep the requests in plain hex in the xml or in “converted” decimal?
080005 rather expresses the the reuqst bit sequence than a decimal ( wich would be 720 901)

I also realized that stiebel seems to categorize the requests by using 0A*, 0B*…

158

Please use hex , same way as in fhem or in post above.
Yes typically the data are grouped. In the older version it was 1 request to get the complete set of data. In later version they extended the request bytes to get individual data.

You can also verify your xml by replacing the file in the jar.

159

Any sucess success stories to share.
Were you able to create the XML and get the full set of parameters?

160

Hi Peter,

currently im chweing thourgh the 00_THZ.pm file. My goal is to convert the information from the PM-File to a XLSX with XML annotations. This will give us the possibitltiy to edit the request/parsing info quite easy over Excel but also saving the XLSX in the needed XML format.

Can you give me a bit more info about the inculded XSD fpr the XML?
E.g. what is the difference between position and bitposition? Or what does scale mean?

As i have a bit more time now, i think i can share the XLSX at the end of the week for discussion.

The next thing one can do with the info in the XLSX is “exploring” a new protocol version. By having the sum of the request bytes in a file it is quite easy to loop over them and query the heatpump via a rest-api call.

Sorry for any typos…i’m in a hurry…

161

No problem.
Take your time
Position is the byte position in the respond
For some infos the information is decoded in the bits of a byte.
If bitposition is not 0 it will decode 0 to false and 1 to true.
Heating program weekday is a typical example

162

Ok so here is my first throw.

https://1drv.ms/u/s!AnvMFS-QVBppjtlNrTXNUkczTr77TQ?e=fTTe7R

Extract.xslx contains the following infos:

Version, Type, Value, Position, ConversionInfo, Command (HEX), Command2 (HEX), argMin, arfMax, Unit, Comment

No XML annotations in Extract.xlsx so far.
This is a exctraction and conversion of all protocols in 00_THZ.pm
It also includes the “break-up” of the structures that are used in the FEHM PM file.

Types.xslx contains some addintinal information… don’t know if we need this as moste of the info is in the Extract.xslx.

Based upon that i will start woking on my 5.09 protocol.