Use ESP8266 to control unlimited groups of milight or limitless LED bulbs in Openhab2

Thanks for the work guys. I managed to create rules fitting my milight RGB bulbs and RGBW strip controller. I also made a rule for the general zone 0 of every bridge, which lets you control all zones, so that it changes the state of all other zones.

In the example there are items for the group 0 and for the group 1. They are also controllable by Alexa.

Items
Rules for group 0
Rules for group 1

Maybe in future I will also add simple state synchronization so that group 0 goes OFF if all single groups have been turned OFF.

Would anyone know how hard it would possibly be to convert these rules over to Lamda? This would let have 1 rule and then you can pass the group/item into the rule to control them?

And do think its best to have a separate bridge almost for each room? You can then use separate remotes with each bridge to control lights per room easier?

I’m loving all the work on this thread. I have a question more related to the bulb hardware itself. I want to be able to set the bulb hue WITHOUT having it fade to the color. What’s crazy is that I know the bulb itself can do this because several of the disco modes do a hue shift without any fade. Just wondering if there’s some sort of hidden command to exploit or if sadly what I suspect is true: there’s no way to do it #sadnessforever

@Luis_Santi the globes only listen to remotes and the hubs emmulate a remote. This hub does repeat the RF commands multiple times in case the bulb misses the RF, by playing with the repeat values you may find you can change colours faster, but you will be limited by what the globe can do. Fast colour changing is not something I have played with yet. I do have a wish to emmulate a TV running in the house when the alarm is armed, so will be looking at it sometime in the future.

@ptmuldoon Have no idea what Lamda is. The best way forward is a binding and then these rules wont be used and things are easier for everyone, just started on the binding now and it is slow as I am new to bindings, eclipse and java… I would not use a hub per room, but multiple hubs would be great when you need more reach out of the RF radio. They do make nrf radios that have an amp in them that can do 1km / 3000 feet so in theory if local laws permit you can use one of those and have a single hub to do the whole house. Less cost and power used by doing that. I have a large number of NRF modules to test to see how the range goes.

I wanted to post an update on my progress of developing a binding for the EspMilightHub which is what I will be calling it.

Can I get some feedback as to what type of globes others own and if you will be keen to try this binding out? It is Hard to predict how much work still needs to be done as this is my first binding, but it now looks to be only days away from having something worth sharing depending on what type of globes you wish to test.

Roadmap and progress for the development is:

  1. Send + Receive MQTT from binding (100% Done)
  2. Create a bridge and add ability to input Address, user and password for the MQTT broker so these dont have to be hard coded. (100% Done)
  3. Connect to broker and fetch all stored globes that are setup (Done) and auto find and add these as things (100% done)
  4. Add the code to make the globes work. (40% done and the rest should be quick to do as I wrote the rules in this thread and its just a matter of moving them over)
  5. Figure out how to create a working JAR file to share with anyone happy to test.
  6. Add any improvements or fixes from feedback and improve the logging to help fault find any issues.
  7. Work towards submitting the binding last.

For myself, it’s been a matter of finding the best way to control RGBW Philips and Lightify bulbs with a remote control. So I’ve been passing this information over via a rule to control them via the mqtt broker. It’s not perfect and there is a delay, but it works.

@ptmuldoon Thanks for the post with how you use it, that is the sort of thing I need to keep in mind when doing the coding to see if it makes sense to create a “remote thing”. The binding I am writing already requires you to add a “Bridge” as a thing which would auto find and add globes if your MQTT lists any saved states of globes which you could then remove and hide to stop them getting auto added back.

Anyone with this hub can see the list that will auto find globes by doing this

mosquitto_sub -u usernamehere -P passwordhere -p 1883 -v -t 'milight/#'

All the saved states of the globes get listed when you connect to the broker, so this will need to be correct for my binding to add your globes smoothly.

Adding a remote thing would work (and be next to no work to do so) but it would probably still mean just as many rules to redirect what a button pushed on the remote does to a different brand of light or totally different type of product like shutters. If it does not save any work for you and still needs rules I probably wont add a remote thing right away as I personally do not use remotes in my house, I have custom made hardware buttons that I designed myself that I need to write a binding for next to get the whole solution slick and working. EDIT: Actually it would give you one feature and that is the ability to know if the Bridge looses its connection to the MQTT broker, your current way does that ever pose an issue and would it be helpful to know when the remote will not work due to MQTT issues?

My goal at this stage is to get a 100% stable binding fully tested with rgb_cct globes and then share it with people for testing and slowly add more support for different globes as I find people happy to test that need a particular globe added. If that means a remote thing then it is easy to add if you wish to test.

Feature requests are also very welcome at this stage. For example when faders/dimmers in openhab are at 0 value I will put the ability to select if the user wants this as the globe is off, or if it is the lowest level of light the globe can create. Knowing what people want to see helps to ensure it is easy to add later on or added right away.

Big thanks to @sidoh for making the bridge open source. I am now pleased to say a binding is now working and I am happy to share it. More info in the following thread linked below as I will leave this one for those that wish to use rules.

So since this is for the saturation bulbs, how can I get it to work with the RGBWW ones? I am trying to get it to work with Matrix Theme for HABPanel.
I receive a HSB value from HABPanel then need to convert it to RGB and publish it in this string:

{"state":"ON","brightness":255,"bulb_mode":"color","color":{"r":4,"g":0,"b":255}}

Any ideas?
I took out the rule for the CTTemp already, but still am working through the errors.

I have written a binding which does everything for you, the link is in the post directly above yours. I will add the link to the first post to make it easier to find

You have not followed the setup instructions in the first post of this thread if your seeing brightness and r g b values in the json blobs of the mqtt messages. You are best off following what I have in The setup instructions which is also required for the binding to work. This is to use level and hsb in the json this way you do not need to do in necessary conversions. The espmilighthub hardware speaks 0-100 values and so does openhab, the reason for it defaulting to 255 brightness is the author uses a different automation package not openhab.

Hi @matt1
It is possible to order ready to run hardware (I need connect this to raspberry 3b+) ?

It is pretty easy to plug two ready made boards together and flash them with a BIN file that is already compiled, but if you can not do it, then try and find someone near you that can do that. Setting up the wifi after it is flashed is probably the hardest part and that will need to be done at your house where the wifi is. Best to take it one step at a time and give it a go.

So will this work with any of the milights that work with the remote? I’m looking at some of their outdoor lights.

Yes AFAIK every single milight globe will work and all from the same single hub! Even the strip light controllers which do not work with the ‘normal’ milight binding will work with this new bridge and newer binding.

I would recommend this binding to be used and not this older method of using rules from this thread.

The rules method is still handy if you are wanting to use the milight remotes to control other things like volume control as the RF gets turned into MQTT and you can use this in any number of ways and does not need to be for Milight lights.

@matt1

Thanks for the quick reply.

The lights I’m considering are not globes, but outdoor fixtures. See link below - do you still think the above solution will work?

https://www.futlight.com/productlist.aspx?typeid=144

Yes they should work (insert usual disclaimer) as the light I just looked at from your link are listing they work with remotes FUT092 and FUT089. The milight protocol is 1 way only and the hub just emmulates the remotes so this is why I am pretty certain if they work with those remotes it will work with the hub and the binding. Buy 1 to try before buying in bulk.

@matt1

Thanks again for the info and the point to your binding. I’m curious where people purchase MiLights from?

I’m in the US and I see some on Amazon but I don’t see a US distributor.

Any suggestions?

hi guys

how do I make ESP8266 work with openhab

not many guides on the internet

You won’t drown if you jump in these waters. You must be bold and not expect a hand to be held all of the way. I’ve proven a few silly questions will be answered but also spent many days not getting anything to work but acculating a lot of knowledge. This makes it much more enjoyable when you light a light bulb or open the garage door.

Buy this or similar https://www.amazon.com/gp/product/B01IK9GEQG/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 and then google for project ideas. Here is one to start with - https://community.openhab.org/t/oh2-control-esp8266-relay-using-mqtt-eventbus/18127

Remember you can always start over.