Solvis heat pump - Should I create a binding (and if yes, how complex should it be)?

Development Add-ons
1

I have a heat pump from German vendor Solvis. I’ve been using it with openHAB (using ModBus binding) for quite some time now, just reading some temperature values. I want to extend my automations by writing data to the heat pump. Last weekend I wrote a small spike, where I moved all my manual ModBus things/items to an own binding, this is working fine :blush:. According to Solvis’ ModBus overview, there are hundreds of registers, grouped in sensors, actors, solar heating and schedules for several heating and circulation circuits (if installed).

Now I’m wondering, if I should…

  1. Not write/publish a binding at all, because there’d be not enough interest in it, anyway (there are several topics for other SmartHome systems in the web, but only few for openHAB)
  2. Write a binding, offering only the Read Input registers (<200 registers, some of them would be grouped/combined to one channel)
  3. Write a binding, offering all channels (No.)
  4. Write a binding, offering channels based on configuration parameters (checkboxes for presence of solar heating, counter for amount of heating circuits; still a lot of channels)
  5. Write a binding, using the main connection as Bridge and all the sensor/actor/heating circuit groups as Things for the bridge
  6. Write a binding, offering basic Read Input registers visible in the UI, but allow all holding registers to be configured via textfiles/manual GUI magic (I never use the GUI so I don’t know the wordings)
  7. Something else I can’t think of.

I appreciate any comments, thank you!

Sascha

2
  1. Bindings only get written with these three things are present:
  • someone who posesses the hardware
  • the skills to write Java or willingness to learn
  • the willingness to donate their time and effort to make a binding

You seem to posess all three so that’s probably a good enough reason by itself to write a binding. The only reason OH doesn’t currently support it is because there has been no one who meets all three categories.

2., 3., 4., 5., and 6. any of these I’m sure would be an improvement over the current modbus approach. I’d probably choose 5 but I don’t have one of these nor the full range of what makes sense to have in OH for automation purposes.

1 Like