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!
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?
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 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:
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?
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.
Thanks a lot, Martin! Much appreciated!
Iâve just merged your fixes.
Is it possible to also get the state of the Bypass?
I could not find it in the variable mappings.
Please use the following binding definition for a Switch item - this should provide the bypass status:
{ helios="summer_winter" }
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?
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.
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.
Thx rossko57,
but that was not the solution.
, autoupdate="false"
What does your events.log show now, though? Itâs a diagnostic move, not a solution.
2019-04-25 13:39:16.277 [ome.event.ItemCommandEvent] - Item âKWL_Partybetrieb_Dauerâ received command 180
In event.log no further entry is set where it has been changed back to 60min. But in sitemap is changed immediately to 60min.
Which suggests the command did not get sent to the device or was ignored by the device or old read values are stuck in the binding.
You are running the updated binding from January? I donât know anything else about Helios.
Yes I use the new binding.
I have now deleted my cache and tmp folder after stopping Openhab. It works after the reboot.
Thank you for your help rossko57.
But that with the status of the bypass does not work yet.
My apologies, apparently Iâm using my own binding wrong⊠
Since I donât actually actively do anything with the KWLâs bypass functionality, I never noticed this.
But Iâve just checked the Helios specification and the summer_winter variable actually only shows if itâs summer or winter time.
The bypass itself canât be activated or deactivated directly. You can only control its functionality via time or temperature based settings.
While I canât find any variables that would control the time based settings (which means you have to set this via the KWLâs web interface), you can set a room temperature (bypass_room_temp) or minimum outside temperature (bypass_min_outside_temp) which trigger the bypass to open.
Sorry for any confusion I caused. I hope that helps!
Since I was happy too early.
That was not the solution, I have the phenomenon again.
Logfile:
Item changed by me:
2019-04-26 09:31:04.510 [ome.event.ItemCommandEvent] - Item 'KWL_Partybetrieb_Dauer' received command 120
2019-04-26 09:31:13.523 [vent.ItemStateChangedEvent] - KWL_Partybetrieb_Dauer changed from 60 to 120
Item changes itself:
2019-04-26 09:31:52.336 [vent.ItemStateChangedEvent] - KWL_Partybetrieb_Dauer changed from 120 to 60
Then again changed by me but with start command.
2019-04-26 09:32:04.611 [ome.event.ItemCommandEvent] - Item 'KWL_Partybetrieb_Dauer' received command 120
2019-04-26 09:32:04.636 [vent.ItemStateChangedEvent] - KWL_Partybetrieb_Dauer changed from 60 to 120
2019-04-26 09:32:09.950 [ome.event.ItemCommandEvent] - Item 'KWL_Partybetrieb' received command ON
2019-04-26 09:32:13.411 [vent.ItemStateChangedEvent] - KWL_Partybetrieb changed from OFF to ON
Then again by itself
2019-04-26 09:33:09.843 [vent.ItemStateChangedEvent] - KWL_Partybetrieb_Dauer changed from 120 to 60
And then the party mode is activated for 60min even though I have selected 120min.
No matter what duration I choose. The (Partybetrieb) party operation is always started for 60min.
Hi bern77
Where ist the openhab.cfg File in openhabian (OH2)? I canât find the directory.
Thank you for your help.