Helios Binding for Modbus TCP

Add-ons Bindings
32

Hi!

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!

Best
Sami

33

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.

34

@ssalonen Thanks for the update. Anyhow, @bern77’s answer shows, that it is actually not too interesting for me. Sorry for the noise.

35

I just stumbled across the following:
https://www.npmjs.com/package/helios2mqtt (Based on Modbus TCP)

Using the OH MQTT binding this might be a fairly easy way to integrate a Helios KWL with OH…

36

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?

37

Yes, the transport supports serial devices

Sami

38

@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?

39

Hallo
gibt es schon eine Lösung dafür ß
habe das gleiche Problem

Dirk

40

Hello,

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.

41

Hi kl8ter,

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.

Hope that helps!

42

Hi,

this works perfect for me, great work - even if it is quite old already.

I didn’t add the “legacy=true” in addons.cfg. What is the purpose of it?

43

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 :wink:
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…

44

I just installed the binding (https://github.com/bern77/org.openhab.binding.helios/tree/master/_release) and did some first tests. The connection works and values are received, operation mode can be set to manual and automatic.
Thank you for the great work and for providing this.

So far, I found one issue:

  • 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

Logs:
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

Do you have an idea what could be the problem?

45

I found some time to debug into this and could identify the problem.
Please find a pull request here: https://github.com/bern77/org.openhab.binding.helios/pull/1 and feel free to integrate if you agree.

1 Like
46

Thanks a lot, Martin! Much appreciated!
I’ve just merged your fixes.

47

Is it possible to also get the state of the Bypass?
I could not find it in the variable mappings.

48

Please use the following binding definition for a Switch item - this should provide the bypass status:
{ helios="summer_winter" }

49

I implemented it like this:

Switch KWL_Bypass "Status Bypass [%s]" { helios="summer_winter" }

...
Text item=KWL_Bypass
...

But unfortunately the status does not change …

Or is this not a status but a command to actively change the bypass?

50

Can it be that this phenomenon is also in the long run?
If I choose a duration, it will jump back to 60min after the next update.

51

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.