Tahoma Binding compatible with OH2

Ondrej_Pecta · April 17, 2018, 9:59am

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?

thanks.
Ondrej

KurtS · April 17, 2018, 2:22pm

Hi Ondrej,

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

Kurt

Ondrej_Pecta · April 18, 2018, 6:56pm

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?

thanks.
O.

rothm · April 18, 2018, 7:11pm

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

Ondrej_Pecta · April 18, 2018, 7:26pm

You are right, I think I’ve fixed it.
Please, download the latest snapshot

Thanks for testing.
Ondrej

rothm · April 18, 2018, 9:20pm

Added properly!

It looks like “current_temperature” linked Item is always NULL.
I waited for 30 minutes, but it is still NULL.

Thanks,
Roth

Ondrej_Pecta · April 19, 2018, 11:10am

I’ve found the bug.
Please redownload it once more from

current_temperature should be working now.
Please let me know if it’s working.
Thanks.
Ondrej

rothm · April 19, 2018, 9:07pm

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

jpf · April 20, 2018, 8:20am

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

Ondrej_Pecta · April 20, 2018, 8:44am

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.

jpf · April 20, 2018, 8:55am

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

Ondrej_Pecta · April 20, 2018, 8:58am

Great!
It is exactly what I was looking for
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

jpf · April 20, 2018, 10:09am

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

KurtS · April 29, 2018, 1:23pm

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

Kurt

Ondrej_Pecta · May 1, 2018, 8:16am

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)

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

KurtS · May 1, 2018, 3:29pm

Hi,

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

Kurt

Ondrej_Pecta · May 1, 2018, 4:32pm

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?

Thanks

Ondrej

KurtS · May 1, 2018, 6:50pm

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

KurtS · May 2, 2018, 5:09am

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

Ondrej_Pecta · May 2, 2018, 5:22am

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