openhab-addons
openhab-addons copied to clipboard
openhab
[kermi] Initial contribution
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
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 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.
@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!
@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 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!
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 ?
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 https://github.com/openhab/openhab-addons/pull/15687 anymore - consider it the be virtually closed.
@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
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 Thanks for your review. I corrected / improved the code. Please re-review.