Milight 2.4 - V3 bridges going offline

[LordGame (Adam Gem)]

Well, I had a few rounds with this protocol already and I failed every time So I agree it is extremely hard to manage. I think it is the time for me to check out the esp based custom bridge, meanwhile I am going to try simplify my rules and play with the configuration.

Thanks for the help anyway.

[pauldsmyth (Paul Smyth)]

@MikeJMajor

I think there’s two issues with the 2.4 release. The first is that it doesn’t work when you have multiple bridges and the second is the timeout issue.

Can you try org.openhab.binding.milight-2.5.0-SNAPSHOT.jar

Thanks Mike, half a fix anyway.

@David_Graeff Mike’s jar file has my bridge back online but no commands at all are working

[pauldsmyth (Paul Smyth)]

Additional info:
2018-12-31 15:20:05.222 [WARN ] [milight.internal.protocol.QueuedSend] - Failed to send Message to ‘10.0.100.111’: Socket is closed
(Obviously 10.0.100.111 is the ip address of my bridge)

[MikeJMajor (Mike Major)]

I see that problem after I’ve updated the bridge config in paperui, but a restart of OH seems to sort it for me.

[pauldsmyth (Paul Smyth)]

Well another restart with an added clear cache and the socket closed message goes away but no joy getting any bulbs to turn on or off. Double checked the easy bulb app to ensure that they’re still working which they are. Does anybody have the 2.3 jar by any chance?

[MikeJMajor (Mike Major)]

Did you try removing and readding your bulbs after upgrading to 2.4? The bulb zone is now part of the config rather than being part of the id.

[MikeJMajor (Mike Major)]

@David_Graeff, I still think I’m seeing some odd behaviour with the 2.4 binding. When OH restarts I send the last known state to all the lights in case there has been a power cut and the house is lit up like a Christmas tree. This is no longer reliable with lights staying on even though they have been sent an OFF command.

I’m looking at the code and in particular the AbstractLedHandler.uidc method. Does this actually work when you have multiple bridges? It looks to me like the same bulb type in the same zone will produce the same id for each bridge. So two bridges trying to turn off the same zone at the same time is going to result in one of those commands being removed from the global send queue.

[David_Graeff]

@MikeJMajor

So two bridges trying to turn off the same zone at the same time is going to result in one of those commands being removed from the global send queue.

True. The bridgeID should be part of the command id.

[MikeJMajor (Mike Major)]

I’ve had a go at fixing it. I’ll submit a PR shortly

PR

[pauldsmyth (Paul Smyth)]

@MikeJMajor

Did you try removing and readding your bulbs after upgrading to 2.4? The bulb zone is now part of the config rather than being part of the id.

I’ll give it a go

[pauldsmyth (Paul Smyth)]

By jove she’s got it!! All fixed. Thanks @MikeJMajor

[usambara (Ulrich)]

Now I tested the provided jar file and the bridge is online again!

[intruder82 (Vaidas)]

Hello, having problem with this binding… I added the milight bridge (old version) to the things although it was not found automatically but after manually entering IP and MAC it showed up under things with constant “online” indication.

added lamps but when I send the commands I get:
“2019-11-04 20:18:48.104 [WARN ] [milight.internal.protocol.QueuedSend] - Failed to send Message to ‘192.168.1.117’: Socket is closed”

I’m running OH 2.4 under Synology diskstation. It’s a new install with first bindings… Am I missing some obvious fix here? I assume this fix was merged in to the binding/OH or do I need to somehow merge it in manually?

P.s. and just noticed that under things if I open the lamp under channels I see only

Nightmode

Brightness

Color temperature

Animation mode

and no ON/OFF channel… which RTFM part have I skipped?..