Tahoma Binding compatible with OH2

Hi,
I have prepared a new version with these changes:

  • added HTTP keep-alive
  • listens to events rather than polling states for each device

I hope this will solve the your connection problems (and also sends fewer messages to TahomaLink cloud, so it spares your internet bandwith and CPU :-))
Could you please test it?

https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1

thanks.
Ondrej

Hi Ondrej,

thanks for the lighting fast update! Iā€™ve deployed it just now and will monitor it.

Kurt

Hi,

Iā€™ve added basic support for HeatingSystem thing (with target_temperature, current_temperature and battery_level channels) . Autodiscovery should work too.
Could you please test it?
https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1

thanks.
O.

I got this error when I try to add an auto-discovered thing (PaperUI / INBOX):

21:09:32.603 [WARN ] [ig.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type somfytahoma:heatingsystem.
21:10:08.439 [ERROR] [thome.core.thing.binding.ThingFactory] - Thing factory (class org.openhab.binding.somfytahoma.internal.SomfyTahomaHandlerFactory) returned null on create thing when it reports to support the thing type (somfytahoma:heatingsystem).

Best,
Roth

You are right, I think Iā€™ve fixed it.
Please, download the latest snapshot
https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1
Thanks for testing.
Ondrej

Added properly!

It looks like ā€œcurrent_temperatureā€ linked Item is always NULL.
I waited for 30 minutes, but it is still NULL.

Thanks,
Roth

Iā€™ve found the bug.
Please redownload it once more from
https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1

current_temperature should be working now.
Please let me know if itā€™s working.
Thanks.
Ondrej

At startup ā€œcurrent_temperatureā€ is NULL and then it gets updated. So the ā€˜mechanismā€™ looks OK.
However, the value is divided by 100 (ie: its value is 0.19 instead of 19).

Concerning ā€œtarget_temperatureā€ at startup the value is OK (ie: 19 for 19Ā°C) but then it get updated to a decimal one, divided by 100 (ie: 0.19).

So, for me it looks like there is just this ā€˜decimal issueā€™ to solve.

Thank you!
Roth

Hi Ondrej,
Thank you for this nice binding.
I am just testing it for few days and discover new unsupported io devices in the log :
2018-04-18 17:47:05.827 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: HeatingSystem
2018-04-18 17:47:05.827 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { cancelHeatingLevel (params: 1); delayedStopIdentify (params: 1); getName (params: 0); identify (params: 0); off (params: 0); refreshHeatingLevel (params: 0); setHeatingLevel (params: 1); setHeatingLevelWithTimer (params: 2); setName (params: 1); startIdentify (params: 0); stopIdentify (params: 0); wink (params: 1); setHeatingLevelForTrigger (params: 1); }
2018-04-18 17:47:05.829 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=ā€˜core:NameStateā€™, type=3, value=GMDE_Zone2}
{name=ā€˜core:VersionStateā€™, type=3, value=5600012e000020202020}
{name=ā€˜core:PriorityLockTimerStateā€™, type=1, value=0.0}
{name=ā€˜io:TargetHeatingLevelStateā€™, type=3, value=frostprotection}
{name=ā€˜core:OnOffStateā€™, type=3, value=on}
{name=ā€˜core:StatusStateā€™, type=3, value=available}
{name=ā€˜core:RSSILevelStateā€™, type=2, value=100.0}
{name=ā€˜io:MaximumHeatingLevelStateā€™, type=3, value=unknown}
{name=ā€˜io:TimerForTransitoryStateStateā€™, type=1, value=65535.0}
2018-04-18 17:47:06.916 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { close (params: 0); delayedStopIdentify (params: 1); getName (params: 0); getOpenClose (params: 0); identify (params: 0); lock (params: 0); open (params: 0); refreshLockedUnlocked (params: 0); setLockedUnlocked (params: 1); setName (params: 1); setOpenClosed (params: 1); startIdentify (params: 0); stopIdentify (params: 0); unlock (params: 0); wink (params: 1); }

2018-04-18 17:47:06.917 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=ā€˜core:NameStateā€™, type=3, value=ā€œLock_01ā€}
{name=ā€˜core:PriorityLockTimerStateā€™, type=1, value=0.0}
{name=ā€˜core:StatusStateā€™, type=3, value=available}
{name=ā€˜core:RSSILevelStateā€™, type=2, value=86.0}
{name=ā€˜core:LockedUnlockedStateā€™, type=3, value=locked}
{name=ā€˜core:OpenClosedStateā€™, type=3, value=closed}

2018-04-18 17:47:06.132 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { close (params: 0); delayedStopIdentify (params: 1); getName (params: 0); getOpenClose (params: 0); identify (params: 0); lock (params: 0); open (params: 0); refreshLockedUnlocked (params: 0); setLockedUnlocked (params: 1); setName (params: 1); setOpenClosed (params: 1); startIdentify (params: 0); stopIdentify (params: 0); unlock (params: 0); wink (params: 1); }
2018-04-18 17:47:06.132 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=ā€˜core:NameStateā€™, type=3, value=ā€œLock_02ā€}
{name=ā€˜core:PriorityLockTimerStateā€™, type=1, value=0.0}
{name=ā€˜core:StatusStateā€™, type=3, value=available}
{name=ā€˜core:RSSILevelStateā€™, type=2, value=94.0}
{name=ā€˜core:OpenClosedStateā€™, type=3, value=open}
{name=ā€˜core:LockedUnlockedStateā€™, type=3, value=unlocked}

Hope you can add this devices in your futures releases.

Best regards,

jpf

Hi, of course I can add it. It seems that your HeatingSystem thing is completely different from the one owned by @rothm
As far as I can see you canā€™t set the target_temperature nor get the current_temperature, but you can set it ON/OFF and you can set heating level state (e.g. frostprotection - not sure what are the other states)

The other two devices are pretty interesting, I have not seem them yet and I guess they are locks. It seems you have not copied all the neccessary log parts.
Could you please look for someting like "Detected a new unsupported device: " ending with the ā€œLockā€ word or something like that in your openhab.log?
thanks.

Hi, Ondrej,

Here is the missing part of the log for the 2 lock devices :

2018-04-18 17:47:06.131 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: DoorLock

2018-04-18 17:47:06.916 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: DoorLock

Best,

jpf

Great!
It is exactly what I was looking for :slight_smile:
These things are very easy to add since they are similar to contact sensors reporting Open/Close
Iā€™ll add them soon, the heating system is under development right now.
Thanks
Ondrej

Hi Ondrej,

The Heating System device is capable of swithing two heating zone ā€œGMDE_Zone1ā€ and ā€œGMDE_Zone2ā€ from four different mode ā€œON/OFFā€, ā€œFrostProtectionā€, ā€œConfortā€, ā€œEcoā€. The temperature for the different mode ā€œEcoā€ and ā€œConfortā€ can be adjust directly on each radiator connected to the device. The device is also a load shader able to balanced the power between the two zone GMDE_Zone1 and GMDE_Zone2 to avoid cutting of ll the installation depending the power subscribed.

Below the part of the log concerning the GMDE_Zone1 which was not included in my precedent mail :

2018-04-18 17:47:05.212 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: HeatingSystem
2018-04-18 17:47:05.213 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { cancelHeatingLevel (params: 1); delayedStopIdentify (params: 1); getName (params: 0); identify (params: 0); off (params: 0); refreshHeatingLevel (params: 0); setHeatingLevel (params: 1); setHeatingLevelWithTimer (params: 2); setName (params: 1); startIdentify (params: 0); stopIdentify (params: 0); wink (params: 1); setHeatingLevelForTrigger (params: 1); }
2018-04-18 17:47:05.218 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=ā€˜core:NameStateā€™, type=3, value=GMDE_Zone1}
{name=ā€˜core:VersionStateā€™, type=3, value=5600012e000020202020}
{name=ā€˜core:PriorityLockTimerStateā€™, type=1, value=0.0}
{name=ā€˜io:TargetHeatingLevelStateā€™, type=3, value=frostprotection}
{name=ā€˜core:OnOffStateā€™, type=3, value=on}
{name=ā€˜core:StatusStateā€™, type=3, value=available}
{name=ā€˜core:RSSILevelStateā€™, type=2, value=100.0}
{name=ā€˜io:MaximumHeatingLevelStateā€™, type=3, value=unknown}
{name=ā€˜io:TimerForTransitoryStateStateā€™, type=1, value=65535.0}

Best,

jpf

Hi Ondrej,
after some time of monitoring, I can report that the error is unfortunately still there. :frowning:
Is there anything I can do to help finding the root cause?

Kurt

Hello,

this binding is currently under a code review from OpenHAB community members and I have to implement several changes according to valuable comments.
Changes:

  • https communication is completely rewritten to use jetty library (OH standard, it might solve some connection issues)
  • action group channel ā€œtriggerā€ is renamed to ā€œexecuteActionā€
  • discovery process is now separated from the bridge functionality
  • added new things: HeatingSystem and DoorLock
  • thing states are now changed when Tahoma event is received (no periodic states polling thus lower communication)

Known issues:

  • automatic things discovery does not work yet (you have to start the discovery manually)

https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1

Could someone try this version please? Donā€™t forget to backup your current working version :slight_smile: (donā€™t worry marketplace version is stable)
Thank you very much
Ondrej

Hi,

with this version, my rollershutters donā€™t go online and remain in initialization state.
Actiongroups go online.

Kurt

Thanks for testing.
I guess you have RTS devices which do not return any state, so the the binding waits for the availability status infinitely.
Could you please try this version?
https://www.dropbox.com/s/nx3gq8aa0f06bc6/org.openhab.binding.somfytahoma-2.3.0-SNAPSHOT.jar?dl=1
Thanks

Ondrej

Hi,
youā€™re right, Iā€™m having RTS rollershutters. The updated version is discovering them and recognizes them as online.

thanks for the work!
Kurt

Hi Ondrej,

after some testing: I noticed that the actiongroups are updated partially:

I have one (RTS) actiongroup which got updated as you described in your post: Channel is now ā€œexecuteActionā€. The rest of them remained on ā€œtriggerā€. As a result the actiongroups on ā€œtriggerā€ remain linked to the original item and donā€™t fire anymore.

Kurt

Good morning,

please remove these actiongroup things (these with trigger channel) and re-add them by manual discovery.
The right channel ā€œexecuteActionā€ should appearā€¦
Thanks.
Ondrej