I think the transport is stable in the sense that there have been many positive experiences from the community.
I think the code can be considered stable, no large changes recently…
The pull request is still pending merge, waiting time for the maintainers to review the code. No ETA on that.
When it comes to Helios, my recent post shows one way for the implementation, and suggestions for going forward. However, that’s all from my side, not planning to develop anything for Helios specifically. Naturally if changes are needed from modbus transport, I am very willing to help!
Ah thanks for the clarification. I now understand, that I would need the Modbus/TCP interface for your binding. - Probably I am not willing to buy that. I would prefer to have a binding directly connecting to the RS485 interface used by the remote control.
I have to come back with one more question: @ssalonen did I see it correct, that the modbus transport should also support serial RS485 physical layer? @bern77 In that case a change to the modbus transport of your helios binding would be automagically support Modbus RTU, wouldn’t it?
@ramack I think so, yes.
However, I’ve not yet really progressed the upgrade to OH 2.0 for the Helios binding. To be honest, since so many OH bindings are still based on the 1.x architecture I don’t exactly feel an urge to move forward with this.
Maybe the implementation of @big_blue is some steps ahead here?
I am trying to install the Helios KWL binding some time ago. unfortunately, without success. I just can not get the binding installed.
I pushed the jar file into addons. Ip set up in the cfg. But how do I install the Jar file? or is it enough if it is there? what did i forget? or is not the binding with openHAB 2? I would be happy for any answer.
the binding does work also in OH2. All I had to do was copy it to the addons folder and enter an entry in sevices/openhab.cfg with helios:host=<your device's local IP address>
Also you need to set legacy = true in services/addons.cfg.
Thanks, I’m happy it’s helpful to you.
Actually, that’s also a bit of the problem - it works well for me so I’ve not really gathered the motivation to tackle an openhab2 version of the binding
The legacy=true setting should tell openhab to allow openhab 1.x bindings. But maybe that’s only applicable for the standard ones, not external ones…
I set the operation mode to manual with a switch widget in happanel
this works well and in the KWL webpage I can see that the mode was changed to manual
but with a next regular update of the status values, the operation mode item is set back to automatic
in the KWL webpage it stays at manual
the behavior is completely reproducible in my setup
2019-01-12 15:35:44.258 [ome.event.ItemCommandEvent] - Item ‘KWL_Manuell’ received command ON
2019-01-12 15:35:44.264 [vent.ItemStateChangedEvent] - KWL_Manuell changed from OFF to ON
2019-01-12 15:36:35.364 [vent.ItemStateChangedEvent] - KWL_Temp_Aussenluft changed from 4.4 to 4.5 2019-01-12 15:36:36.856 [vent.ItemStateChangedEvent] - KWL_Manuell changed from ON to OFF
2019-01-12 15:36:37.100 [vent.ItemStateChangedEvent] - KWL_Zuluft_RPM changed from 1602 to 1598
2019-01-12 15:36:37.357 [vent.ItemStateChangedEvent] - KWL_Abluft_RPM changed from 1640 to 1635
2019-01-12 15:36:37.862 [vent.ItemStateChangedEvent] - KWL_Temp_Zuluft changed from 18.7 to 18.8
In the first instance, I would disable autoupdate for these Items. To stop autoupdate assigning Item status in response to command, which you don’t want when you are polling true status from a modbus device. You should get a better view of what is really happening.