this is an information / learning on milight. I have 100 downlights in 4 zones controlled by two bridges (because of the distance).
If you send a ON/OFF (probably true for all commands) to multiple bridges at the same time (i.e. a rule switches off two zones) then please be prepared for some RF interference.
The bridge listens on UDP as this is not blocking the binding sends the UDP packet to the 2nd bridge so fast after the first one that in comparison with the very low RF baudrate they collide in RF resulting in all types of weird situations. some downlights not swiched off, another zone goes down as well, 50% brigthness etc… repeating the commands will not help here.
To reliably shutdown there must be a break of 2 seconds (for my installation) between speaking to two bridges and I also think between speaking to two zones on the same bridge(!). this is no issue in a rule file where a simply Thread::sleep will do this but stuff like restoreOnStartup or the restore function of saved HashMaps will not take care of this. As the bridge will never speak back to the sender there is no handshaking possible. it’s fire and forget.
Bottom line: speak very slowly to many milights. smaller quantity of fixtures will help as well (I don’t know why, maybe they interfere RF wise to each other when they have to “work”). and creating a wireline ethernet bridge out of the crappy wifi bridge will help too (this is not too hard to do and highly recommended).
This is a Chinese product. The company is futlight and they sell a 12W CW/WW downlight for around 20$ (yes they ship directly from the company, don’t but these here in Europe - too expensive). Don’t expect the usability of a Hue fixture. It’s just not “there”. the 2.4GHz label in combination with the wifi says it all: it’s by no means a wifi controlled lamp. yes the carrier is 2.4 Ghz but the RF protocol is so primitive and lean and one-way only that such issues will pop up.