Hi guys,
do I need MQTT to get this binding working or can I use it like all “normal” bindings?
Thanks
This binding needs a mqtt broker setup. However openHAB does have a different milight binding that does not need mqtt, but see the very first post in this thread as to why people use the mqtt version.
Binding is now built into openHAB v3.1 Milestone 1 and newer that was released today.
Readme is now found on the website with all the other documentation here:
EspMilightHub - Bindings | openHAB
Thanks to all those that helped test before it was merged to get things fixed and the people who reviewed the code to get it merged.
3 Likes
Just stopping by to say thank you for this wonderful binding. It works very well for me and was easy to setup for the most part.
I’ve got one suggestion for the documentation though since I had to figure that out for myself: it should be mentioned that, if you want to control your devices with group ALL in addition to the specific bulb group you need to add a separate thing (as it was not autodiscovered at least for me) for the group and connect it to the same items.
Edit: This brings up another question: I now have both things (the one for my led stripe on group 1 and group 0/ALL) linked to my items. So when I switch the light ON or OFF the command will be sent to all the brightness channel of both things. This is ok for me since I do not use the other groups right now but if I did I would always switch all devices on or off even if this wasn’t my intention. It’s there a simple way to tell OH that it should only send commands to one of the linked channels or do I need separate items for the group and use rules to propagate a group change only unidirectional to the single devices?
Good point, can you add it to the docs after your second issue is resolved? There would be two different approaches to adding a ‘group’ control.
- Using openHABs built in group feature that allows any number of lights to be grouped as often you have lights with 5 globes in them and the milight group 0 can only do 4. This is how I run mine.
- Use the remotes group 0 ability which will always change all the 4 lights. Yes you need to manually add them.
Think of it as modelling only light globes instead of modelling the controls in openHAB based off the remote control buttons. Two different ways.
Sorry I completely do not understand what your issue is, nor what the question is. Can you reword it and then read it again considering how another person may not understand?
Yes I can suggest a documentation change for the group handling. I solved it like you described in 2. but due to my second issue I may change this to your approach 1.
No worries if you did not understand what I meant with the additional question, let me try to explain differently:
Right now I have two things, one for group 1 and one for group 0 (ALL). For simplicity however I just linked the brightness and color temperature channels of both things to the same item as you can see in the attached screenshot Screenshot_2021-03-23-07-33-23-247_org.openhab.habdroid|230x500
This works fine as long as you only use one group in addition to the ALL group but will cause a change of both groups whenever you send a command to the item: if you change the brightness item for group 1 OH would send this command to the group 0 and group 1 things. By changing the group 0 it would also change e.g. group 2 item if it was setup the same way (linked to groups 2 and 0 things). I hope this makes it a bit clearer.
No I would not recommend doing that. Each things channels should be linked to its own item. The way it works is when you move a group 0 control, the hub will send updates to the 4 MQTT topics and this will in turn update the 4 controls in openHAB.
Of course since I don’t use the group 0 very often if there is an issue let me know so I can retest and look for a bug.
Yes that’s exactly what I realized just after I configured it like that… I don’t need the group 0 as an item as I only use one group anyway, I just want to stay in sync when I use the remote. But the solution is simple of course: I’ll create a separate group 0 item and use rules to propagate the group 0 charges to my group 1 item but not vice versa.
I was just thinking at that moment that it would be helpful to have a channel profile that works as the opposite of the ‘follow’ profile: it could be used to propagate changes from the thing channel to the item but not from the item to the thing (a read-only profile). However that does not seem possible.
This is definitely not a bug in your binding, I’ll just have to create one additional item.
A rule should not be necessary, I coded it to update the 4 or 8 remote channels automatically when a group 0 is moved. It should just work, but as mentioned I have not tested it in months. Moving the group 0 on your remote should update the other ‘things’ that share the same remote code ID. If this is not happening let me know so I can look into it and also which remote you have…
Sorry I do not know this area of openHAB very well, it may be best to ask this as a generic how to use openHAB in a new thread. A lot is possible in openHAB and probably no one person comes close to knowing it all.
Oh now that’s interesting. It does indeed not work for me unfortunately. If your binding would do that I would not need any other items or rules whatsoever. Please let me know if I can help you with log files or anything. I also created a pull request for the Readme tonight. You can ignore that for now I guess since it did not make sense in this case. I don’t think anyone needs the ALL group as a separate thing or item when your binding handles it like you say.
I use a fut091 remote btw.
Can you test if it only works for remote code 5 to 8? Perhaps it is not working for 1-4
Edit: @DrRSatzteil
I looked the code over and it looks like you must create a thing with the group 0 for the mqtt messages to be subscribed to and hence processed, I could be wrong but you probably don’t need to create items if you don’t want the controls, simply creating a thing may be enough to get it working.
I can see I did code the feature for a fut091 here, under void changeChannel(String channel, State state)
This remote only supports up to four channels actually. It’s this model: https://m.de.aliexpress.com/i/4000217570398.html
But you are right: I disabled my custom synchronisation rules and my items still change when I use the ALL controls on the remote. That’s great, so I can get rid of the unused items again though it seems a bit strange that an unlinked Thing is able to change the state of my items. However everything works as designed then I guess!?
Yes
So it is important to document this, can u do it in the same PR? thanks
Sure I will do this. Thank you for your help!
@matt1: I’m a bit lost in Github right now… I thought I know enough about Git and Github for this simple task but that’s apparently not the case… I somehow managed to screw up the PR and it’s closed now… Please let me know if I should create a new one… I’ve got all the changes here.
Hi @matt1!
Until today, I have used the jar in the addons catalog, openHAB3.1 # 2350
Updated to # 2361 today. After rebooting openHAB, I received EspMilligtHub binding errors, it was previously updated, everything was fine. I removed the addons jar from the catalog in order to establish the binding via the openHAB interface. But in the list of bindings, I did not find EspMillightHub bindings.
What am I doing wrong?
It does not show up because it is part of the mqtt binding, so to add things you click on mqtt binding.
I recently upgraded to openHAB 3.1.0.M4 (coming from 2.5)
So now I am using the mqtt esp milight binding, but I encounter a strange issue.
I have a Milight RGBW bulb configured as a “color” item like shown below:
Color RGBW_Bulb_E14_Color “test lamp E14 color” {ga=“Light”, channel=“mqtt:rgbw:0x11121:colour”}
When I use openHAB controls, within the openHAB android application, then I can change the colors and the saturation.
When the saturation is set lower than the threshold value the bulb changes to white mode.
The saturation slider in openHAB should now function as a brightness slider (I assume), but it doesn’t.
If I do the exact same thing with the Google home application it works perfectly.
Details:
When I change from a blue color to white then the openHAB log shows:
Item ‘RGBW_Bulb_E14_Color’ changed from 229.090912,81.960785,99.000000 to 0.000000,0.000000,99.000000
->Bulb changes to white
MQTT explorer shows {“command”:“set_white”}
When I now change the brightness with the slider then the openHAB log shows:
Item ‘RGBW_Bulb_E14_Color’ changed from 0.000000,0.000000,99.000000 to 0.000000,0.000000,30.000000
->Nothing changes
MQTT explorer shows {“command”:“set_white”} again
When I change the brightness from the Google home application the openHAB log shows:
Item ‘RGBW_Bulb_E14_Color’ changed from 0.000000,0.000000,30.000000 to 0.000000,0.000000,99
(note that there are no ‘zeros’ behind the last value)
->Brightness increases
MQTT explorer shows {“state”:“ON”,“level”;99}
Any help would be appreciated.
That can be disabled or changed where the threshold is, so this is normal.
No saturation is different to how bright a globe is. You can have pastel colours that are very washed out red for example but the globe is still bright. Saturation is the ratio of the white LEDs VS the raw colour/s.
You would need to look at the openHAB event log to see what command is being sent to the binding. The developer sidebar is one way to do this and it allows for filtering so you only see what you wish. I am guessing that google home is sending a brightness command to the event bus VS your sending a saturation change. You can link multiple controls back to the same channel so if you wish to have a separate brightness slider and color controls you can do this.
Do a search for OH3 widgets as there are a number of custom widgets people have created, one example is this one.
OH3 Color/White Bulb Widget - Add-ons / UIs - openHAB Community
Currently I am using the sitemap for the Android application, I don’t think there is that much flexibility.
Anyway, If I select the item from the openHAB settings page then I have HSB controls. Also with these controls the brightness settings only work when the bulb is in color mode.
The openHAB log shows what you would expect when the brightness changes. The last number changes, so that is correct. The problem is that the bulb doesn’t respond to this when it is in white mode when controlled from openHAB. When I use the google home app the openHAB log shows just one value, so instead of 0,0,50 it just shows 50 which actually changes the brightness of the bulb.
Below the sniffing results of the bridge when I change the brightness in openHAB from one value to another in white mode:
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 13
Sequence Num. : 3B
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 13
Sequence Num. : 3A
When I do this with the google home application:
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 0E
Sequence Num. : 40
rgbw packet received (7 bytes):
Request type : B0
Device ID : 1112
b1 : 00
b2 : 01
b3 : 03
Sequence Num. : 3F
Strange to see that the google home application sends brightness changes in white mode as a single value and openHAB itself as a complete HSB value.