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.
2019-08-26 12:14:56.862 [INFO ] [b.handler.EspMilightHubBridgeHandler] - No HUB_IP has been provided, binding can not auto setup the Hub for you.
2019-08-26 12:14:57.264 [INFO ] [b.handler.EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.
2019-08-26 12:15:07.262 [INFO ] [b.handler.EspMilightHubBridgeHandler] - Sucessfully subscribed to milight/states/#
2019-08-26 12:15:07.278 [WARN ] [b.handler.EspMilightHubBridgeHandler] - Milight MQTT message came in as being a colour mode, but was missing a HUE value.
2019-08-26 12:15:07.284 [WARN ] [b.handler.EspMilightHubBridgeHandler] - Milight MQTT message came in as being a colour mode, but was missing a HUE value.
2019-08-26 12:15:07.291 [WARN ] [b.handler.EspMilightHubBridgeHandler] - Milight MQTT message came in as being a colour mode, but was missing a HUE value.
2019-08-26 12:15:07.292 [WARN ] [b.handler.EspMilightHubBridgeHandler] - Milight MQTT message came in as being a colour mode, but was missing a HUE value.
Bridge espmilighthub:esp8266Bridge:001 "hub" @ "milight" [ADDR="tcp://192.168.215.2:1983", MQTT_USERNAME="MQTT-logIn", MQTT_PASSWORD="MQTT-password"]
{
Thing rgbw 0x20110 "milight" @ "milight"
Thing rgbw 0x20111 "milight 1" @ "milight"
Thing rgbw 0x20112 "milight 2" @ "milight"
Thing rgbw 0x20113 "milight 3" @ "milight"
Thing rgbw 0x20114 "milight 4" @ "milight"
}
Switch milight_id2011_G0_state "On/Off" {channel="espmilighthub:rgbw:001:0x20110:level"}
Dimmer milight_id2011_G0_level "level" {channel="espmilighthub:rgbw:001:0x20110:level"}
Color milight_id2011_G0_hue "color" {channel="espmilighthub:rgbw:001:0x20110:colour"}
Number milight_id2011_G0_dmode "discomode" {channel="espmilighthub:rgbw:001:0x20110:discomode"}
String milight_id2011_G0_mode "mode [%s]" {channel="espmilighthub:rgbw:001:0x20110:bulbmode"}
String milight_id2011_G0_cmd "Command to Send" {channel="espmilighthub:rgbw:001:0x20110:bulbcommand"}
Switch milight_id2011_G0_send_cmd "Send Command" {channel="espmilighthub:rgbw:001:0x20110:sendbulbcommand"}
how to do it?
I tried through the paperUI, in the log I see the following:
2019-08-26 12:37:50.923 [INFO ] [st.core.internal.thing.ThingResource] - Received HTTP PUT request for update configuration at 'things/espmilighthub:esp8266Bridge:001/config' for an unmanaged thing 'espmilighthub:esp8266Bridge:001'.
on github I did not find information on how to do this
Thanks!
I turned on the trace, where there was data on non-existent bulbs that were once tested. I deleted (
mosquitto_pub -u username -P password -p 1883 -t ‘milight/states/0x0/rgb_cct/1’ -n -r
) information about them and warnings in the log stopped. Thank!
How to do this using files xxxx.things?
@matt1 with OH M2 (and probably M3) there is a problem with paho version conflict (M2 use 1.2.1 and espmilightub 1.2.0). With these 2 versions active, MQTT binding doesn’t work (it can’t connect to broker). With only 1.2.1, espmilighthub binding doesn’t work.
Hey @furax54 - Try removing the Paho client from your Addons Folder. That worked for me on M2 and still works for me on M3.
You will see an error in logs from the binding, but it should still work.
Edit: See Matt and I’s discussion above. EspMilightHub new binding for milight limitlessLED and easybulb
Yes I need to update the paho version as I got messages stating the older version has a security flaw in it. As soon as I update my PC and do a full reinstall and then setup a IDE again I can then get back onto doing this but its not high on my to do list, possibly over the Christmas break I can get it done. As John wrote it should work if you just remove the paho lib if another binding has already installed a newer version. Since there is a known flaw in the lib it would be a good idea to update it.
WOW this seems to be a very interesting binding…
Does it work with Mi-Light FUT045 controllers? This is a RGB+CCT LED strip controller.
Thanks!
Visit the GitHub project for the controller and look at the list of supported remotes. Milight is a 1 way protocol so it only emulates the remotes and since it is opensource the project keeps growing and adding support.
Hi!
I update openHAB
with openHAB 2.5.0 Build #1736
on openHAB 2.5.0 Build #1759
When rebooting openHAB in the log, the following warning:
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.espmilighthub [204]
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) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
I added the paho library to the add-ons directory, there are no more warnings. It looks like the MQTT binding no longer uses this library. Have I done the right thing?
But now, with the on / off command, I get the following warnings:
2019-11-18 17:40:08.959 [WARN ] [qtt.generic.AbstractMQTTThingHandler] - Channel mqtt:topic:g_mqtt:hall_light_switch_things:state is a read-only channel, ignoring command ON
2019-11-18 17:40:12.948 [WARN ] [qtt.generic.AbstractMQTTThingHandler] - Channel mqtt:topic:g_mqtt:hall_light_switch_things:state is a read-only channel, ignoring command OFF
This doesn’t seem to be a binding problem, but I don’t know how to cure this. Maybe someone will tell?
Thanks!
Yes MQTT binding now using HiveMQ (see release notes for 2.5M5)
Hi, don’t know if I’m wrong with this
Are new features in Mullins project indipendent from the bind? Or could the transiction method be included in a future versione of you OH bind with a dedicated channel or function?
Thanks
Do you have a link to where the new feature is explained? Have not visited the project in a while.
Here it is
Transitions between two given states are supported. Depending on how transition commands are being issued, the duration and smoothness of the transition are both configurable. There are a few ways to use transitions:
/transitions routesThese routes are fully documented in the REST API documentation.
transition field when issuing commandsWhen you issue a command to a bulb either via REST or MQTT, you can include a transition field. The value of this field specifies the duration of the transition, in seconds (non-integer values are supported).
For example, the command:
{“brightness”:255,“transition”:60}
will transition from whatever the current brightness is to brightness=255 over 60 seconds.
{“brightness”:255,“kelvin”:0,“transition”:10.5}
will transition from current values for brightness and kelvin to the specified values – 255 and 0 respectively – over 10.5 seconds.
status or state . For example,{“status”:“ON”,“transition”:10}
will turn the bulb on, immediately set the brightness to 0, and then transition to brightness=255 over 10 seconds. If you specify a brightness value, the transition will stop there instead of 255.
That would need new features added to support at a binding level. You could do it right away by sending raw mqtt packets manually if you were wanting to transition between set scenes but if you wanted slow brightness swells that react to fader movements it would need two things added per globe.
Then any change could have the transition time auto added by the binding. Problems may arise if you drag a finger around the colour wheel as openhab sends some serious data that backs up in a FIFO queue when you do this and it would be interesting to see how the hub handles this flood of data with transition times added to every command.
Have you done any testing using manual mqtt messages?
No, sorry, I haven’ made any test
How do you get out of this?
Have you resolved?
Is the following possible: I’m using rlkoshak’s Design Pattern: Time Of Day for various stuff in the house. I want to add color temperature based on time of the day. What colder in the morning and through out the day getting warmer.
The problem is setting lights that are off to the new color temperature What happens now is: the light switches on in the color temperature it was previous and then changes to the new value. BTW this is also happening with the light level. If I switch a light on at 30% and previously it was 90%, it switches on at 90% and fades to 30%. Not very pleasant in the night!
I tried to manually send mqtt commands mosquitto_pub -h localhost -u XXX -P XXX -t 'milight/commands/0x4/rgb_cct/2' -m "{\"state\":\"OFF\",\"level\":100,\"color_temp\":153,\"bulb_mode\":\"white\"}" which results in:
Client mosqsub/27628-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x4/rgb_cct/2', ... (64 bytes))
milight/states/0x4/rgb_cct/2 {"state":"OFF","level":100,"color_temp":370,"bulb_mode":"white"}
Where 370 is the previous value of color_temp.
And it seems these commands are also crashing my openHAB. My log is full with this and nothing is working anymore. Java cpu load is 300%+ on a Raspberry Pi 3 Model B Plus Rev 1.3 with openHAB 2.5.0~M5 en the MQTT2 binding.
2019-11-21 19:49:49.032 [ERROR] [o.client.mqttv3.internal.ClientState] - espMilightHub:46a03e89: Timed out as no write activity, keepAlive=15,000 lastOutboundActivity=1,574,362,156,205 lastInboundActivity=1,574,362,161,660 time=1,574,362,189,030 lastPing=0
2019-11-21 19:50:27.614 [ERROR] [b.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) [org.eclipse.paho.client.mqttv3-1.2.0.jar:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_222]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[?:1.8.0_222]
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
2019-11-21 19:49:49.029 [ERROR] [o.client.mqttv3.internal.ClientState] - espMilightHub:46a03e89: Timed out as no write activity, keepAlive=15,000 lastOutboundActivity=1,574,362,145,243 lastInboundActivity=1,574,362,145,258 time=1,574,362,189,025 lastPing=0
2019-11-21 19:49:49.024 [INFO ] [b.handler.EspMilightHubBridgeHandler] - Sucessfully connected to the MQTT broker.I had two problems:
Note for people upgrading from M4 to M5
As @furax54 mentioned above, as of 2.5 M5, Paho JAR is no longer included in OH, so it is again required to be added into the Addons folder for espMilightHub binding to work properly.
People like me who had deleted Paho JAR from Add-Ons with M4, will need to add it back to the Add-Ons folder. Steps (assuming you already have binding running):