Hue & lightify creeping incompatibility?

I own some lightify plugs and surface light. Usually these were connected to the hue bridge. A few weeks ago i connected them via the lightify gateway, leaving the other bulbs at the hue bridge.

After some trying with the lightify binding i decided to switch them back to the hue, removing the Lightify Gateway completely from my installation.

All items, the hue bridge, the lightify gateway, the plugs and the surface light received updates while being separated. After joining all of them at the hue bridge again, i discovered a dropped network connection at the bridge every few minutes. It looks like it resets itself all the time (network & internet light turned off). After removing the lightify stuff, the behaviour is gone again. It comes back whenever the first lightify component is connected to the hue bridge.

I did a factory reset of the hue bridge only to discover the same behaviour again after joining the first lightify component.

I did not discover this behaviour when i connected all to the hue bridge at first. (I can’t run a clean up on the hue, the connection drops before it is finished, whenever just one lightify component is connected. I used the clean up several times before without any problems, with and without lightify components.)

The plugs use version 01020509, the surface light 01020510, the hue bridge 1707040932.

Does anybody discover the same behaviour? Or a different one in a similar setup?

BTW, this is not a openHAB issue, i turned openHAB off completely, network drops are still existing.
Sorry for posting here, but i am not aware of any hue/lightify forums. Please use it as a warning if you own a similar setup.

Edit: Thanks. Somehow i misread the links at first. I’ll try there. :wink:

The 01020510 firmware has a couple of “features” that I’ve noticed. One is that it seems as though it sometimes doesn’t respond or responds badly sometimes and the Lightify gateway reports it as having not been heard from for >5mins followed almost immediately by an ok-here’s-the-status. The other thing is that it reports an increased white range of 1501K to 8000K. The previous 01020412 firmware reported 2702K to 6622K. The official range for my PAR16 RGBWs is 2000K to 6500K. Neither of these is an obvious candidate for crashing a controller but… Curiously after updating my first set of 4 PAR16s I swapped over to the second set (I’m still testing so haven’t installed everything yet) the Lightify app hasn’t yet offered me the update for them so it’s possible problems have been noted and a hold issued. OSRAM have no release notes, no bug lists, no forums… :frowning:

If you want to go with the Hue bridge you could try emailing I believe they might be able (although not necessarily willing) to force a downgrade via your Lightify gateway and their cloudy management system.

Alternatively there’s a new “osramlightify” binding in the PR queue and in active development. If you have problems/suggestions/ideas I’d love to know!

I’ve seen your binding, but was unable to set up a build environment to create the jar. So i couldn’t test. :frowning:

If you could direct me to a jar, i would happily test it.Thanks in advance.

The latest jar from the auto-build can be found here. Or you can go via the marketplace entry here. You can’t install it via the openHAB marketplace add-on yet apparently because the marketplace backend REST API limits entries per response to 25 (10 for non-smarthome clients) an there are more than 25 entries in the IoT catalog :frowning:

Thanks. I installed the binding, got my Surface light discovered.

I can issue exactly one command, afterwards the binding dies with the following log entry:

2017-08-17 16:59:09.354 [ERROR] [mlightify.internal.LightifyConnector] - Connector died: 
	at org.openhab.binding.osramlightify.handler.LightifyDeviceHandler.changedTemperature( [229:org.openhab.binding.osramlightify:]
	at org.openhab.binding.osramlightify.internal.LightifyDeviceState.fullRefresh( [229:org.openhab.binding.osramlightify:]
	at org.openhab.binding.osramlightify.internal.LightifyDeviceState.received( [229:org.openhab.binding.osramlightify:]
	at org.openhab.binding.osramlightify.internal.messages.LightifyListPairedDevicesMessage.handleResponse( [229:org.openhab.binding.osramlightify:]
	at [229:org.openhab.binding.osramlightify:]

After a restart, the gateway doesn’t come online again.

2017-08-17 17:13:34.571 [hingStatusInfoChangedEvent] - 'osramlightify:tunable:84-18-26-00-00-0A-89-CE' changed from UNINITIALIZED to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2017-08-17 17:13:45.958 [hingStatusInfoChangedEvent] - 'osramlightify:gateway:017ba969' changed from UNINITIALIZED to INITIALIZING
2017-08-17 17:13:45.988 [hingStatusInfoChangedEvent] - 'osramlightify:gateway:017ba969' changed from INITIALIZING to UNKNOWN
2017-08-17 17:13:46.063 [hingStatusInfoChangedEvent] - 'osramlightify:tunable:84-18-26-00-00-0A-89-CE' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2017-08-17 17:13:46.079 [hingStatusInfoChangedEvent] - 'osramlightify:tunable:84-18-26-00-00-0A-89-CE' changed from INITIALIZING to UNKNOWN
2017-08-17 17:14:06.090 [hingStatusInfoChangedEvent] - 'osramlightify:gateway:017ba969' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR)
2017-08-17 17:14:06.090 [hingStatusInfoChangedEvent] - 'osramlightify:tunable:84-18-26-00-00-0A-89-CE' changed from UNKNOWN to OFFLINE (BRIDGE_OFFLINE)

I even need to remove the gateway from the wall socket afterwards. Here are the versions:

That’s a strange one. I’d have expected an exception between the “Connector died” and the first “at…” at least. Can you post a 10s worth of log at TRACE (one poll’s worth of state query) and then a full start-to-dead log at DEBUG?

The surface is a tunable white, right?

Yes, it is.

Here’s the first log. I filtered by “lightify”. It’s trace level from start to dead.

The other one is filtered around the dying timestamp (2017-08-17 20:15:5). Sadly the multiline exception is
omitted, but the exception is also in the other log.

Not exactly what you asked for, but if i didn’t filter the log would be huge. If something is missing, just let me know. i can reporduce the effect.

Please don’t filter by lightify. The important part of that call chain is not in osramlightify at all. If you must filter do it by removing what you know to be irrelevant rather than keeping what you think might be relevant.

It appears to have died while trying to update the absTemperature channel with a number which corresponds to the probed maximum temperature. I can’t reproduce it on openHAB 2.1.

I will post the needed logs later, thanks.

Edit: Sorry, I don’t have the spare time tonight, will prepare the logs at the weekend.

Sorry for the delay, was really busy. Here is the complete log from lightify gateway going online until the connector died:

I did nothing but switching the light on.
Here are my items:

Switch  Tisch_Toggle "Esstisch Toggle" <light> (ghueKT)  { channel="osramlightify:tunable:84-18-26-00-00-0A-89-CE:dimmer" }
Dimmer  Tisch_Dimm "Esstisch Dim" <light> (ghueKT)  { channel="osramlightify:tunable:84-18-26-00-00-0A-89-CE:dimmer" }
Dimmer	Tisch_ColorTempAbs	"Esstisch Abs" <slider> (ghueKT) {channel="osramlightify:tunable:84-18-26-00-00-0A-89-CE:absTemperature"}
Dimmer	Tisch_ColorTempP	"Esstisch Perc" <slider> (ghueKT) ["Lighting"]	{channel="osramlightify:tunable:84-18-26-00-00-0A-89-CE:temperature"}

Hope that helps. Thanks.

Here is another log, this time i used the latest osramlightify binding (2017-08-24), results are similar.

I restarted the bundle several times via karaf console, the result was always the same.

Hope that helps as well

Unless I am very much mistaken you appear to have something other than a Number item (probably Dimmer or Color) linked to the “White Temperature (K)” channel. PaperUI doesn’t let you do that but possibly the console is less strict. If you want a temperature slider you MUST link the Dimmer item to the % channel and it will then vary the temperature between the min and max (defined in the device config, bridge config or probed in that order). Dimmers are ALWAYS % regardless of how they are labeled in any UI. There’s no concept of a range type/item other then % in openHAB (at the moment).

1 Like

Thanks. That was the problem.

I just copied the percentage config to the absolute config without thinking or reading the manual. Sorry.

But nevertheless, i don’t think a misconfiguration should completely crash the binding.