I’ve been running this setup for a few weeks now. Some lights missed a command now and then. This was resolved by changing the power level from “Max” to “Low” or “Min”, depending on the hub.
Thanks for the feedback as it is good to know the new feature is working. With needing to drop transmit power Down, I suspect it is power related and you will gain more reliable transmissions if you make some changes in the areas of this post. Soldering on a capacitor helps them out a lot. Loads of info out there on the web. Or just leave the transmission power down low and use more rf repeats as a work around.
1 Like
Can this plugin be used along with MQTTv2 from OpenHab 2.4?
Yes, that’s my setup and it works fine.
Thank you @rastus_rob. What did the trick for me was to empty the cache.
sudo rm -rf /var/lib/openhab2/cache/* && sudo rm -rf /var/lib/openhab2/tmp/*
1 Like
Hey guys,
Did y’all do anything else besides clear cache to get MQTT2 broker back running? It appears that since I have the Paho library in the add-ons folder for espMilight, that the MQTT2 broker is also trying to use that and throwing an error.
Hoping at this point that I have not completely jacked up my MQTT2 config trying to fix this.
Any thoughts @matt1 ?
More details of my issue here: MQTT Broker - Set HTTPS Hostname Verification Enabled Error
Edit - Is there any way to specifically tell MQTT2 to not use Paho?
Paho is the best mqtt library out there and my guess we are using two different versions of Paho that cause issues. Will look into it but it is worth deleting the Paho jar from addons and clean tmp and cache and reboot. The version installed with the mqtt2 should work with this binding.
Appreciate the quick reply, @matt1!
You were right. Deleted the 1.2.0 Paho from Add-Ons, cleaned cached, rebooted and I once again have both MQTT2 and espMilight.
Ran bundle:list from the console after the remove and reboot, looks like I have Paho 1.2.1
Without your 1.2.0 Paho, did see this error:
==> /var/log/openhab2/openhab.log <==
2019-07-22 16:25:24.636 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.espmilighthub (206): Starting destruction process
2019-07-22 16:25:24.637 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.espmilighthub (206): Not an extended bundle or destruction of extension already finished
2019-07-22 16:25:24.662 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.espmilighthub-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.espmilighthub [206]
Unresolved requirement: Import-Package: org.eclipse.paho.client.mqttv3; version="[1.2.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Edit - Did find this earlier today, seems like it could be applicable: https://github.com/openhab/openhab-core/pull/929
Edit 2 - And this is the bump from 1.2.0 to 1.2.1 in the core compile pom: https://github.com/openhab/openhab-core/commit/d55d59d3b5e0e7ca0ea1efd95bd61e809c8cfb78
Thanks for the heads up on the changes in the GitHub links and that they moved to a newer version of paho in the snapshots. This makes me happier this binding is not tied to the turmoil and is stand alone if they move to HiveMQ away from Paho. Just ignore the warning for now and it should be just fine as Paho does not change hugely and limits breaking changes between versions. Since most people are not using snapshots I wont be changing it until needed. Homekit binding also uses Paho.
No problem. There was quite a bit of talk about Hive being better than Paho from David, but that sounds like it would require a good bit of refactoring on your end if you decided to follow suit. Can’t say I blame you for not 
Good news is that if they do officially switch to Hive, then people on snapshots will not run into the issue I had with Paho 1.2.0 in the Add-Ons folder since Paho will not be used by MQTT binding.
Edit - Forgot to add that despite that error, EspMilightHub has been working well since yesterday without Paho 1.2.0.
Hey, having some issues with updates in Habpanel, since I had to re-install some things, and didn’t have a backup of my ESP8266/milight hub settings (oops lesson learned)
Everything is working fine, except I am having difficulty getting the buttons to update in my sitemap/habpanel.
When I make changes in the milight hub GUI status changes are updated on my sitemap, but for some reason the remotes are not updating the status on the sitemap. Not getting proper status updates on the sitemap. Just want to make sure my settings look ok.
MQTT topic pattern milight/commands/:device_id/:device_type/:group_id
MQTT update topic pattern milight/updates/:device_id/:device_type/:group_id
MQTT state topic pattern milight/states/:device_id/:device_type/:group_id
State, level,hue,saturation,color_temp, bulb_mode are checked.
Looking at mosquitto when using remote: (on then off)
milight/update/0x14BA/rgbw/0 {“state”:“ON”}
milight/states/0x14BA/rgbw/0 {“state”:“ON”,“level”:4,“hue”:144,“bulb_mode”:“color”}
milight/update/0x14BA/rgbw/0 {“state”:“OFF”}
milight/states/0x14BA/rgbw/0 {“state”:“OFF”,“level”:4,“hue”:144,“bulb_mode”:“color”}
mosquitto when using web GUI on ESP8266 (on then off)
milight/update/0x14BA/rgbw/1 {“state”:“ON”}
milight/states/0x14BA/rgbw/1 {“state”:“ON”,“level”:100,“hue”:144,“bulb_mode”:“color”}
milight/update/0x14BA/rgbw/1 {“state”:“OFF”}
milight/states/0x14BA/rgbw/1 {“state”:“OFF”,“level”:100,“hue”:144,“bulb_mode”:“color”}
So mosquitto is getting updates from both the GUI controls and the remote, there are some slight differences.
This is using an RGBW buld with remote.
I will note that I’m also using a RGB_CCT bulb with remote, oddly enough the tempurature slider seems to update on the sitemap when using the remote.
It’s probably something small and simple to fix, but i’m scratching me head a bit on this one. missing something…
thanks much++
currently using 1.9.2 of milight hub software.
Actually, I realized the issue was the group. as I have the switch on my sitemap/habpanel as group 1 on and off. I was using the group 0 (the main switch) on the remote.
milight/update/0x14BA/rgbw/0 all on or off.
milight/update/0x14BA/rgbw/1 group 1 on or off.
duh.
but this brings up a question, as technically If I’m hitting the all on or off button. on the remote technically this turns on or off all lights in group 1-4. Since group 0 is turning all on or off, should not all individual group switches in sitemap/habpanel also reflect the status of the lights, regardless of whether I’m using the main (group 0) button on the remote or individual groups?
All globe type used to ignore the group 0 until I added the feature recently. It is possible I only added it for rgb-cct globes as I don’t have any rgbw globes and I never use the remotes myself so it is possible there is an issue that needs looking at… Since you have both can you test using group 0 for rgb-cct to see if that works and if this is only with rgbw globes and I’ll take a look in the source code.
BTW the binding only listens to
milight/states/
it will not react to
milight/update
thanks matt.
yeah, the new 2.5 version works on both RGBW and RGB_CCT group zero does apply it’s state to individual groups.
I do have an issue with the 2.5 binding though, for some reason it keeps disconnecting and connecting to the MQTT broker.
16:27:03.626 [INFO ] [ub.handler.EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.
16:27:03.658 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException
16:27:03.668 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException to ONLINE
16:27:03.693 [ERROR] [ub.handler.EspMilightHubBridgeHandler] - MQTT connection has been lost, cause reported is:{}
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:181) [249:org.eclipse.paho.client.mqttv3:1.2.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:133) ~[?:?]
… 7 more
16:27:03.695 [INFO ] [ub.handler.EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.
16:27:03.723 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException
16:27:03.729 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException to ONLINE
16:27:04.665 [ERROR] [ub.handler.EspMilightHubBridgeHandler] - MQTT connection has been lost, cause reported is:{}
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:181) [249:org.eclipse.paho.client.mqttv3:1.2.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:133) ~[?:?]
… 7 more
16:27:04.667 [INFO ] [ub.handler.EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.
16:27:04.690 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException
16:27:04.702 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘espmilighthub:esp8266Bridge:Auto001’ changed from OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException to ONLINE
16:27:04.722 [ERROR] [ub.handler.EspMilightHubBridgeHandler] - MQTT connection has been lost, cause reported is:{}
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:181) [249:org.eclipse.paho.client.mqttv3:1.2.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ~[?:?]
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:133) ~[?:?]
… 7 more
This happens every second. on off on off. It starts off about every minute then gets faster. till the log is just a steady stream of disconnect/connect.
I will note that in 2.4 it disconnects and reconnects about every 5 minutes or so, and does not seem to have much of an effect on usability.
I’m trying to sort through the above posts to get a grasp on the changes, but it’s a bit unclear to me.
As per my setup, I’m on 2.4 openhab, not using the MQTT binding, but using mosquitto installed on the rasberry pi for MQTT.
Just wanting to be clear on what you suggest, I currently have the org.eclipse.paho.client.mqttv3-1.2.0.jar in the addons folder, but I’m assuming I may not need it there.
remove it and clear cache, and perhaps that’s the issue…havnt tried it yet…
as I reverted back to 2.4 for now (issue goes away)
My guess is your issue is caused by not clearing the cache and temp folders which is required anytime you add change or remove something from the addons folder. With the 2.5 version you need the Paho lib in the addons folder unless you have a binding installed that has it included. The embedded mqtt binding will supply it for example.
Yes the group 0 feature may only be in the 2.5 version I forget when exactly it was added but that will be in the thread.
I never get disconnects and is very stable so never heard of it doing it before perhaps it is something with your network you need to look at. I have my mqtt broker on the same arm system as openhab.
Hi!
When loading openHAB2 in the log I see the following:
2019-08-15 10:20:30.546 [WARN ] [b.handler.EspMilightHubBridgeHandler] - Milight MQTT message came in as being a colour mode, but was missing a HUE value.
Did I configure something wrong?
Thanks!
Not enough info to comment. I would need some trace level log output to see what the incoming mqtt message is. If you use the latest version of the binding you can give the IP address and it will setup the hub for you.
Thank you, I will come back to this later and let you know!
Is it possible to add custom effects, besides the builtin (disco mode)?
For example. is it possible to create something like this with a FUT039 controller:
Or a little simpler, also for use with bulbs, flash 3 times in a color. I can do “Send red on/off/on/off/on/off” but that wont be a consistent flash since time and network delays affect the duration of every signal.
I do basic colour flashes and then back to colour it was on before the flashing occurred which is done with openhab rules.
Advanced stuff will tie up openhab threads for running rules so you are best to program the esp8266 to do the heavy lifting and trigger it from a mqtt command but you will need to learn how to program in C with programio and esp8266.
EDIT: If you are looking at doing multiple strips with advanced effects it would be better to create them in a micro like the video is showing. This is because it takes time to transmit data over the air and it will at some point be a bottleneck. There is a lot of info out there for individual addressable strip leds if you look up the Ambilight projects.
1 Like