EspMilightHub new binding for milight limitlessLED and easybulb

[JMacIV (John McMillan)]

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 (Skinah)]

@stfn82

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!

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 (Stefan)]

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 (Stefan)]

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 (John McMillan)]

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 (Stefan)]

@JMacIV

Try removing the quotes on “true”

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

@JMacIV

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

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.

@JMacIV

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.

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

@JMacIV

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

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 (John McMillan)]

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 (Skinah)]

@JMacIV

On the delays and Fav White - I think they can be either strings or integers.

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

@JMacIV

On the HUB_IP

@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 (Sergey M)]

@matt1

Heres an example…

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 (Skinah)]

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 (Stefan)]

@JMacIV

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

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 (Elenio)]

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

[Hypernova (Hans)]

Helo, When I slide the dimmer to 0 the On/Off switch doesn’t update. Or when I switch the light on, the dimmer slider doesn’t update eather.
The individual controls are working perfectly (On/Off, Dimmer, Color Temperature, Color Picker). There is just no feedback to the other controls.

Is this normal behaviour or did I do something wrong?

[matt1 (Skinah)]

@Hypernova

When I slide the dimmer to 0 the On/Off switch doesn’t update.

This works for me in Openhab 2.5 Stable and with rgb_cct globes. It is possible it is happening with another globe type so more info on how to reproduce is needed.

1. What globes?
2. Is it only happening to group 0 controls?
3. Does leaving the page of the sitemap and returning make the control show correct? I have seen this happen and it is not the binding in my opinion.
4. Is it only when you use COLOURS or only in white mode that it happens? any other pattern that may suggest how to reproduce it?

[Hypernova (Hans)]

Hi Matt,
Thanks for you quick reply. I tried with OpenHAB 2.4 and 2.5, in both versions i get the same result.

1. I’m also using rgb_cct globes
2. I’m not using group 0, but group 1 & 2
3. Leaving the page and coming back doesn’t change anything on the view of the controls
4. It happens all the time, no matter what mode the lamp are in.

Things config:

Bridge espmilighthub:esp8266Bridge:002 [ADDR="tcp://192.168.150.10:1883", 1TRIGGERS_NIGHT_MODE=true, DELAY_BETWEEN_MQTT=40, POWERFAILS_TO_MINDIM=true, AUTOCTEMP_MAXDIMMED_TEMPERATURE=350, FAVOURITE_WHITE=200, HUB_IP="192.168.150.22"]
{
        Thing   rgb_cct 0x00011 "Relax Room Front"   
        Thing   rgb_cct 0x00012 "Relax Room Back"       
}

I’m not using a password yet in the MQTT broker.

Items config:

// Light RelaxRoom Front 
Switch      Milight_ID0x00011_G1_State    "Aan/Uit [%s]"          (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00011:level"}
Dimmer      Milight_ID0x00011_G1_Level    "Dim [%.0f %%]"           (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00011:level"}
Dimmer      Milight_ID0x00011_G1_CTemp    "Color Temperature"     (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00011:colourtemperature"}
Color       Milight_ID0x00011_G1_Hue      "Relax room front"     (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00011:colour"}

// Light RelaxRoom Back 
Switch      Milight_ID0x00012_G1_State    "Aan/Uit [%s]"          (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00012:level"}
Dimmer      Milight_ID0x00012_G1_Level    "Dim [%.0f %%]"           (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00012:level"}
Dimmer      Milight_ID0x00012_G1_CTemp    "Color Temperature"     (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00012:colourtemperature"}
Color       Milight_ID0x00012_G1_Hue      "Relax room back"     (gRelaxRoom,gLightFirstFloor)      {channel="espmilighthub:rgb_cct:002:0x00012:colour"}

I also triple checked MQTT topic and state topic pattern and the Group state fields. All of these settings are correct.

Thanks for helping me out.

[matt1 (Skinah)]

@Hypernova

1TRIGGERS_NIGHT_MODE=true

What happens if you make this false?

theory is if you are sliding your finger on the controls it may be sending a value of 1 which turns on the night mode.

Can you provide a trace of this showing what the MQTT messages are doing when the fault occurs?

[matt1 (Skinah)]

New build 2019-12-28 has these changes:

• New ability to link dimmer and color channels so they always show the same brightness. Thanks to Jaffa for the PR and testing done. This is an option that can be turned on and off.
  https://github.com/Skinah/EspMilightHub/pull/1
• If you use Group 0 controls instead of Openhab Groups, they now update when a remote it moved.
  thanks for Xento PR and testing.
  https://github.com/Skinah/EspMilightHub/pull/8
• If you change globes to WHITE, the colour item will change to white. Please report if this causes any issues as sadly the milighthub’s firmware sees a HSB of 0,0,x as red and not white.
• Google Home seemed to change its HSB for when you ask for the colour white a month or so back so this was changed so the real white LEDs are used when you ask for white.
• Bug fix that meant a non round number was used in MQTT messages.

[thowa]

@matt1 First I want to thank you for your great work !!!

I’m having a problem with controlling the LEDs and I assume it is related to the EspMilightHub.
When the LEDs are already off and I send the command to switch them once more off, the LEDs will light up shortly.

Actually I just want to send another “OFF” to ensure that all LEDs in the Group are really off. But this command will switch on all (or some) LEDs in the Group. Finally it switches the LEDs of, but sometimes one LED stays on.

The previous state is OFF:

2020-01-02 23:49:19.691 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Processing new incoming MQTT message to update Openhab’s controls.
2020-01-02 23:49:19.691 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Message ={“state”:“OFF”,“level”:0,“hue”:49,“saturation”:69,“bulb_mode”:“color”}
2020-01-02 23:49:19.692 [TRACE] [b.handler.EspMilightHubBridgeHandler] - globeType =rgb_cct
2020-01-02 23:49:19.692 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteCode =0x1001
2020-01-02 23:49:19.693 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteGroupID =1
2020-01-02 23:49:19.694 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Chan Prefix =espmilighthub:rgb_cct:001:0x10011:
2020-01-02 23:49:19.694 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbState =OFF
2020-01-02 23:49:19.695 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbLevel =0
2020-01-02 23:50:13.484 [INFO ] [ort.shared.ScriptedAutomationManager] - removeAll added handlers

Starting the script with switching OFF one more time

2020-01-02 23:50:13.487 [INFO ] [me.core.service.AbstractWatchService] - Loading script ‘python/personal/Beleuchtung_Aussen.py’
2020-01-02 23:50:14.567 [INFO ] [jsr223.jython.Beleuchtung_Aussen ] - Rule triggert!
2020-01-02 23:50:14.569 [INFO ] [jsr223.jython.Beleuchtung_Aussen ] - GartenUnten_Level: setting off
2020-01-02 23:50:14.585 [TRACE] [b.handler.EspMilightHubBridgeHandler] - MQTT message just sent, there are now 0 more messages in the queue
2020-01-02 23:50:14.586 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Started timer because it was null.
2020-01-02 23:50:14.757 [TRACE] [b.handler.EspMilightHubBridgeHandler] - MQTT message just sent, there are now 0 more messages in the Queue

Script causes LED to switch ON

2020-01-02 23:50:14.914 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - * Recieved the following new Milight state:milight/states/0x1001/rgb_cct/1 : {“state”:“ON”,“level”:0,“hue”:49,“saturation”:69,“bulb_mode”:“color”}
2020-01-02 23:50:14.925 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Processing new incoming MQTT message to update Openhab’s controls.
2020-01-02 23:50:14.926 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Message ={“state”:“ON”,“level”:0,“hue”:49,“saturation”:69,“bulb_mode”:“color”}
2020-01-02 23:50:14.927 [TRACE] [b.handler.EspMilightHubBridgeHandler] - globeType =rgb_cct
2020-01-02 23:50:14.927 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteCode =0x1001
2020-01-02 23:50:14.928 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteGroupID =1
2020-01-02 23:50:14.929 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Chan Prefix =espmilighthub:rgb_cct:001:0x10011:
2020-01-02 23:50:14.930 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbState =ON
2020-01-02 23:50:14.931 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbLevel =0
==> /log/openhab/events.log <==
2020-01-02 23:50:14.564 [.event.RuleStatusInfoEvent] - fa4445ed-b6da-4f64-b98c-223e6e6f9d61 updated: RUNNING
2020-01-02 23:50:14.578 [ome.event.ItemCommandEvent] - Item ‘GartenUnten_Level’ received command OFF
2020-01-02 23:50:14.579 [.event.RuleStatusInfoEvent] - fa4445ed-b6da-4f64-b98c-223e6e6f9d61 updated: IDLE
2020-01-02 23:50:14.587 [nt.ItemStatePredictedEvent] - GartenUnten_Level predicted to become OFF
==> /log/openhab/openhab.log <==

Finally the LED goes OFF again

2020-01-02 23:50:15.417 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - * Recieved the following new Milight state:milight/states/0x1001/rgb_cct/1 : {“state”:“OFF”,“level”:0,“hue”:49,“saturation”:69,“bulb_mode”:“color”}
2020-01-02 23:50:15.428 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Processing new incoming MQTT message to update Openhab’s controls.
2020-01-02 23:50:15.429 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Message ={“state”:“OFF”,“level”:0,“hue”:49,“saturation”:69,“bulb_mode”:“color”}
2020-01-02 23:50:15.430 [TRACE] [b.handler.EspMilightHubBridgeHandler] - globeType =rgb_cct
2020-01-02 23:50:15.431 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteCode =0x1001
2020-01-02 23:50:15.431 [TRACE] [b.handler.EspMilightHubBridgeHandler] - remoteGroupID =1
2020-01-02 23:50:15.432 [TRACE] [b.handler.EspMilightHubBridgeHandler] - Chan Prefix =espmilighthub:rgb_cct:001:0x10011:
2020-01-02 23:50:15.432 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbState =OFF
2020-01-02 23:50:15.433 [TRACE] [b.handler.EspMilightHubBridgeHandler] - bulbLevel =0

Here is the script

        from core.rules import rule
        from core.triggers import when

        """@when("Time cron 0/10 * * * * ?")"""
        @rule("Beleuchtung_Aussen", description="This is an example cron triggered rule using decorators", tags=["Test tag", "Beleuchtung Aussen"])# description and tags are optional
        @when("System started")
        def Beleuchtung_Aussen(event):
            Beleuchtung_Aussen.log.info("Rule triggert!")
            Beleuchtung_Aussen.log.info("GartenUnten_Level: setting off")
            events.sendCommand("GartenUnten_Level", "OFF")

[matt1 (Skinah)]

That flash is most likely the binding setting the globe to
Min dim in case the power fails. You can turn this feature on and off. Also if you want to ensure the globes get commands you can increase rf repeats in the firmware instead of resending commands at openhab level. You can also setup multiple hubs to increase coverage.

[thowa]

Ah, @matt1 that is perfect. Setting POWERFAILS_TO_MINDIM to false prevents the flashing of the LED.

I’ve already played around with the Radio-Settings, but I wasn’t very successful.
The current values are:
Packet repeats 60
Packet repeat throttle threshold 200
Packet repeat throttle sensitivity 0
Packet repeat Minimum 20

A range issue can I exc.lude, because I’m still in Trial Phase where all bulbs are close to eachother and the esp-Hub is less than a meter apart.

I’m having currently 2 Groups of 4 bulbs per each Group.
I have set 4 bulbs to be assigned to 0x1001(1) and the other 4 buls to 0x1002(1)

I wonder, if it is better to address each bulb individually or if it is ok to controll 4 buls via one address.