Not sure what I could have done wrong - there is not even the ‘show more’ button that you sometimes see hiding additional channels. Is this one missing for the RGBW thing?
When I trigger a command from OH (via the sitemap) I am still getting the received update [] rule triggering every time.
espmilighthub log (DEBUG enabled)
04-Mar-2018 21:24:02.991 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - MQTT message just sent, there are now 0 more in the Queue
04-Mar-2018 21:24:02.992 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - MQTT broker replied an outgoing command was recieved:org.eclipse.paho.client.mqttv3.MqttDeliveryToken@46347e67
04-Mar-2018 21:24:03.245 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - MQTT sending queue has been cancelled
04-Mar-2018 21:24:03.338 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Recieved the following new Milight state:milight/states/0x684C/rgbw/1 : {"state":"ON","level":100,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}}
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - ***** Processing new incoming MQTT message to update Openhab's controls. Found the following:
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - globeType =rgbw
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - remoteCode =0x684C
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - remoteGroupID=1
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Chan Prefix =espmilighthub:rgbw:001:0x684C1:
04-Mar-2018 21:24:03.339 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - bulbState =ON
04-Mar-2018 21:24:03.340 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - bulbLevel =100
04-Mar-2018 21:24:03.340 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - bulbMode =white
04-Mar-2018 21:24:03.341 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Could not find "color_temp": in the incomming MQTT message which was: {"state":"ON","level":100,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}}
events.log
2018-03-04 21:24:02.987 [ome.event.ItemCommandEvent] - Item 'myBulb' received command ON
2018-03-04 21:24:02.990 [vent.ItemStateChangedEvent] - myBulb changed from OFF to ON
debug output from rules
04-Mar-2018 21:24:02.992 [DEBUG] [org.eclipse.smarthome.model.script.Rules-Test ] - update --- ON
04-Mar-2018 21:24:02.993 [DEBUG] [org.eclipse.smarthome.model.script.Rules-Test ] - change --- ON
04-Mar-2018 21:24:03.343 [DEBUG] [org.eclipse.smarthome.model.script.Rules-Test ] - update --- ON
rules
when
Item myBulb received update
then
logDebug("Rules-Test","update --- " + myBulb.state)
end
when
Item myBulb changed
then
logDebug("Rules-Test","change --- " + myBulb.state)
end
item:
Switch myBulb "My Bulb" {channel="espmilighthub:rgbw:001:0x684C1:level"}
As you mentioned, I do see the state update coming back from the hub after receiving the ‘command’ from OH but it doesn’t appear to be an off-by-one situation.
Can you explain this in more detail, I dont understand? Nightmode is meant to lock the remote out so it can not change brightness or colours until the mode is disabled AFAIK. If I change to 1% dim setting it would not be true nightmode to lock out the remote. Nightmode is as a guess 1/4 or less of the brightness of 1% at least with my globes.
New channel for RGBW and RGB globes to expose the disco mode channel that was previously only on RGB_CCT
New channel for all globes except CCT that displays the last known MODE of a globe.
Fixed bug for when password is empty and now allow empty usernames.
new night mode @ 1% option which defaults to off/false.
Edited the discovery service to also play nice with null password and user.
NOTE: to see/use the new channels you may need to link the channels OR remove and re-add the globe. Depends on if you use a manual thing file to setup the globes or if paperUI added the globe.
I was not aware for the remote lock in night mode, I don’t have any Milight remote.
Create some other buttons on my panel to trigger white or night mode is not very WAF…
Yes, Nightmode is 1/4 or less of the brightness of 1%, but 2% DIM is not so far from 1%, and I can do without the 1% DIM and replace it with Night Mode.
In this way, my wife can easy handle this with the dimmer only, and cherry on the cake, it is possible to ask google to set the light to 1% to get Nightmode, and it is very handy when you arrive in the living room in the middle of the night with baby in your arms
I understand that I maybe be the only one who want this feature, so, don’t bother with this I can do somes rules to do that, and with the new Last Know Mode Channel, maybe I can do it in a smarter way.
Feature added to the level channel only so GA won’t work yet till I do more work. If you already downloaded the 05-03-2018 I uploaded a newer copy so re-download. Very little testing done as it is late so let me know if it works. If any issues use the previous ZIP which has been left.
Bug? Works for ‘white’, ‘color’ and ‘scene’ modes but bulb_mode - night is not updating. i.e. set the bulb to night mode and watching MQTT I see the following status update come in: {"state":"ON","level":100,"bulb_mode":"night","color":{"r":255,"g":255,"b":255}} but the bulbmode channel, and linked item doesn’t update to ‘night’.
Seems I was wrong as I was watching the globes in the event.log when things were changing. I stil think you can do it by using rules to look at command as that seems to only get sent when it came from an openhab control. You could then use another rule that compares what it has been changed to and if it does not match the command then it must be external to openhab. I will have to look into it further so don’t go writing too many rules.
This is my first binding and I am still pretty new to openhab so it is great to have feedback.
I added 1TRIGGERS_NIGHT_MODE=true to the thing configuration file and when I set Dim to 1%, the bulbs switch to night mode, and go back when I set >1%.
Just one bug, when the command is sent (ex: I was previously at 50% Dim and I send 1% command) , the Openhab value of the dimmer go to 1% and go back to the previous value (50%), even if the bulbs switch to nightmode. I think it is just because the real value of the dim was updated. Is it possible when you ask to switch to night mode, to set the Dim at 1% for real ?
Not a bug, but yes I agree it should display that as well so will add this feature. BTW your states have RGB codes in them which tells me you have not followed the setup instructions fully and not all features will be working till you do this…
In the box called group_state_fields you need to untick brightness and Color, then you need to tick level, hue and saturation instead. Leave the rest on defaults.
This is found in the hubs control panel not the binding.
Just installed last version without any issues. The dimmer report correctly 1% when send 1% Dim and switch to Nightmode as well. Also it switch to night mode when you ask Google Assistant to set 1% !
Thanks a lot ! That’s perfect !
PS : I don’t know if it work as expected but when you ask google for a color, it work but the dimmer is pushed to 100%, whatever was your previous dimming status.
Yes that is expected, HSB controls are made up of hue saturation and brightness. Funnily that is what the hsb stands for and you need to specify all three. You should see the command in the event.log and my binding just follows the command.
If you want a set Color and brightness consider creating a scene button and make that switchable.
Ok, it is not a issue for me, just want to report it just in case.
Maybe Google don’t keep in memory the dim status, so when you ask for a color, it will set the full dim by default…
Just install and “wow !” It works fine.
First my GU10 problem doesn’t seem to appears since I have made a “better” board and not using breadboard.
The only feature missing for me is for rgbw bulbs when sending saturation over a certain value (click near the center of the color wheel), with “official” milight binding, bulb automaticaly switch to white (WAF is better !)
I need to make some tests with my google home but befor i must switch my items/rules/sitemap to use this binding !
I must disagree with you a little on this one. I find it very annoying that the the other binding switches to white in that situation. If I am scrolling around though the colours and accidentally get too near the centre, the light switches to bright white!
However, it would be perfect if this ‘minimum colour saturation’ value were configurable so it could be set to a lower value to avoid accidental triggering but high enough so if I were to select somewhere near the centre it would switch to white without having to get it absolutely perfectly in the middle.
Obviously this is only an issue for bulbs such as the rgbw that do not support saturation.
Good suggestion that I am happy to add after some feedback first.
Is it white= sat>threshold. please write it two ways to ensure I understand if it is the value ABOVE or BELOW a threshold that should trigger white. I’m pretty sure it is white when X drops below the threshold.
What should the default be set to? If you have it setup can you play with it and watch the event.log to see what threshold seems the best. No doubt you will all want a different value but I need to set a default which people can then change, or I can set the default to -1 which disables the feature by default. Guessing the size of your screen and your finger size will influence what you like it set to.
Feature will only apply to RGBW globes and yes will be configurable and able to be disabled with -1.
I am currently testing some major changes to the code so wont be releasing anything new for a few days till it is proven on my own setup.
Tested and working - Thanks