[kermi] Initial contribution

[KaaNee]

New Binding for Kermi Heat Pumps

Similar implementation like modbus e3dc binding, this is a simple modbus binding for kermi heat pumps with modbus-tcp connection activated.

It's an easier integration for a kermi heat pump, preventing creating modbus-things and items manually, which is some really annoying click-work and confusing with bridges, pollers, data-things and items for each single value.

Just create a Modbus TCP-Bridge, create a kermi x-center thing attached to this modbus-bridge and you're fine. Finally adding items to the desired channels.

OH community-thread: https://community.openhab.org/t/kermi-modbus-binding/153385?u=kane

[openhab-bot]

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

https://community.openhab.org/t/kermi-modbus-binding/153385/1

[lolodomo]

What's the difference with #15687 ?

[KaaNee]

@lolodomo This is a modbus binding and works without any authentication, the other type of binding is different. it uses an api endpoint, which i don't know that it may exist. But from my talks with kermi (manufacturer) the only way to get all the specific data is a modbus interface.
I could not find the specific Parameters of the heatpump in the other binding.
and: damit, i didn't find the other binding before.

By the way i contacted col-panic for exchange our knowledge, but currently i think both bindings are useful, maybe they work on different models.

[col-panic]

@lolodomo This is a modbus binding and works without any authentication, the other type of binding is different. it uses an api endpoint, which i don't know that it may exist. But from my talks with kermi (manufacturer) the only way to get all the specific data is a modbus interface. I could not find the specific Parameters of the heatpump in the other binding. and: damit, i didn't find the other binding before.

By the way i contacted col-panic for exchange our knowledge, but currently i think both bindings are useful, maybe they work on different models.

As described in my contribution, I reverse-enginered the binding by analysing the web-interface of the kermi heatpump's x-center. It is not as elegant as this solution, which by the way seems to be supported by the producer kermi - who never reacted to my mails - but it does not require a modbus binding. (I don't know modbus enough - that is, i only know the 2-wire modbus connections where you have to have special hardware, with my binding you don't need this).

Still, as this seems to be in some way supported by the producer, I'd be in favor of this binding!

[KaaNee]

@col-panic Hi, thanks for your participation to explain the difference.

So #15687 is a binding, which connects to the WebBackend in the cloud, which is normally used by the kermi-(mobile)-app.

This binding is for non-cloud / local access to the current values, it works with modbus TCP, so only local network access is requiered. For other (older) versions of the heatpump, additional hardware (converter from modbus RTU to modbus TCP) may be needed, which uses to connect by 2-wire-connection.
I described this in the readme of this binding.

[col-panic]

@col-panic Hi, thanks for your participation to explain the difference.

So #15687 is a binding, which connects to the WebBackend in the cloud, which is normally used by the kermi-(mobile)-app.

This binding is for non-cloud / local access to the current values, it works with modbus TCP, so only local network access is requiered. For other (older) versions of the heatpump, additional hardware (converter from modbus RTU to modbus TCP) may be needed, which uses to connect by 2-wire-connection. I described this in the readme of this binding.

No, not in the cloud! I use it to directly connect to the x-center in my local network!

[lsiepel]

We should prevent two bindings that have a very high overlap. Could we somehow intetgrate both binding proposals into one?
If i understand correctly both PR's have some sort of the same channels / functionality, and connect to the same x-center device. Only difference is the connection by modbus vs webapi?

What would be the best way of moving this forward @KaaNee and @col-panic ?

[col-panic]

This binding seems to be definitely the better one, as there seems to be at least some support by the manufacturer! I don't think that the code I have written can contribute anything to the functionality implemented in this PR.

It seems like @KaaNee did directly mail Kermi about opening the ModbusTCP - I will have to find out, whether this approach is feasible with my franchised version of Heizbösch. But It would be nice, if you could elaborate more on the mail exchange with Kermi. Did they enable this feature remotely?

Don't consider #15687 anymore - consider it the be virtually closed.

[lsiepel]

@col-panic can you perform some kind of review ? check if all the channels and use-cases that you had covered are available here. Maybe if there is a (small) gap, this can be implemented right away by @KaaNee

[KaaNee]

We should prevent two bindings that have a very high overlap. Could we somehow intetgrate both binding proposals into one? If i understand correctly both PR's have some sort of the same channels / functionality, and connect to the same x-center device. Only difference is the connection by modbus vs webapi?
What would be the best way of moving this forward @KaaNee and @col-panic ?

Hi @lsiepel. yes, you're right. both are nearly the same, having the difference in their connection.
one should be available in OH, not two.

My binding requires manual remote-settings from Kermi, which maybe can be a blocker for some users, if kermi (or similar manufacturer) isn't that supportive, maybe difficult to "force" them to add these settings in every users heating-central. The other binding from @col-panic is just working out of the box, maybe for more devices-types, we don't know.
On the other way, i think modbus is more reliable because they won't change any adresses in their products, or very unlikely that this will happen.

Long Story short: @col-panic Maybe you can publish your addon in the addon-store that your work won't be lost and used by every user which does not succeed or don't want the changes by kermi.

@col-panic can you perform some kind of review ? check if all the channels and use-cases that you had covered are available here. Maybe if there is a (small) gap, this can be implemented right away by @KaaNee
Some Settings are not implemented yet, these are just routine work to add them. I have the documentation for them.
This version is a "first cut" to have the basic and most important settings.

@col-panic If you disagree, than i could publish this on the addon-marketplace - the other way round. I'm fine with both solutions.

[lsiepel]

First review pass. Looked at the first 20 files mainly focused on the things, channels and structure. The comments i made apply to all channels and channel types, so please also look at other occurences in the other xml files.

• Keep labels short, < 23 chars, 2-3 words and capitalized.
• Make good use of UoM
• Use system types if possible: https://www.openhab.org/docs/developer/bindings/thing-xml.html#system-state-channel-types

[KaaNee]

@lsiepel Thanks for your review. I corrected / improved the code. Please re-review.

[lsiepel]

I still need to look at the handler, bu don't want to hold back these comments. Most of the code looks solid. Also had a quick peek at the readme and noticed the channels need to be aligned with the thing xml files.

[lsiepel]

Ran out of time, don;t want to hold back the comments so far. The last two files we have to look at, so getting closer.

[lsiepel]

Common mistake where the openHAB remote repository is directly merged into the feature branch. To prevent this i always merge openhab/main => my fork/main => my feature branch. Not sure if that was also the cases here, but it seems fixed already.

[lsiepel]

Last few comments, otherwise LGTM. Do you need some time to test the binding after all these changes?

[KaaNee]

Do you need some time to test the binding after all these changes?

Yes, i will do some final testings on a fresh system, will report back when finished.
This should not take more than a few days, maybe after next weekend.

• Final Testing

BTW: I created a script for generate "Items"-Files, this is useful for other devs, too. Is there a good place to drop it ?
https://gist.github.com/KaaNee/066a97d4f6acb32b2dee558527a0355f

[lsiepel]

Thanks again for this contribution. LGTM. Ping me when you are finished with the tests.

Next step would be to add the binding logo to the openHAB website. See https://www.openhab.org/docs/developer/addons/#add-your-add-on-s-logo-to-the-openhab-website