If Saturation < myThreshold then White else Colour.
i.e if the saturation is BELOW a certain threshold then it should trigger white.
This is the centre of the circle on the non-mobile sitemap colour wheel.
I attempted to select the center of the circle a few times. Most of the time I got a saturation level of 4-7 but a few times it was as high as 11. So in my testing any saturation level <12 should result in white.
However, I vote for making this an opt-in feature and so a default of -1 (i.e feature disabled) make sense to me. This would also keep consistency with the 1%=night mode feature which is also disabled by default.
Also - @matt1 thanks for your openness to suggestions and continued efforts with this binding!
Build 08-03-2018 available as beta at the normal link, but this time contained in separate sub folder.
New feature added for RGBW globes only. Parameter is called RGBW_WHITEMODE_SAT_THRESHOLD since I dont have the globes I need someone to test it for me, possible it wont trigger but it should. -1 disables it and is the default, values 0 to 99 are valid.
Better code written that fetches any changes made with a remote whilst the openhab to MQTT connection is down. Spent a lot of time pulling out my network plugs to break the connection and testing everything works as it should when cables get plugged back in. So far is rock solid for >24 hours on my setup.
Less logging in debug to speed up the binding as it is no longer needed in well tested areas of the code.
Improvements to the message reduction feature called DELAY_BETWEEN_MQTT. The IOS app can send 41 messages per second when swiping your finger around the colorpicker which floods the esp8266 with commands faster than the hub can transmit to the globes.
bug fix for message reduction feature added after testing at faster speeds.
I found last week that by setting the “packet_repeats” to 70 or below a big jump in speed for rgb_cct globes could be achieved. RGBW globes seem to be not effected to the same extent possibly due to them not using scrambling on the RF packets. This “packet_repeats” setting is in the esp8266 control panel and is not a binding setting. The setting is how many times the openhab command is blasted out to the globe before the next openhab command is processed by the esp8266 and nrf radio. Globes a long way from the hub (or through multiple walls) can benefit from raising the packet repeats if using a nrf board with internal antenna and no PA+LNA feature. Going to test different nrf2401 radio designs to find which one performs the best so the packet repeats can be lowered for more speed.
The idea is by using a more powerful nrf radio with PA+LNA and external antenna the “packet_repeats” can be lowered and hence I can lower the “DELAY_BETWEEN_MQTT” setting in the binding. I wanted to finish testing the binding with the cheap internal antenna boards before moving onto this.
When trying different chinese sourced NRF boards, the versions with PA+LNA use a LOT more power than boards without the PA+LNA features, really not surprising. What did surprise me was the chinese made LoLin nodemcu V3 board I am using can not power some of them at all. When trying to get them running the thing to look out for is the LED on the esp8266 sub board. If you press the reset button on the nodeMCU you will notice a small LED flashes. When you try and transmit this LED flashes about 6 seconds later showing the board has reset due to too much power getting drawn and the voltage sags low enough to cause a reset. Using capacitors did not solve this so my conclusion is the PCB traces on some (not all factories make them to the same quality level) nodemcu boards can not supply enough 5V power. I ruled out the USB cable and power supply as they power a PI2 without causing the rainbow icon that cheaper leads do. Raspberry Pis are very fussy on power so the test setup is very reliable.
The only one I could get running was the shielded metal cover version after first installing large capacitors on Vin and Vout and also running wire back further on the nodemcu board to grab power before it runs down the PCB traces. I now have reliable transmission to an entire house of globes from a single hub and can drop the packet_repeats down to a value of 8 which speeds things up. If my calcs are correct it now takes 23ms to transmit a state to a globe. So all 23 milight globes in my house are now changing in around 1 second all from the one hub, very cool.
Recommendations from what I found:
Use a 5v power supply and feed 5v directly to the nodemcu (or other esp8266 board like D1 mini) PLUS send power directly to the nrf base PCB so the radios get good solid power directly and not through the nodemcu or D1 mini board.
Solder on a 25uf solid tantulum cap (or any electrolytic between 25 to 100uf will also be fine just larger in size) on the Vout of the nrf base if using the base (see pic at bottom of this post) to connect your NRF boards with. The next post also shows where to solder directly to the nrf boards.
Consider using better branded nodemcu boards from reputable suppliers as they may use thicker copper on the PCB making the previous steps un-necessary. I found the D1 mini gave more power as the tracks were shorter so if you can not solder I would use these as a base.
NRF24L01 is one of the commonly faked IC’s. If you are paying less than $5 for the board the odds are it will be a fake IC. These IC’s do work but are known to draw a LOT more power than a genuine nrf24l01+ chip. All of my boards are pretty much going to be fakes as the printing on the IC is almost impossible to read. I ordered a number of the basic internal antenna boards from numerous chinese suppliers and some use a lot more power than other boards which appear to look the same. Adding capacitors did get them working so they were not faulty just power hungry from being a worse fake compared to the other better faked chips.
If you do not need a 1km range then consider this board which I have not tried personally. It appears to not have PA+LNA features so will use less power and is more likely to have a genuine nrf IC. Both of these things will mean less power draw and will make connecting it directly to a nodemcu board much more likely to work first go without adding extra capacitors. Sadly there is no way to use it without soldering wires or header pins to the board. Cost is higher when you add the antenna to the board. https://www.sparkfun.com/products/705
Do not believe any chest beating claims of 1km or 2.5km ranges when choosing which board to use. See this link for what is commonly known as “the ugly fix”. https://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/
But why do that when ready made shielded boards already exist? Search for E01-ML01DP5 as they can be purchased for around $5 with the antenna included and this is the board I have settled to use.
The esp8266milighthub project defaults to using the full power of any extra on board amps. If you turn the power down which is now a feature in the hubs firmware it could/will reduce the power rail sag and improve comms. By turning down the transmit power you could very well get better range if you have not soldered on caps.
Users on the web are reporting that separating the esp8266 from the nrf board with longer wires gives better results. My limited tests seem to confirm this as I have built some very compact units similar to the ones in the next post by @furax54 which do not perform as good as my prototype which has 4" (100mm) of push on style wires between the two boards.
The boards and the base I have tried are shown in this picture.
Actually I’m using E01-ML01DP5 with quite good result also with GU10 bulbs. A good thing is to solder wire and NOT using breadboard. With exactly same hardware, result are far better (especially with GU10). Wemos D1 mini (last rev) for me, another AMS1117 3.3V and 100uF near NRF Board. I can decrease packet repeat to 15 (with breadboard I have to set it to 50 !)
@matt1 : can you give me more detail about color temperature ? What is the range ? in es firmware , it’s between 0-100 but in config by default you set FAVOURITE_WHITE to 200.
If you go into paperui and try and change the settings it guides you on what the range can be. Off top of my head it is 153 to 370? And it is this because the globes use this format. Sniff a remote or watch the mqtt replies from the hub, they all use this number. By watching the logs or mqtt you can find the colour u prefer and see the number to enter in.
Edit: only rgbcct and cct globes can use this feature. The binding should send the whitemode command for the other types. If u only have rgbw globes ignore the feature.
Fixed a bug that was very rare that would stop all outgoing mqtt commands when you increase the speed of the binding by lowering the DELAY_BETWEEN_MQTT setting. Most likely in all versions since 1-3-2018. I’m using 25ms for DELAY_BETWEEN_MQTT and packet_repeats of 8 in the esp8266 control panel.
Adjusted debug output to have less info.
Tip:
Multiply 2.8 by your packet-repeat value (rough figure of how long it takes to transit to the globe with current firmware) and start trying the DELAY_BETWEEN_MQTT at around that figure. Interested to hear feedback from anyone with how many globes they have and what settings work for them.
My setup is 18 RGB_CCT globes and 5 CCT for a total of 23 globes currently in use and I have a few more yet to setup. Now I have all the globes changing states in 1-2 seconds and very reliable with full control over each one via voice control.
Installed the lastest version without issues. I didn’t play with DELAY_BETWEEN_MQTT and packet_repeats because you said RGBW globes seem to not be affected and this is all I got.
And I’m lucky with my hardware, all seem to work pretty well… crossed finger
I said not to the same extent. The more times the hub sends out a command to the same globe the longer it takes before it begin sending a change to the next globe, if you have more than a few globes in the same room then having a big delay will be seen. Rgbw globes have a shorter rf packet and no encryption so I think they are 50% faster than the newer globes.
By using mqtt and speaking directly to the globes I would not be surprised if a lot more is possible with this setup compared to an ibox milight hub. I don’t have any real hubs to compare to.
Multiple globes: Try and get DELAY_BETWEEN_MQTT low as possible and packet-repeats also low or globes don’t change all at once.
If you like fast colour changes for a disco: Try and get DELAY_BETWEEN_MQTT low as possible and low packet_repeats.
Only a few globes and you like to swipe around a colorpicker: Then a higher DELAY_BETWEEN_MQTT will reduce the changes when you swipe around. If the commands are backing up then a low packet_repeats with a high DELAY_BETWEEN_MQTT will be preferred.
You can really fine tune how it works with playing with the settings.
Hey guys, thanks for all your effort to make this awesome project! I’m currently trying to set up the OH2 binding. I’m a bit confused about the currently newest zip file, dated 2018-03-12. This zip file contains only one jar file, whereas older zip files contain two jar files and also instructions mention two jar files. Could someone please quickly clarify if only one or two jar files are needed? Thanks a lot! Regards, d.
When I tested this last build I found it worked for me with only the one JAR as the second jar is actually packaged into the JAR already. A jar is like a zip file. Try it with only the one and if it does not work use the second jar from any of the other zip files. Let me know so I can clear up the confusing documentation or include the jar. Eventually I should be able to get it working as a single jar, just still learning and have limited time.
When I tested this last build I found it worked for me with only the one JAR as the second jar is actually packaged into the JAR already.
I can confirm, it works with only the one JAR file.
For others as an information: My MQTT broker was set up with anonymous access. I could not get the binding to work with anonymous MQTT access. openhab.log showed some NullPointer Exceptions. After enabling username/passwords on MQTT broker, the binding started to work.
There is one more confusion: I’m using the FUT089 remote (this is the 8 channel remote). The connected bulbs are rgb_cct types. Items in OH2 are set up as rgb_cct types, commands are sent to ESP and get executed correctly. What confuses me: When using the remote, ESP will broadcast on MQTT topic milight/states/0x66CA/fut089/2. It uses fut089 as device_type instead of rgb_cct. Therefore, Openhab does not update the item’s state. I assume it is expecting the topic milight/states/0x66CA/rgb_cct/2. I might be able to work around this by setting up a MQTT bridge and forward the messages to the rgb_cct topic. But I might be missing something here, so if anyone has a hint for me, would be much appreciated! Thanks!
I am using this binding successfully with an MQTT broker, (mosquitto), configured for anonymous access. Therefore I’m not sure why you were having trouble but it is possible to get it to work without a username and password.
Any npe errors are bugs so please report if you are using the very latest build. Describe how to reproduce so I can fix thanks.
Your correct about the remote needing to be rgb_cct for it to update openhab but not sure if this is correct behaviour of the hubs firmware or not. If the binding sends the correct command the. The hub should respond with the state in the same format. Not sure about remotes thou as mine stays on rgb_cct can you confirm what what hub firmware you have and if you linked the globe as a rgb_cct type?
It might be worth posting a question if this is a issue at the hubs github site. They may say that is how it is meant to work or it is a bug. They are doing work on beta releases the past week so will be quick to respond.
2018-03-16 21:36:49.562 [INFO ] [b.handler.EspMilightHubBridgeHandler] - MQTT sucessfully connected
2018-03-16 21:36:49.556 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler@253f7ed6': null
java.lang.NullPointerException: null
at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.connectMQTT(EspMilightHubBridgeHandler.java:332) [206:org.openhab.binding.espmilighthub:2.3.0.201803120939]
at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.initialize(EspMilightHubBridgeHandler.java:488) [206:org.openhab.binding.espmilighthub:2.3.0.201803120939]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.b1]
<snip>
After enabling MQTT password on Mosquitto and adding user/password to the bridge config, everything works fine. So for me the issue is resolved.
As additional information, Openhab and Mosquitto both are running as docker containers on the same host.
About my other issue, I will try later to update to the newest ESP firmware and check, if it makes a difference. Just for clarification: Basically, the item states in Openhab are supposed to update automatically if everything works as intended, correct? No need to setup additional rules to keep the states in sync, right?
EDIT: Please disregard my last question. I have just setup Mosquitto to bridge the messages from device type “fut089” to “rgb_cct” and I see now states updating in Openhab. Cool!
The more I think of it the more I am sure the 8 channel remote should work that way. Do you know if that remote only works on rgbcct or can it do the older globes as well?
Have to look into a add support into the binding if that is the case but u have a work around till it is done.
Tested and working. Thanks!
