Seems perfect ! Thanks you !
Hey @matt1 and others, I was thinking if it was possible to have two Milight bridges in my network. That way I could split up the globes between the two hubs and have faster completion times when controlling many bulbs at once. Currently, the only way I see this can be done is by having two separate MQTT brokers in my network. Alternatively, if the binding allowed to specify the MQTTās topic prefix as a parameter, then one hub could be bound to topcis milight/# and the other could be bound to a different topic, e.g. milight2/#. I think that would be nicer than to introduce a second MQTT broker in the network. Or am I missing something here and it can be done in another/easier way? If not, consider this to be a low priority feature request. 
I have just built two hubs to do this myself so great mindsā¦
I have tried it already very quickly and it did work as I wanted people to have the ability to create two virtual hubs if they wanted different settings for different groups of bulbs. Example some globes have halogen style colour temp changing and others do not change. The binding uses a unique client Id for each bridge you add using the openhab uid so you should be able to add as many as your broker allows to connect. Have you tried doing this and is there an issue as I have not done much testing? The scanning for new globes is actually a second connection to the same broker and I have not had issues when testing those features.
Currently I suspect the firmware will/may cause issues due to the frequency it broadcasts on, so have been meaning to request a feature of Sidoh on github. The ability to set which of the six frequencies the hub broadcasts on so both hubs can be different. Itās the way I plan on getting my rf repeats down even lower than 8 to make a while house loads of globes change faster.
Edit:
Sorry, probably a stupid question - could I use this alternate binding with the proper MiLight hub? I have an older one.
Great piece of work,
My wemos D1 turned up yesterday, I had some NRFs from mysensors projectsā¦
7 jumper cables and 15 minutes later I was talking to my bulb!!
Nowā¦ One question, how do I get the light bulb back to white after playing with the colour picker on HABPanel, or the sitemap, preferably without adding yet another button to the sitemap?
No you need to do two things to use this binding.
- Spend $10 on two ready made boards and connect the two, then flash it with an already compiled file.
- Setup MQTT broker which if you use openhabian can be done automagically by the setup tool and it can run on the same hardware as your openhab runtime.
If you do setup the opensource hub you can use it with either of the two bindings, but it does not work the other way sorry.
@vzorglub Cant take the credit for the hub, Chris Mullens did and is still doing a great job. Very active project which is great to see. What globes do you have? RGBW globes can use a shortcut to set white as the globes do not havea saturation control, so the hub allows a threshold to be set in the parameter setup of the ESPmilightHub thing. Click on pencil icon in paperUI to see what options are available.
If you have a google home or Alexa you can use another feature I added to trigger white with a set HUE and SAT value which is also found in the hubs parameters in paperUI. I think the google home parameters are setup and active by default.
Lastly a third way is to move the colour temperature control and you jump back to the white LEDs if you have a RGB_CCT globe.
Too many options maybe but I like to add the ability for people to customise on their own.
I read about that further up in the thread but I am struggling with it. I have set the value to 12 in the binding. Do I need to set something in the hub? I move the cursor near the center on the colour wheel and and I can see the Saturation value changing to less than 12 in the OH log, however the light doesnāt go back to whiteā¦
I change this value from -1 to 12 and the log shows:
Received HTTP PUT request for update configuration at 'things/espmilighthub:esp8266Bridge:001/config' for an unmanaged thing 'espmilighthub:esp8266Bridge:001'.
However, when I go back into the setting it has changed back to -1!!
That may be because you have used MANUAL TEXTUAL configuration which locks the settings to what is written in the text files and prevents paperUI from changing them. If you prefer textual config use this
RGBW_WHITEMODE_SAT_THRESHOLD
All the possible settings are listed in post 1 or 2 of this thread. PaperUI gives you hopefully enough information in the descriptions on what each setting does.
Bridge espmilighthub:esp8266Bridge:001 [ADDR="tcp://192.168.1.100:1883", MQTT_USERNAME="myusername", MQTT_PASSWORD="Suitcase123456", RGBW_WHITEMODE_SAT_THRESHOLD=12]
{
1 Like
Thanks, I was just about going to do that!!! That works!!
Ok, Iāve whittled down my list of tasks to sort so now looking for more! So Iāll order some bits and get this working. My current bridge keeps dropping offline, so isnāt always firing the dim commands.
Q: on the range of the NRF24L01 modules - without an aerial module, how far roughly?? Is only another $1 to get the model with an aerial, but does change project case considerations tho. I have a two story house.
Great, Iām sure you will agree it is worth the time especially if you use the milight remotes. The MQTT works very well and handles things going on and off line if you have a bad network cable for example.
That is hard to comment on because it depends on where you buy your nrf radio from because of the fact that so many of the places are selling fake/counterfit nrf chips, some of the fakes work OK and others are shocking. With a 2 story house I would go for the nrf board that I use and is covered in my post in this thread with pictures of the boards that are available, but you will need to solder as the boards with the built in PA and low noise amp (LNA) draw more power than what the nodemcu clone boards can supply. There is also a board worth looking at and it may have a real nrf chip as well as having decent capacitors on the board.
Note the nice large yellow capacitors that this board has.
So can you solder?
yes = go for pa+lna boards with antenna and metal shielding. 1 bridge will cover your whole house.
no = go for a quality NFR board with no pa+lna then it will work with bread board style wires. Or take a gamble on the itead board which may draw too much power due to the pa+lna and then require more work for someone without soldering skills but the board should work with the power injector boards that I show in my other post.
I would also recommend you use the āD1 miniā as the pcb traces are shorter and the clones can supply more power than the clones of the nodemcu. I have been doing some more testing with my oscilloscope and when finished I have some more test data to share.
1 Like
Does anyone have any feature requests? I am doing a code review of the binding at the moment with the goal to streamline the binding and then try to upload to the marketplace. Whilst I am going through the coding it is an opportunity to consider new features.
Maybe a channel with the ip address of the gateway so that we can link directly to it for config
Matt, sorry for not replying to this sooner, as I have not realized I should answer your questions! I have not tried creating two bridges, yet. I probably donāt fully understand. Will the two bridges not publish on the same MQTT topics? Hence both MilightHubs will process the messages, so things will not be speeded up. Iām probably missing something here. If not, consider configurable MQTT topic prefixes as my feature request, because that way each bridge could be bound to its own topic and the MilightHubs could be configured for an individual topic, each.
Beside of that: Thank you for the very useful frequency separation request on the ESP Milight projct ā very good idea!
@vzorglub
Do you mean the IP of the broker or the esp8266? Sounds like an easy thing to add but I can not see how it would be useful, can you explain it to an idiot please as to why/how you would use the IP in a string channel?
@devax
Yes but AFAIK that wont cause issues as you can stop one of the hubs from listening to the remotes, but once again I have not tested it and it is late at night right now so you may be seeing something that I am overlooking. My guess is that in a month or twos time the firmware for the esp8266 will support multiple hubs also listening on the same MQTT topics, when this feature is added I think it will be the time to look at it. I like your suggestion, Iām just thinking it may not be needed. I dread how much needs to be changed to do that though as the binding kind of needs a predictable MQTT topic structure for the auto finding of globes to work.
I try to explain what Iād like to do, because I donāt know who I can achieve it, currently. When I turn off all 30 lights, it takes a certain amount of time to do so and I would like to minimize that time. I know with a proper ESP hub with antenna and everything I can reduce package repeats to about 8 and optimize delays. But if I want to further reduce the lampsā reaction times, I thought it would be nice to have one ESP hub to control 15 of the lamps and have a second ESP hub to control the other 15 lamps. That way, time to turn off all lights could be cut in half. If the ESP hubs in addition have frequency separation, this would be perfect. But even then, I currently see no way on how I can set this up, because both ESP hubs will receive all commands from the bridges and execute them, so no time saving here.
Unless what youāre saying is that the ESP hub does not send out a command if the channel has not explicitely been added through the web UI. I would have to re-check, but I think the Hub sends out all commands received on the command MQTT topic.
That is the exact reason I am doing it and I still believe it will work fine in theory once the new feature is added. I understand the RF side of things very well as I used to write custom RF protocols at a low level, what I am not as strong on is MQTT.
You are thinking use 2 hubs still doing 8 repeats and doing half the globes.
I am thinking use 2 hubs doing 4 repeats and doing all the globes each.
Both ways would result in half the delay, how you set each method up is different which is why my way does not need a MQTT change.
How I see it working is broken down as follows. The binding only has 1 hub setup, but two or more physical hubs are actually doing the workā¦
- Openhab sends command to turn all 30 lamps off.
- MQTT broker sends the commands out to both the hubs.
- Hubs broadcast it out on the RF channels that wont collide (in the new feature not yet added)
- Globes are frequency hopping and will hear the first hub it hobs on to. Because the globes hopping is the reason the RF repeats needs to be at 8 having two or three hubs should get you lower.
- Both hubs then publish the state back to openhab and this is where it needs testing, worse case you disable one of the hubs from broadcasting the state back to openhab. I suspect it will still work fine.
- When you use a milight remote both hubs will hear and try to report back, chance this will cause an issue, but you would disable one of the hubs from listening to the remotes which is already possible.
The issue I can see is if people are wanting to use multiple hubs to increase reliability of the remotes in a very large house, I have no idea how far away the LNA models can hear the remotes.
As a ui shortcut to the bridge configuration
Ah ok, now I got you. Thanks for the detailed explanation!
The 2 hubs / 4 repeats / all globes sounds very reasonable and will work fine in my place, once I have built a more reliable hub. For people who have difficulties in covering the whole area with one hub, it still would be handy to set up the 2 hubs / 8 repeats / half the globes scenario. It can be done already by using two different MQTT brokers. It sure would be easier if the MQTT topic prefix could be chosen per bridge. Might be not the most important feature request, just reporting because youāve been asking.
EDIT: As I read there are three frequency bands available (ālowā, āmidā, āhighā), I guess the maximum optimisation limit would be 3 hubs / 3 repeats / all globes. It will probably be ok in most cases. Probably does not make sense to think about further potential optimisation at this point.