[modbus.stiebeleltron] Binding enhancements with new Things and support for more (missing) channels

[tb4jc]

Description

This is a enhancement Pull Request for the Stiebel Eltron ISG binding. It is releated to the issue #12773.

• I added three new Things for the different WPMs "WPMsystem", "WPM3" and "WPM3i", one thing to support the Energy Management settings and information (SG Ready - only supported with an ISG plus)
• The new Things support the retrieval and control of more items of the heat pump.
• The binding still contains the original Thing to stay backward compatible.
• I added a German translation file.

Check the new README.md for more information about the new Things and channels.

Testing

I have tested the enhancement only with version 4.2.3 and using it since about 3 years with earlier releases.
The jar file for Release 4.2.3 and a snapshot build for 5.0.0 are here available. Note: I didn't tested the 5.0.0 snapshot build. I don't have an 5.0.0 beta installation.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/how-to-set-sgready-states-using-the-stiebel-eltron-isg-binding/155912/19

[GerdZanker]

Hello,

I tested the PR code with my 5.0.0-SNAPSHOT installation. Creating a bridge thing and an ISG + WPMSystem worked for me. I can see "old" value and get new values from the my real heating system. Good work @tb4jc !

Here some feedback for improvement & discussion:

1. I miss the backflow temperature of my heating system. It seems to be communicated with modbus register 542. Therefore I suggest to add the Heatpump1 modbus registers 542-548. The value of register 516 is always shown as 0 in my case.
2. I took a look at the code and can see several duplicated code parts inside the new files. Is a refactoring required before a PR merge?
3. The trace statements give details. But the output could be improved and better structured to really trace down what is happening inside the bundle. What do you think?
4. Perhaps the ISG can be discovered in the network and the ISG/WPM thing can be discovered afterwards based on try and error/success - but this an improvement idea if this PR is finished.

[tb4jc]

Hi Gerd

I'm sorry I didn't answer earlier. I'm ill since Silvester, now it's the first time at startet my computer again since then.

Thank you very much for your feedback. I appreciate it.

1. Have you checked the values directly on the ISG with a Modbus tool (e.g. I'm using https://sourceforge.net/projects/qmodmaster)? At least in the code, I haven't find any differences regarding parsing and handling of the value of 'ACTUAL RETURN TEMPERATURE'.
   Besides, yes I know there are many 'system values' missing for WPMsystem and WPM3 (all Heat Pump 1 to 6 and different circuits). If you can approve that adding at least Heat Pump 1 would be enough for you, then I could surely add it.
2. Yes, I fully agree, there is a lot of duplicated code. But as I'm not that used to Java and all its features, I made it as simple as possible; besides I don't really have another idea right how it could be simplified. My goal now also was to have the enhancements in the main branch as soon as possible, so that everybody can use it in the future.
   Who is in charge to decide if that needs to be done before merging? I don't know.
3. I didn't really care that much about the existing tracing code. I exteneded it where I needed to verify read values, but else it's more or less the same as before.
4. I don't know how I could add this feature. But I think it wouldn't really be such a big help as the required info can easily be found: IP address of ISG/ISG+, WPM version on diagnostic system page:
   

Does anybody know how we can proceed, if @pail23 is not going to review my changes? (it looks like he moved on th Home Assistant).

[GerdZanker]

I'm sorry I didn't answer earlier. I'm ill since Silvester, now it's the first time at startet my computer again since then.

No problem at all and good that you well again. My own response time is more like a week not not within a day.

Have you checked the values directly on the ISG with a Modbus tool (e.g. I'm using https://sourceforge.net/projects/qmodmaster)? 

No, not yet. But I will try the modbus tool and check the raw values. But I guess that not all "return temperature" registered are filled.

Regarding

1. I think the additional values for Heatpump1 are sufficient. I already modified your code and will proved a patch soon.

2. OK, fine for me - First goal is to bring enhancements merged to main! I will collect possible improvements and create an issues with my recommended changes after this PR is merge.

3. OK, I use the existing logging output

4. With the Bosch SmartHomeController Bundle I got some experience how the discovery works. Perhaps I can apply it here. I create openhab-addons issue [modbus.stiebeleltron] Support discovery for IGM and WPM things #18067.

[tb4jc]

1. I think the additional values for Heatpump1 are sufficient. I already modified your code and will proved a patch soon.

Sorry, didn't mention that I also already have some values in the code. No patch needed from your side, just confirmation with Modbus tool that heat pump 1 values are there.

4. With the Bosch SmartHomeController Bundle I got some experience how the discovery works. Perhaps I can apply it here. I create openhab-addons issue [modbus.stiebeleltron] Support discovery for IGM and WPM things #18067.

Ok, thanks.

[GerdZanker]

I can confirm to see values for heatpump 1.

But I have doubts about the address - need to cross check my results...

Update: I cross checked more registers and the register address number, shown in the tool on the left, needs to be increased by 1 to match to the Stiebel Eltron documentation PDF. Nut sure where and how, but the bundle code takes this into account.

Result: values of modbus registers 542 (backflow temperature) - 548 (flow rate) as defined in PDF for heat pump 1 are available in my heating system with WPMSystem.