EspMilightHub new binding for milight limitlessLED and easybulb

Sure I will do this. Thank you for your help!

@matt1: I’m a bit lost in Github right now… I thought I know enough about Git and Github for this simple task but that’s apparently not the case… I somehow managed to screw up the PR and it’s closed now… Please let me know if I should create a new one… I’ve got all the changes here.

Hi @matt1!

Until today, I have used the jar in the addons catalog, openHAB3.1 # 2350
Updated to # 2361 today. After rebooting openHAB, I received EspMilligtHub binding errors, it was previously updated, everything was fine. I removed the addons jar from the catalog in order to establish the binding via the openHAB interface. But in the list of bindings, I did not find EspMillightHub bindings.


What am I doing wrong?

It does not show up because it is part of the mqtt binding, so to add things you click on mqtt binding.

I recently upgraded to openHAB 3.1.0.M4 (coming from 2.5)
So now I am using the mqtt esp milight binding, but I encounter a strange issue.
I have a Milight RGBW bulb configured as a “color” item like shown below:

Color RGBW_Bulb_E14_Color “test lamp E14 color” {ga=“Light”, channel=“mqtt:rgbw:0x11121:colour”}

When I use openHAB controls, within the openHAB android application, then I can change the colors and the saturation.
When the saturation is set lower than the threshold value the bulb changes to white mode.
The saturation slider in openHAB should now function as a brightness slider (I assume), but it doesn’t.
If I do the exact same thing with the Google home application it works perfectly.

Details:
When I change from a blue color to white then the openHAB log shows:

Item ‘RGBW_Bulb_E14_Color’ changed from 229.090912,81.960785,99.000000 to 0.000000,0.000000,99.000000

->Bulb changes to white
MQTT explorer shows {“command”:“set_white”}

When I now change the brightness with the slider then the openHAB log shows:

Item ‘RGBW_Bulb_E14_Color’ changed from 0.000000,0.000000,99.000000 to 0.000000,0.000000,30.000000

->Nothing changes
MQTT explorer shows {“command”:“set_white”} again

When I change the brightness from the Google home application the openHAB log shows:

Item ‘RGBW_Bulb_E14_Color’ changed from 0.000000,0.000000,30.000000 to 0.000000,0.000000,99

(note that there are no ‘zeros’ behind the last value)
->Brightness increases
MQTT explorer shows {“state”:“ON”,“level”;99}

Any help would be appreciated.

That can be disabled or changed where the threshold is, so this is normal.

No saturation is different to how bright a globe is. You can have pastel colours that are very washed out red for example but the globe is still bright. Saturation is the ratio of the white LEDs VS the raw colour/s.

You would need to look at the openHAB event log to see what command is being sent to the binding. The developer sidebar is one way to do this and it allows for filtering so you only see what you wish. I am guessing that google home is sending a brightness command to the event bus VS your sending a saturation change. You can link multiple controls back to the same channel so if you wish to have a separate brightness slider and color controls you can do this.

Do a search for OH3 widgets as there are a number of custom widgets people have created, one example is this one.

OH3 Color/White Bulb Widget - Add-ons / UIs - openHAB Community

Currently I am using the sitemap for the Android application, I don’t think there is that much flexibility.
Anyway, If I select the item from the openHAB settings page then I have HSB controls. Also with these controls the brightness settings only work when the bulb is in color mode.
The openHAB log shows what you would expect when the brightness changes. The last number changes, so that is correct. The problem is that the bulb doesn’t respond to this when it is in white mode when controlled from openHAB. When I use the google home app the openHAB log shows just one value, so instead of 0,0,50 it just shows 50 which actually changes the brightness of the bulb.
Below the sniffing results of the bridge when I change the brightness in openHAB from one value to another in white mode:

rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 13
Sequence Num. : 3B
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 13
Sequence Num. : 3A

When I do this with the google home application:

rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 0E
Sequence Num. : 40
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 03
Sequence Num. : 3F

Strange to see that the google home application sends brightness changes in white mode as a single value and openHAB itself as a complete HSB value.

You can do that with sitemaps, as mentioned you will need to create an extra item that is a Dimmer and link it to the same color or level channel (not sure which one, they should both work?) and this item can be placed into the sitemap as a Slider. But I am now very rusty on sitemap syntax. Best to follow the docs here…

EspMilightHub - Bindings | openHAB

Also please note that it is best to not spend too much time learning sitemap IMHO. Sitemaps are only for backwards compatibility and I have no idea how much longer they will be in openHAB, so it is best to learn the new UI way/method of doing things.

Now the binding is merged, I’ll probably look at doing some widgets to display the lights in a nice compact format that I like.

If you believe what your seeing is a bug, then please create a github ticket and I’ll take a look when I have some time. I dont know the raw data packets, only the mqtt messages and what the openHAB event bus states is happening is what matters.

Only it does not open for me?

It was not merged until after 3.0x stable was created so just to make it harder to find and to break links you now need to go to next.Openhab.org

1 Like

Sorry for my dummy request but where do I find a version for openHAB 2.5 of this binding? No way to find it anywhere in the KAR or on GitHub, Feature:intall in Karaf does not find anything neither.
Thank you for your support

I had the github marked private and have changed this for you.

Do not use these versions on openHAB V3.1+ as from that version it is built in and there are breaking changes between the two versions. So make sure you read the readme.md at this github instead of the official openHAB doc pages.

Releases · Skinah/EspMilightHub (github.com)

Great! Thank you! It will help until I can complete the migration to OH3.

A heads up for all users of the binding and rgb-cct globes that they can now have the white leds triggered from the colour wheel controls if your using 3.2 Milestone 1 and newer. It can be disabled and configured to a threshold value that you prefer. You have to read the NEXT version of the docs to get the information on this which is linked from the release notes.

Release openHAB 3.2.0 Milestone 1 · openhab/openhab-distro (github.com)

I use a WL-Box1 (because the iBox2 isn’t available anywhere) to control my led strips with 4 dimmers type Fut036. Is it possible to control my dimmers with this esp bridge? Or is possible to control the WL-Box1 via openhab tuya and mqtt?
Thanks!

A few times a month I have to restart openhab because my ESP milight doesn’t respond anymore. It is not a MQTT issue, because I have other non milight MQTT items which continue to work. If I control the bulbs by the web interface of of the ESP then everything just works fine. I enabled the debug logging for all the MQTT things, but I don’t see any ESP milight in the openhab.log
Do I need to add an additional logging to see the communication between openhab and Mosquitto? I do see the commands sent to other MQTT items.

my current log settings:

Logger level=DEBUG name=org.openhab.binding.mqtt.espmilighthub/
Logger level=DEBUG name=org.openhab.binding.mqtt/
Logger level=DEBUG name=org.openhab.core.io.transport.mqtt/
Logger level=DEBUG name=org.openhab.binding.mqtt.generic/

I probably did not add the raw data to the logs of the binding as it is very simple to get this. I’ll assume your using Linux and Mosquitto…

Type this into the linux command

mosquitto_sub -u usernamehere -P passwordhere -p 1883 -v -t 'milight/#'

You will then see all traffic in both directions.

I am running both openhab and mosquitto on a windows machine running as a service. I just enabled the Mosquitto logging in the mosquitto.conf file, but it looks like there is no way to capture the topics.
I found a solution to use “mosquitto_sub” to write to a log file.

mosquitto_sub.exe -v -t milight/# -F “%I %t %p” >c:\openhab\userdata\logs\milight.log

Heya, just updated OH3 from OH2 trying to get installed with the latest release: https :// Releases · Skinah/EspMilightHub · GitHub

but getting an error:
10:59:36.143 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.espmilighthub-3.0.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.espmilighthub [258]
Unresolved requirement: Import-Package: org.apache.commons.io; version=“[2.2.0,3.0.0)”

at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]

guessing it has something to do with latest OH3.x update. would love to get this working++