EspMilightHub new binding for milight limitlessLED and easybulb

Add-ons Bindings
, ,
246

Well I think i’m close, but failing to grok something.

I created a dummy switch:

Switch Milight_cct_test   "Change hue"

I have an item for the bulb…

Switch Milight_SndCmd_cct    "Send Command" 		   {channel="espmilighthub:rgb_cct:001:0x88F1:sendbulbcommand", autoupdate="false"}

and a rule:

rule "Set Bulb Color CCT"

     when
         Item Milight_cct_test received command
     then  
       
      Milight_Cmd_cct.sendCommand(335,57,173)
      
end

this logic seems to make sense to me, but apparetly I’m still not getting it.
as I see this in mosquitto. (and of couse it does not work)

milight/commands/0x88F/rgb_cct/1 {"command":"335"}
247

You are close. Change the item to this as it needs to go to the colour channel and not to the channel you were using…

Color  Milight_SndCmd_cct    "Front Hall" ["Lighting"] {channel="espmilighthub:rgb_cct:001:0xEC591:colour"}

Also the brightness only goes to 100

Milight_Cmd_cct.sendCommand(335,57,100)
1 Like
248

All changed as noted above:

Switch Milight_cct_test   "Change hue"
Color  Milight_SndCmd_cct2    "Front Hall" ["Lighting"] {channel="espmilighthub:rgb_cct:001:0x88F1:colour"}


Milight_SndCmd_cct2.sendCommand(335,57,95)

I get this warning.

01:13:34.885 [WARN ] [arthome.model.script.actions.BusEvent] - Cannot convert '335' to a command type which item 'Milight_SndCmd_cct2' accepts: [HSBType, PercentType, OnOffType, IncreaseDecreaseType, RefreshType].

Just FYI, as I’m using a switch I added in Habpanel to trigger the rule, that shouldnt matter though, I think, as it’s just an action to trigger the rule.

249

Sorry my mistake, I left out the quotes. It should be in this format which I just tested and it ends up green…

Milight_SndCmd_cct2.sendCommand("100,100,100")
250

Works! ++

Hair pulling session officially over :wink:

Thanks for your patience and persistence.

There’s a few other odd glitches here and there I may have questions about, but mostly I see things working well, for now sleep. and thanks again.

251

One other glitch I’ve noticed that I’d like to figure out. Pertaining to the dimmer.

I have an item:

Dimmer  Milight_Kitch_dim    "Kitch dim" ["Lighting"] {channel="espmilighthub:rgbw:001:0x14BA1:level"}

.sitemap

Text label="EntryHallway" icon="light" 
		{
             Slider 		item=Milight_Kitch_dim
			}

(PS, I mostly have been working with Habpanel, just did the sitemap for this item to test it out)

This dimmer functions, in that, when I adjust the slider to a certain level, say for example 50% the light dims to 50% , although the odd thing I see, is that the slider itself on the sitemap jumps back up to 100% after the setting is sent to the bulb. The bulb retains the level adjustment (be it, anywhere from 1%-99%) but the slider itself always jumps up to 100%. I have the same issue when I add a dimmer to Habpanel.

On/Off status of bulbs seems to work properly, even if I turn bulb on/off with milight remote, the status updates on Habpanel (light ON/OFF). Also I note that if I switch the light off, either with the remote or the switch on Habpanel, the slider indicator will flip from 0% (when off) and 100% (when on)

note: adjusting the dimmer on the remote has no affect on the slider status on the UI.

also…not sure if they are supposed to, but hue/color updates on the remote doesn’t affect the indicator in the UI as well.

Not sure if these are bugs, or if I’m missing something or have an error in my setup. or perhaps even some of these things are not implemented yet.

here’s what I see in mosquitto when adjusting slider.

milight/commands/0x14BA/rgbw/1 {"state":"ON","level":8}

milight/states/0x14BA/rgbw/1 {"state":"ON"}

milight/states/0x14BA/rgbw/1 {"brightness":20}

Thanks again :slight_smile: this is a really great binding, so far loving it.

PPS. I have Homekit for iphone setup, and light (ON/OFF) status seems to work well, it is synced across iphone/habpanel/and remote. but I notice the same thing happen with the dimmer, I will adjust it on the iphone and the indicator jumps back to 100% (but the light dims to the desired level and holds it’s setting) I do however notice that when I adjust the dimmer on the iphone, this syncs with the Habpanel dimmer, (although it always jumps back to 100%)

252

This shows you have not carefully followed the setup instructions in the second post of this thread. You should see level, hue and saturation instead of brightness and RGB codes.

I am now testing the latest firmware 1.8.7 to see if anything is the setup has changed recently. All seems to be fine. Readme file is now also updated to cover all of the second post.

253

you are correct sir, incorrect copy paste for mqtt_state_topic_pattern.

thanks again. all seems to be functioning as intended.

254

So on/off, level and colour changes are all updating correctly in Openhab controls when your remote is used? It should work perfectly with the only change is I track the brightness/level independantly for white compared to colour, as the brightness of coloured light is usually much lower and white I added this feature in.

I only own rgb_cct and cct globes so I can not run tests on rgb or rgbw globe types.

255

Yup, from what I can see eveything appears to be in sync.

RGBW lights and strips are working perfectly. RGBWW lights are all in sync with the UI and the remote changes are updated all around. Openhab UI, homekit, and remote.

Color picking for CCT bulbs is slightly wonky, mostly on the homekit connection, but i’m not too attached to that. I mostly just want to use it to trigger scenes with homekit. the openhab UI and color picker on the remote seem pretty good, colors and levels are synced…(although I’m not too crazy about the color picker in openhab UI)

Colortemp slider for (rgbw_cct) has a slight issue, in that if I adjust the remote all the way to the warmest setting, the UI slider jumps up to 100, it’s all in sync from 1-100, the remote and UI match, but “0” on the remote jumps up to 100 in the UI (bulb still retains “0” warm setting.

mostly all looking good!

256

Can you post what MQTT messages are sent when this issue occurs please? I’ll take a look. I never use my remote as I use Openhab for everything, too many globes to have remotes for :slight_smile:

Yes the old CCT globes do things in a very different way, they can not jump to an exact brightness/level and the hub has to do some trickery to fake this ability. In short it sends an off command and then X amount of level up commands until the desired level is reached. I usually only turn mine on and off and don’t set the level very often. I have heard that some of the newer CCT globes actually respond as RGB_CCT globes and work far better using those remotes, but sadly mine only use the older method. Still worth fault finding to determine if this is a hub firmware issue or my binding at fault so it can be reported at the correct place to be looked at.

If buying Milight globes try to stick to only buying the ones that are rgb_cct types.

257

This is what I see in mosquitto. you can see it start out as color temp 227 and as I slide to the left on the remote towards the warm color, the number is going up, then you’ll see it jump back to 153 as I have slid all the way to the warm section of the remote

milight/states/0x88F/rgb_cct/1 {"color_temp":227}

milight/states/0x88F/rgb_cct/1 {"color_temp":235}

milight/states/0x88F/rgb_cct/1 {"color_temp":242}

milight/states/0x88F/rgb_cct/1 {"color_temp":244}

milight/states/0x88F/rgb_cct/1 {"color_temp":244}

milight/states/0x88F/rgb_cct/1 {"color_temp":262}

milight/states/0x88F/rgb_cct/1 {"color_temp":264}

milight/states/0x88F/rgb_cct/1 {"color_temp":281}

milight/states/0x88F/rgb_cct/1 {"color_temp":283}

milight/states/0x88F/rgb_cct/1 {"color_temp":303}

milight/states/0x88F/rgb_cct/1 {"color_temp":303}

milight/states/0x88F/rgb_cct/1 {"state":"ON","level":100,"color_temp":303,"bulb_mode":"white"}

milight/states/0x88F/rgb_cct/1 {"color_temp":329}

milight/states/0x88F/rgb_cct/1 {"color_temp":355}

milight/states/0x88F/rgb_cct/1 {"color_temp":357}

milight/states/0x88F/rgb_cct/1 {"color_temp":153}

milight/states/0x88F/rgb_cct/1 {"color_temp":153}

milight/states/0x88F/rgb_cct/1 {"state":"ON","level":100,"color_temp":153,"bulb_mode":"white"}
258

If you only slid your finger in one direction I would say that could be a bug in the hubs firmware or a faulty remote. The binding is doing exactly what the incoming states are telling it to do.

Try using the SNIFF feature of the hub and see what the remote is sending.

259

My guess would be the remote, as when I adjust the slider in the Hub web Gui, it works properly/

I’m not really sure how to decode the sniffer commands to know what they are saying enough to say for sure.

I have another remote, I may try…

eitheway it’s no big deal. I probably wont use that functionality anyway.

260

Hi Matt, you’re probably aware of the new implemented feature by Criss with his esp hub introducing this:

New Features

  • ( #375 ) Add oh_color field, which adds support for OpenHAB’s colorRGB channel type

I guess which is the relationshipt between your bind and this feauture and if a change is needed from you to use it. In fact it stated that is a OH channel type
Sorry if it is a sot question

your code goes here
261

Why would I be aware of something that was added less than 2 days ago in a non released dev firmware? The feature looks good and is good to have but the binding will not be updated as that would break the smooth updating for anyone already using it for no benefits. There’s a saying, if it ain’t broke, don’t fix it.

262

on another note: I see the binding loose the connection to mosquitto from time to time, it only blips for a second, and things appear to be functioning properly. Just curious if anyone has any suggestions of what to look for. It always comes back “online” and it’s usually just a second blip…

16:49:48.354 [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) [192:org.openhab.binding.espmilighthub:2.4.0.201811130904]

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:49:48.359 [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) [192:org.openhab.binding.espmilighthub:2.4.0.201811130904]

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:49:48.408 [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:49:48.432 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:esp8266Bridge:001' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException

16:49:48.439 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA1' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)

16:49:48.446 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA2' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)

16:49:48.452 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA3' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)

16:49:48.460 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgb_cct:001:0x88F1' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)

16:49:51.434 [INFO ] [ub.handler.EspMilightHubBridgeHandler] - MQTT sucessfully connected

16:49:51.451 [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:49:53.449 [INFO ] [ub.handler.EspMilightHubBridgeHandler] - MQTT sucessfully connected

16:49:53.474 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:esp8266Bridge:001' changed from OFFLINE (COMMUNICATION_ERROR): MQTT broker connection lost:Connection lost (32109) - java.io.EOFException to ONLINE

16:49:53.483 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA1' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

16:49:53.496 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA2' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

16:49:53.504 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgbw:001:0x14BA3' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

16:49:53.511 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'espmilighthub:rgb_cct:001:0x88F1' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
263

I was only acting like a mosquitto broker forwording the news to you and aiming to understand if that would be relevant to your binding. I was thinking this could potentially be of your interest
Absolute no criticism to you, sorry

265

Try swapping network cables and testing any ports that are punched down. If wifi check the channel it is on and what channel your neighbours r on.

Mine is rock solid and stays connected for weeks. The mqtt is setup in the binding to handle a dodgy connection and will forward messages when it reconnects.

266

That occurred to me, wifi is a bit weak on the Pi. but I think the communication issue is between the binding and mosquitto which are hosted on the same machine, so I figured that should not be an issue?

That said, as I think about it, Even though they are hosted on the same machine, with the same IP address, they of course have different ports, so thinking that if they are not communication via “localhost” and instead via IP then they perhaps still utilize the network. I had assumed it would not, but perhaps that is the case.