we have two central heating boilers from KWB since a couple of months installed and I’d like to integrate them now into our Openhab installation. Purpose for the moment is mostly monitoring (i.e. reading values) as controlling them is done mostly physically on-site or can be done via the KWB’s own portal.
There is no binding for KWB currently available, so I’m okay to develop and contribute it something. I managed to activate the Modbus TCP interface on both controls, they are already connected to our local network as well. Also I got an excel sheet with all the modbus parameters but as I’m quite new to the modbus topic, I have to admit that I need to learn how to interpret this ,-)
Just wanted to ask how to continue from here best: I noticed there is a generic (?) modbus binding. Would that be the best starting point to work on, parametrize somehow etc.? If it’s generic I suppose developing a standalone binding makes no sense at all, so what would be the best track to start this task for me?
Any hints welcome, thanks!
As usual with software, it depends. Binding gives you a chance to implement logic which is impossible or hard to achieve with modbus binding configuration. For example sunspec binding is there not only to get predefined registers but also to detect different encoding schema in registers and take care of it.
Each binding can also implement discovery, so based on broadcast messages sent by controller, you will be able to create a dedicated thing instance which will handle known KWB registers. Other point are quantities which are not supported by modbus binding core and have to be added later on. This means that if you ie. have an energy value stored in
W with two decimal points it is something which will force you to apply read/write transformation. Its basic but makes configuration more complex.
Overall look at the pros and cons - if your configuration is just plain mapping of registers then you will be fine with generic functionality. If you need to merge registers or make various transformations then it is some justification to make a dedicated binding. Another point - update of binding is usually straight as it forces user just to install new version while staying with configuration will force everyone to sync it. The more controllers (and variants of it) you have, the better tooling or the bigger amount of time you will need to complete that.
Okay, fair enough. “It depends” is definitly a good answer, to my experience as well ,-)) I’ll try to start first with a plain modbus client and also get hold of the modbus binding sourcecode. Yet I do not know what is required. I think the current binding is at least a good learning source.
I also own a KWB (EF2) since 2016. I built my own monitoring solution back in the days also based on Modbus (Perl-Script, InfluxDB and Grafana). I used Perl back then because it was simple to parse the Excel with the register definitions.
I’m exploring the possible approaches for a KWB native binding since a few quarters, but I lack the needed Java-skills. I can read/understand what OH bindings do and need to do, but never coded one.
If you want to approach a binding, I’m happy to help.
If you want to explore/debug Modbus, I recommend you start with mbpoll https://github.com/epsilonrt/mbpoll to read/set registers on the CLI.
The native Modbus-binding (that is used via config-files) has already been extended by device-specific ones. There you can study how they done it (e.g E3DC, Studer, Helios aso.)
My oberservations so far:
- if the binding should be generic, complete and usable for all real-world deployments, it will be a huge undertakting
- Boiler-types can’t be auto-detected/discovered, they’d need to be specified by the user as things
- heating-circuits, buffers aso could be discovered (by checking the status-register for each temp-register). But I would start the first binding iteration without any discovery
- you probably need mapping tables (valid registers per boiler-type) and a info-table how to interpret the registers (based on the Excel)
- based on Modbus restrictions one can only read a limited number of registers in one go. The register-layout is not really friendly here: eg. buffer-temp T1 registers are at 8708-8737 for all possible 15 buffer-tanks. T2 is 8742-8771 and so on. In my script I get T1, T2 each in one go and later only process the temps from the one buffer I use. Not sure if a binding should do the same or poll each register(pair: value/status) in its own poll-thread
Each of the existing Modbus-extension-bindings use their own approach on how to poll registers, how they define which registers to get and how to interpret them. None fits 100% to be reused IMHO for KWB.
As I said, I can help with experience with KWB Modbus but not really with coding.
I had a look on several of modbus extensions and Stiebel (ISG) is quite basic. You might look at it. It does not have many features (it didn’t work for my deployment), so its fairly easy to compare it with config files.
thank you very much for getting into this thread - I will PM you after easter holidays because I think we need to get together ,-))
My Java skill are quite okay and I always wanted to provide some added value to OH. As of my understanding modbus is a very basic protocoll (from what I tried out already, seems to be pretty basic / easy to understand from a protocol level), but the individualy implementation of vendor specific interpretation is >90% of the efforts. If you you have good knowledge of the KWB specific modbus interpreation, that could be a nice match for the two of us ,-) So I’ll get in contact with you next week.
I’ll also try to approach KWB directly, maybe it’s overly optimistic, but one has to do it