New binding Resol VBUS

RESOL-LAN Firmware version: 2.0

good to know, but I meant the solar controller not the VBUS-Interface.

Oh ok. Itā€™s a Cosmo Multi2

1 Like

Thanks for filing the issue.
It looks like thereā€™s already a solution on the way.
Cheers.

Yes, Daniel is working on it, it should be only a matter of time until a new library version is released.

@bernhard and @jhardy08 are you planning to switch to OH3 any time soon - or did you already? - or do you need a 2.x version of the binding (when we have a robust solution)

The OH3 version of the binding is now in review stage for merging it into the OH distro, and Iā€™d be happy if I need to care about one version only. - Theoretically it is not a problem to backport the change but the OH development environment is so troublesome for me that I fear changing back to 2.5 for compilationā€¦

Well for me I would think itā€™s too early to switch to OH3. I am using the KNX and Resol bindings plus the node-red-contrib-openhab2 together with NodeRed to send some energy measurement data to OH2. If everything works well with OH2 I donā€™t see any reason to switch.

But at one point itā€™s always better to upgradeā€¦ If itā€™s for a robust Resol binding I will be happy to switch earlier :slight_smile: I understand that itā€™s much easier to concentrate on only one version and I am grateful of your effort.

By the way I have a complex installation running on Resol (visible here) and there is not handy way to change thermostat setpoints. If there was a way to send parameter to Vbus it would be a big plus.

Yes I understand. @jhardy08 which solar/system controller do you use? Is it by chance one that can be extended with an EM module?

The issue with writing parameters is, that the changes are stored in flash memory in the device and this will wear out. Manually you will not reach the limit, but if you are using a machine (e. g. openhab) to change the parameters it could easily be reached after a few months or years. So I am not too happy about allowing to change parameters (beside the effort :slight_smile:)

On the other side, I am working on support for emulating such an EM device, which could extend some (not many, but at least the MX and the BXPlus) controllers by additional relays and sensors - and those will be a good fit for the OH interface to emulate room control units and even virtualize temperature sensors (and feed the outdoor temperature from the OH connected wheather station or even an online service) instead of measureing it physically with the controller.

The installation is controlled by a Deltasol MX with an EM module and connected to a DL2 datalogger.

Writing parameters is indeed not a good idea in these conditions.
But if itā€™s possible to emulate room control units it may give some control.

ok, if you have an MX it will be an option to let openHAB be a second EM, then you can control vitually everything by stimulating temperatures and room control units as you like. But this will definitly not be ported back to OH2 :frowning:

@ramack I plan to switch to OH 3 in the next months and will start testing next week so if it work in OH 3 it wold be perfect for me.
Thanks

@bernhard good.

On my local machine I have already a fixed version of the library integrated in the OH3 version which should avoid the problem.

Nice job, I have also setup an OH3 instance. If you need some testing please let me know.

Itā€™s from the middle of the rework for the review in the PR for merging it into the openHAB repository, but here is a version that should work.
As said, it is not yet cleaned up and there might be some further changes in names and types of channels or alike, but Iā€™d be happy if you could give it a try and see.
The README gives some more details.

The support of the simulated BAS (room control unit) is quite fresh and based on reverse-engineering the resistor values, but maybe it works already for you :slight_smile: - and here it is likely to have a change in the channel type to support symbols instead of the numeric modes.

I have now OH2 and OH3 connected to the same DL3.
So far so good, OH2 keeps on opening new tcp connections whereas OH3 has only one.
Good job!

Great, thanks for testing and letting me know.

12 days on and only one active connection on OH3.

Hi @ramack
Thank you for the OH3 binding :ok_hand:
Iā€™ve successfull scan and install my bridge : KM2
the ā€œdeDietich 2007ā€ device has been configured and all channels are working great.
Iā€™ve finally removed all those to create them via text-config files. (personnal preference)
The only thing that I need to fix is the refresh rate. Should be 60000 but the update is more frequent :thinking:
Great job. Thank you

Thanks for the feedback, Iā€™m happy that it works. The refresh of the data is maybe not really clear. Actually the data update is done by the binding as the controller is transmitting the data (the binding doesnā€™t poll it) the configurable refresh time is only relevant in case the connection fails to try to reconnect. I once though I could remove it and just use a fix time, but for now I have kept it.

Also the PR seems to reach the final track and hopefully it will be part of the next official OH release.

1 Like

Thanks for all the feedback I received here and all your patience to get this one here done. The binding is now officially included in the openhab source tree and will be part of the next milestone build and the 3.1 release.

3 Likes

Good jobs @ramack
Good news :clap: :clap: :clap: