EspMilightHub new binding for milight limitlessLED and easybulb

openHAB 4.0.0
Build #3412
On the first snapshots OH4 the binding worked, now it doesn’t work. I can’t say exactly when it stopped working. File configuration.
milight.things:

Thing mqtt:rgbw:0x20110 "milight-0" (mqtt:broker:garage) @ "milight"
Thing mqtt:rgbw:0x20111 "milight-1" (mqtt:broker:garage) @ "milight"
Thing mqtt:rgbw:0x20112 "milight-2" (mqtt:broker:garage) @ "milight"
Thing mqtt:rgbw:0x20113 "milight-3" (mqtt:broker:garage) @ "milight"
Thing mqtt:rgbw:0x20114 "milight-4" (mqtt:broker:garage) @ "milight"


If you disable these things from the interface and turn on the discovery and switch, for example, the first light bulb from the esp8266 interface, then the thing will be added to the inbox. Next, in the inbox, click - add a thing and restart oh4, we get the following:

Does anyone have it working on the last snapshots?
Thanks!

Can you try a snapshot just before this was merged? JFROG can be used to get different builds of just a bindings jar to trial without changing the core.

Since the binding uses the core for mqtt connectivity, its possible for other changes in the core or the MQTT binding itself, to effect this one. So if we can narrow it down to which PR caused the break it will speed it up. I am on v4.0m1 and going to move to m2 tonight so probably will find its broken, so thanks for the heads up.

I’m running 4.0.0.M2 and espmilighthub is working without any problems.

Mine is broken after the update, the bridge comes online but all child’s get stuck on initialising, wont be able to look into why for a week if not 3 weeks. The v4. 0 milestone 1 was working so it should be possible to use the binding jar from that build on top of the v4. 0m2 core to see the result. Jfrog server has the builds on it.

I did note that some other changes got added to the mqtt side that broke the homie binding and was fixed before release. This was noted in the v4. 0m2 release notes. So if someone trys the older jar in the m2 core that would help narrow the cause.

Reference? Release openHAB 4.0.0 Milestone 2 · openhab/openhab-distro · GitHub lists the espmilighthub state topic change, a minor logging change in mqtt.generic, and new support for JSON schema lights in mqtt.homeassistant (all done by me). There’s also a new MQTT Ruuvi binding I’m unfamiliar with.

Perhaps you’re referring to Binding in "NOT_YET_READY" state after recent core changes · Issue #3394 · openhab/openhab-core · GitHub, which yes definitely affected Homie and Home Assistant (but should not affect espmilighthub, since it uses static thing types)? Allow initialization of incomplete things by J-N-K · Pull Request #3397 · openhab/openhab-core · GitHub was the temporary fix, but it was already merged prior to 4.0.0.M1. There’s a more permanent fix, with the core piece pending review, and the pieces for the mqtt.homie and mqtt.homeassistant bindings not even started.

Sorry for the delay, I only have access to this ox4 setup during the weekend.
Unfortunately, I don’t understand what I need to do. You probably need to download older versions of the binding somewhere and put it in the add-ons folder. Thus, by sorting through the versions of the binding file, find the one that stopped working?
If so, let me know (url) where I can download these files, I couldn’t find it myself, sorry.

JFROG server has all builds, you just need to navigate the folders…

https://openhab.jfrog.io/artifactory/libs-milestone-local/org/openhab/addons/bundles/org.openhab.binding.mqtt.espmilighthub/4.0.0.M1/org.openhab.binding.mqtt.espmilighthub-4.0.0.M1.jar

I can confirm that rolling back to the M1 jar link above fixes the issue when using the M2 core and other bindings so it is not necessary to roll the installation back as you can just do the JAR.

@ccutrer I have had a chance to look at this and the cause of the things not coming online is this (see below) is not filled out, so the readme needs to be updated, OR add some backwards compatibility needs to be added.

milight hubs control page>SETTINGS>MQTT>

MQTT Client Status Topic

set it to a value of:

milight/status

I believe another issue causing WARN possibly will be fixed by this PR in the next milestone 3.

Improve precision of ColorUtil by andrewfg · Pull Request #3542 · openhab/openhab-core (github.com)

2023-04-25 15:59:34.256 [WARN ] [nternal.handler.EspMilightHubHandler] - Failed processing Milight state {"state":"ON","level":100,"color_temp":201,"bulb_mode":"white"} for milight/states/0x8/rgb_cct/1

java.lang.IllegalArgumentException: xy array only allowes two or three values between 0.0 and 1.0.

	at org.openhab.core.util.ColorUtil.xyToHsb(ColorUtil.java:277) ~[?:?]

	at org.openhab.core.util.ColorUtil.xyToHsb(ColorUtil.java:258) ~[?:?]

	at org.openhab.core.library.types.HSBType.fromXY(HSBType.java:144) ~[?:?]

	at org.openhab.binding.mqtt.espmilighthub.internal.handler.EspMilightHubHandler.calculateHSBFromColorTemp(EspMilightHubHandler.java:297) ~[?:?]

	at org.openhab.binding.mqtt.espmilighthub.internal.handler.EspMilightHubHandler.processIncomingState(EspMilightHubHandler.java:177) ~[?:?]

This will only occur if your globes are a RGB capable model.

downloaded, put in addons, it works, thanks!

I updated to Build #3475 and the link doesn’t work again. I have tried org.openhab.binding.mqtt.espmilighthub-4.0.0.M1.jar and org.openhab.binding.mqtt.espmilighthub-4.0.0.M2.jar. Can you please tell me which file should I use?

2023-05-20 20:32:12.293 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.mqtt.espmilighthub-4.0.0.M2.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mqtt.espmilighthub [236]

  Unresolved requirement: Import-Package: org.openhab.binding.mqtt.discovery

I updated to Build #3476
Deleted all files from addons folder.
Cleared the cache.
Restarted OpenHab.
All things of my lamps look like this:
image
But from the sitemap I can enable white mode, night mode and disco mode. The channel level switch is always on for me, if you turn on the lamps from the esp interface, then from the site map, by pressing the level switch (on), the lamps will turn off, and the switch itself will return to the on state.

See my last post in this thread, it has the solutuon that needs to be done going forward. I did change the documents but they don’t seem to have changed on the site here yet probably as it is waiting till the next milestone is released for the changes to show up in the setting up the firmware section.

openHAB 4.0.0
Build #3474

Hub Version: 1.10.7 (d1_mini)

I was getting the Communication Error (Waiting for ‘milight/status: connected’) on my RGBW Things that had been discovered.

Setting MQTT Client Status Topic to: milight/status had NO effect.

On the HUB “Client Status Messages Mode” was set to “Detailed”

Changing to “Simple” fixed it for me.

Not sure if “Detailed” is the default? Maybe I changed it at some point in the past?

Perhaps this could be added to the Docs for future Reference?

Agree that should be added. Any chance you can? A single line edit is pretty easy to do and the sign-off is waived usually.

Had a go. Not familiar with GitHub. Hope its OK.

1 Like