EspMilightHub new binding for milight limitlessLED and easybulb

matt1 · November 19, 2019, 1:02pm

Do you have a link to where the new feature is explained? Have not visited the project in a while.

Brignoud · November 19, 2019, 1:15pm

Here it is

Transitions

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:

RESTful `/transitions` routes

These routes are fully documented in the REST API documentation.

`transition` field when issuing commands

When 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.

Notes on transitions

espMH’s transitions should work seamlessly with HomeAssistant’s transition functionality.
You can issue commands specifying transitions between many fields at once. For example:

{“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.

Color transitions are supported. Under the hood, this is treated as a transition between current values for r, g, and b to the r, g, b values for the specified color. Because milight uses hue-sat colors, this might not behave exactly as you’d expect for all colors.
You can transition to a given 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.

matt1 · November 19, 2019, 11:27pm

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.

Enable disable control for transition
A fader that changes the translation time or a global transition time set via a config.

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?

Brignoud · November 21, 2019, 5:38pm

No, sorry, I haven’ made any test

Brignoud · November 21, 2019, 5:56pm

How do you get out of this?
Have you resolved?

stfn82 · November 21, 2019, 7:01pm

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.

Olymp · November 22, 2019, 4:56am

I had two problems:

binding did not start
warnings when sending commands.
What kind of problem are you asking? The first I decided by putting the Paho library in the add-ons folder, the second I could not solve, it seems that I am the only one who has a problem sending commands, they work correctly, but warnings appear in the log.

JMacIV · November 25, 2019, 4:45am

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):

Download Matt’s binding (link taken from his GitHub page): http://www.pcmus.com/openhab/EspMilightHubBinding/
Unzip .ZIP.
Copy org.eclipse.paho.client.mqttv3-1.2.0.jar to openhab2-addons folder. Full path on an automated Debian install should be /usr/share/openhab2/addons.
Check Paper UI -> Configuration -> Things. Your EspMilightHub Bridge Thing should now be initialized and all Milight Things should show as Online.
Profit.

JMacIV · November 25, 2019, 4:54am

On your second problem, it sounds like you may need to double check your settings on the EspMilightHub itself. It sounds like you may be trying to post commands to the state channel based off of that warning.

Check your EspMilightHub device directly (not in OH, but by connecting to Web UI of ESP device). Go to Settings, then MQTT. Check the settings below.

MQTT Topic Pattern. Should = milight/commands/:device_id/:device_type/:group_id
MQTT State Topic Pattern. Should = milight/states/:device_id/:device_type/:group_id

Also, double check your Group State Fields. Should have the following checked: State, Level, Hue, Saturation, Mode, Color_temp, Bulb_mode.

Edited for clarity.

matt1 · November 25, 2019, 11:24pm

This is easily fixed for level as I added a feature I called it ‘min dim if power fails’ or similar which places the light in 1% right before turning the light off. This way it will start at 1% and dim up to what you asked for each time. Also if the power fails in the middle of the night they come back on at 1% instead of 100% or the last value.

I believe the firmware will not allow level changes with the lights off the same is probably true of colour temps.

Some of what you are wanting you need to first test what happen with raw MQTT messages and determin if it is the firmware/hardware doing it and then ask at the projects GitHub page to get it supported at a hardware level. I am not keen to add fixes unless I use them or you do the coding.

As for your crashes, no idea here as I am still using 2.4 stable, I plan to over Christmas do some changes and testing.

stfn82 · November 30, 2019, 3:57pm

After some trail and error it seems that POWERFAILS_TO_MINDIM=“true” is the correct syntax for in my thing file:

Bridge espmilighthub:esp8266Bridge:milighthub_zolder [
    ADDR="tcp://localhost:1883",
    MQTT_USERNAME="milighthub_zolder",
    MQTT_PASSWORD="MiLight1234",
    FAVOURITE_WHITE="200",
    DELAY_BETWEEN_MQTT="140",
    DELAY_BETWEEN_SAME_GLOBE="250",
    DEFAULT_COMMAND="set_white",
    HUB_IP="10.0.2.229",
    POWERFAILS_TO_MINDIM="true"
]

{
        Thing rgb_cct 0x11 "TrapgatBovenlamp" @ "Zolder"
        Thing rgb_cct 0x12 "Overlooplamp" @ "Overloop"

        Thing cct 0x51 "Werkkamerlamp" @ "Werkkamer"
        Thing cct 0x52 "Badkamerlamp" @ "Badkamer"
        Thing cct 0x53 "Bieblamp" @ "Bieb"
        Thing cct 0x54 "Waskamerlamp" @ "Zolder"
}

But now my lights will no longer switch off:

==> /var/log/openhab2/openhab.log <==
2019-11-30 16:28:06.484 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.espmilighthub.handler.EspMilightHubHandler@1f3714': java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
        at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.getPowerFailsToMaxDim(EspMilightHubBridgeHandler.java:549) ~[?:?]
        at org.openhab.binding.espmilighthub.handler.EspMilightHubHandler.handleCommand(EspMilightHubHandler.java:100) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy887.handleCommand(Unknown Source) [?:?]
        at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
        at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?: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]
2019-11-30 16:28:06.511 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.espmilighthub.handler.EspMilightHubHandler@16f527b': java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
        at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.getPowerFailsToMaxDim(EspMilightHubBridgeHandler.java:549) ~[?:?]
        at org.openhab.binding.espmilighthub.handler.EspMilightHubHandler.handleCommand(EspMilightHubHandler.java:100) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy889.handleCommand(Unknown Source) [?:?]
        at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
        at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?: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]

==> /var/log/openhab2/events.log <==
2019-11-30 16:28:06.393 [ome.event.ItemCommandEvent] - Item 'gKeukenLightsLevel' received command OFF
2019-11-30 16:28:06.443 [ome.event.ItemCommandEvent] - Item 'Milight_ID0x2_G1_Level' received command OFF
2019-11-30 16:28:06.474 [ome.event.ItemCommandEvent] - Item 'Milight_ID0x2_G2_Level' received command OFF
2019-11-30 16:28:06.477 [nt.ItemStatePredictedEvent] - Milight_ID0x2_G1_Level predicted to become OFF
2019-11-30 16:28:06.491 [nt.ItemStatePredictedEvent] - Milight_ID0x2_G2_Level predicted to become OFF
2019-11-30 16:28:06.548 [vent.ItemStateChangedEvent] - Milight_ID0x2_G1_Level changed from 90 to 0
2019-11-30 16:28:06.551 [GroupItemStateChangedEvent] - gKeukenLightsLevel changed from 0 to 90.00000000 through Milight_ID0x2_G1_Level
2019-11-30 16:28:06.554 [vent.ItemStateChangedEvent] - Milight_ID0x2_G2_Level changed from 90 to 0
2019-11-30 16:28:06.559 [GroupItemStateChangedEvent] - gKeukenLightsLevel changed from 90.00000000 to 0.00000000 through Milight_ID0x2_G2_Level

openHAB says they are off, but the lights are still on. Switching off through the hub itself works flawless.

When I remove POWERFAILS_TO_MINDIM="true" I can turn off my lights again.

stfn82 · December 5, 2019, 3:04pm

Also, I noticed:

[b.handler.EspMilightHubBridgeHandler] - Can not reach the espMilightHub directly, check you have entered the correct HUB_IP in the Things setup

The supplied IP address is pingable and can be opened in the browser (MiLightHub control panel). How is the binding trying to reach the HUB_IP?

JMacIV · December 5, 2019, 6:18pm

Try removing the quotes on “true” for the mindim param. That error is saying that it cannot parse a string to a boolean. Removing the quotes should turn true from a string into boolean.

On the HUB_IP param, try adding tcp:// in front of the IP, inside the quotes. Not sure if that will work or not.

Also, I do not think you need quotes around the values on Fav white or the two delay params as those should probably treated as numbers, not strings.

Full disclosure - I did not use text config to set up this binding, just making guesses based on what I know about programming.

stfn82 · December 5, 2019, 8:00pm

This seems to work, I no longer get the error. And my lights turn OFF.

Good idea, unfortunately it doesn’t work:

2019-12-05 20:15:39.015 [WARN ] [b.handler.EspMilightHubBridgeHandler] - An error occured when trying to talk to your EspMilightHub directly, check the HUB_IP is correct. The error was :{}
java.net.UnknownHostException: tcp
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184) ~[?:1.8.0_222]
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_222]
        at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_222]
        at sun.net.NetworkClient.doConnect(NetworkClient.java:175) ~[?:1.8.0_222]
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:463) ~[?:1.8.0_222]
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:558) ~[?:1.8.0_222]
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:242) ~[?:1.8.0_222]
        at sun.net.www.http.HttpClient.New(HttpClient.java:339) ~[?:1.8.0_222]
        at sun.net.www.http.HttpClient.New(HttpClient.java:357) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1229) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1165) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1059) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:993) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1343) ~[?:1.8.0_222]
        at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1318) ~[?:1.8.0_222]
        at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.putHttp(EspMilightHubBridgeHandler.java:612) [bundleFile:?]
        at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.initialize(EspMilightHubBridgeHandler.java:633) [bundleFile:?]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:178) [bundleFile:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?: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]

I think only Matt knows the correct syntax.

I don’t notice other behaviour with the quotes removed, but I think you’re right with the numbers vs. strings.

When I look at the docs they give this as an example:

Thing network:device:webcam "Webcam" @ "Living Room" [ hostname="192.168.0.2", timeout="5000", ... ]
Thing astro:moon:home [ geolocation="50.12345,10.98765", interval=300 ]
Thing ntp:ntp:local [ hostname="de.pool.ntp.org" ]

Some numbers with quotes, other without

Full disclosure - I only know some limited shell scripting and openHAB’s rulesengine. And some hardcore HTML back in the days when we only had Notepad™

I tried looking at this addon’s source code but I don’t understand it enough to see how to define HUB_IP.

JMacIV · December 5, 2019, 8:37pm

Yeah, not sure what I was thinking with my “tcp://” suggestion… That is def wrong.

If you have the hub setup correctly following his instructions, then you should not need that HUB_IP. I have never added it my config via Paper and my lights work flawlessly

For whatever reason, I did not think to look at the code… That being said, things I have learned ( /think I have learned since I am not a dev):

On the delays and Fav White - I think they can be either strings or integers. He takes the value, converts it to a string, then parses to an integer. I would assume he does this, so you can use either strings or integers in the config and it will still work.

On the HUB_IP - He takes your value and adds “http://” in front, hence why OH threw an error when you added “tcp://” (I am still dumb for suggesting that ha). Then he appends the file path to the end.

That being said, try going to “http://10.0.2.229/settings” in a browser. Does that load?

That is the IP you provided in your config file and a file path from his code. If that opens in a browser, then I am at a loss and will defer to Matt! “/settings” shows up as just a JSON object when it loads for me.

If the IP of your hub is dynamically assigned via DHCP, then I could easily see how that would not work since the IP could be changing upon reboot of ESP or Router.

Glad we at least made some progress!

matt1 · December 7, 2019, 1:06am

No they must be integers to match the channel type, the conversion is to make a MQTT message.

@Olymp I made an edit after you posted…

From memory it will be a string of the IP “192.168.1.55” and if it is password protected it will not work. It is a security flaw in the firmwares settings as your password can be seen with that url. It is possible in newer firmwares a change was made. As mentioned check http://hubIP/settings” to see if it works without a password and also if your password is able to be seen.

Here’s an example…

Bridge espmilighthub:esp8266Bridge:001 [ADDR="tcp://localhost:1883", MQTT_USERNAME="user", MQTT_PASSWORD="12345678", 1TRIGGERS_NIGHT_MODE=true, DELAY_BETWEEN_MQTT=40, POWERFAILS_TO_MINDIM=true, AUTOCTEMP_MAXDIMMED_TEMPERATURE=350, FAVOURITE_WHITE=200]
{
Thing rgb_cct 0xAB12 "First Linen Hall"//driveway end
}

Olymp · December 7, 2019, 1:36am

Bridge espmilighthub:esp8266Bridge:001 "hub" @ "milight" [ADDR="tcp://192.168.215.2:1974", MQTT_USERNAME="MQTT-login", MQTT_PASSWORD="MQTT-passw"]
{
        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"
}

log:

2019-12-07 09:27:11.255 [INFO ] [b.handler.EspMilightHubBridgeHandler] - No HUB_IP has been provided, binding can not auto setup the Hub for you.

Where and how should I configure HUB_IP?

matt1 · December 8, 2019, 3:43am

A new build 2019-12-08 has been uploaded which has only a single change to use the newer Paho 1.2.2 library due to a security flaw having been found in the older library. Delete any older version of the lib from your addons folder and unzip the two files there. Don’t forget to clean your cache and tmp folders and reboot your Openhab to ensure only the newer files are used.

I updated my firmware in the esp8266 to 1.10.5 and it appears to be working fine so far, any issues let me know…

TRANSITIONS: @Brignoud
I looked at this new feature of the hub to see if there was an easy way to implement this that made sense. The only way that made sense was to specify a different time per globe using a slider with 0 being the default value set in the firmwares settings (500ms normally) and when >0 it will then be the time in seconds for the transition. This way in rules you could do something like…

Milight_Transistion.sendCommand(30)
Milight_Hue.sendCommand("100,100,100")
Milight_Transistion.sendCommand(0)

This would make the globe change over 30 seconds to the new colour and then go back to doing the default 500ms transitions. It is probably not easy to make this change so unless people would use it I wont make the change. Thoughts?

stfn82 · December 8, 2019, 12:54pm

Yes that works. I don’t have a login + password configured for my hub.

{"admin_username":"","admin_password":"","ce_pin":4,"csn_pin":15,"reset_pin":0,"led_pin":-2,"radio_interface_type":"nRF24","packet_repeats":160,"http_repeat_factor":1,"auto_restart_period":0,"mqtt_server":"10.0.0.153:1883","mqtt_username":"milighthub_zolder","mqtt_password":"MiLight1234","mqtt_topic_pattern":"milight/commands/:device_id/:device_type/:group_id","mqtt_update_topic_pattern":"","mqtt_state_topic_pattern":"milight/states/:device_id/:device_type/:group_id","mqtt_client_status_topic":"","simple_mqtt_client_status":false,"discovery_port":48899,"listen_repeats":3,"state_flush_interval":10000,"mqtt_state_rate_limit":600,"packet_repeat_throttle_sensitivity":0,"packet_repeat_throttle_threshold":200,"packet_repeat_minimum":3,"enable_automatic_mode_switching":true,"led_mode_wifi_config":"Fast toggle","led_mode_wifi_failed":"Fast blip","led_mode_operating":"Slow blip","led_mode_packet":"Flicker","led_mode_packet_count":3,"hostname":"milight-hub-zolder","rf24_power_level":"MAX","rf24_listen_channel":"HIGH","wifi_static_ip":"10.0.2.229","wifi_static_ip_gateway":"10.0.0.2","wifi_static_ip_netmask":"255.255.0.0","packet_repeats_per_loop":10,"home_assistant_discovery_prefix":"","wifi_mode":"n","default_transition_period":500,"rf24_channels":["HIGH"],"device_ids":[1,2,3,4,5],"gateway_configs":[],"group_state_fields":["state","level","hue","saturation","mode","color_temp","bulb_mode"],"group_id_aliases":{}}

Since I’m using POWERFAILS_TO_MINDIM=true I’ve found another issue. I have some non-MiLights turn ON or OFFwith these rules:

rule "Switch Lights Trapgat Beneden OFF"
when
    Item gHalLightsLevel changed to OFF or
    Item gHalLightsLevel changed to 0
then
    //logInfo("tasmota.rules", "Tasmota Turning lights OFF")
    gTrapgatBenedenLights.sendCommand(OFF)
end

rule "Switch Lights Trapgat Beneden ON"
when
    Item gHalLightsLevel changed from OFF to ON or
    Item gHalLightsLevel changed to 90 // or
    //Item gOverloopLightsLevel changed from OFF to ON or
    //Item gOverloopLightsLevel changed to 90
then
    //logInfo("tasmota.rules", "Tasmota Turning lights ON")
    gTrapgatBenedenLights.sendCommand(ON)
end

Somehow the lights first receive the command ON at level 73. Then they receive the command ON at level 0, and then again ON at level 73:

Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/commands/0x2/rgb_cct/3', ... (25 bytes))
milight/commands/0x2/rgb_cct/3 {"state":"ON","level":73}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (61 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":0,"color_temp":296,"bulb_mode":"white"}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (61 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":0,"color_temp":296,"bulb_mode":"white"}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (61 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":0,"color_temp":296,"bulb_mode":"white"}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (62 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":73,"color_temp":296,"bulb_mode":"white"}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (62 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":73,"color_temp":296,"bulb_mode":"white"}
Client mosqsub/9236-openhab received PUBLISH (d0, q0, r0, m0, 'milight/states/0x2/rgb_cct/3', ... (62 bytes))
milight/states/0x2/rgb_cct/3 {"state":"ON","level":73,"color_temp":296,"bulb_mode":"white"}

NB the states are updated 3 times each because I have 3 hubs in my house. 1 on every floor.

Corresponding openhab.log:

2019-12-08 11:39:24.963 [ome.event.ItemCommandEvent] - Item 'Milight_ID0x2_G3_Level' received command 73
2019-12-08 11:39:24.987 [nt.ItemStatePredictedEvent] - Milight_ID0x2_G3_Level predicted to become 73
2019-12-08 11:39:25.018 [GroupItemStateChangedEvent] - gHalLightsLevel changed from 0.00000000 to 73.00000000 through Milight_ID0x2_G3_Level
2019-12-08 11:39:25.020 [vent.ItemStateChangedEvent] - Milight_ID0x2_G3_Level changed from 0 to 73
2019-12-08 11:39:25.222 [GroupItemStateChangedEvent] - gHalLightsLevel changed from 73.00000000 to 0.00000000 through Milight_ID0x2_G3_Level
2019-12-08 11:39:25.227 [vent.ItemStateChangedEvent] - Milight_ID0x2_G3_Level changed from 73 to 0
2019-12-08 11:39:25.822 [vent.ItemStateChangedEvent] - Milight_ID0x2_G3_Level changed from 0 to 73
2019-12-08 11:39:25.832 [vent.ItemStateChangedEvent] - Milight_ID0x2_G3_State changed from OFF to ON
2019-12-08 11:39:25.837 [GroupItemStateChangedEvent] - gHalLightsLevel changed from 0.00000000 to 73.00000000 through Milight_ID0x2_G3_Level
2019-12-08 11:39:25.843 [GroupItemStateChangedEvent] - gHalLights changed from OFF to ON through Milight_ID0x2_G3_State
2019-12-08 11:39:25.845 [GroupItemStateChangedEvent] - gBeganeGrondLights changed from OFF to ON through gHalLights

It happens too fast to see the MiLights flash, but the other lights do turn ON, OFF, ON. This doesn’t happen when POWERFAILS_TO_MINDIM=false.

Is this a bug?

Brignoud · December 8, 2019, 3:16pm

You’re so kind to reply me
I have no more request about and I’l let you judge if it worth or not an adaptation since you’re the master
Thanks for the hint

EspMilightHub new binding for milight limitlessLED and easybulb

Transitions

RESTful /transitions routes

transition field when issuing commands

Notes on transitions

RESTful `/transitions` routes

`transition` field when issuing commands