Looking for some bulbs OR a dimmer that will work with standard Spots (GU10?), the cheaper the better! Dimmable/RGB isn’t something I’ve explored yet, I’m used to Shellies/Sonoffs.
Requirements, must have:
Keep cost as low as possible
Dimmable
Warm white
Narrow beam angle
Capable of 500lm+ when white
Nice to have, not essential:
Physical switch
RGB
Current options/interfaces I could use:
Aeotec Z-Wave USB (never used, still in box)
Conbee II
ESPHome - Preferred option, love ESP stuff.
RFLink
Sonoff RF Bridge (modded and flashed with ESPHome)
I have an NRF24L01 that I’ve never used so could look at Milight or similar (this sort of setup or could solder it to the RFLink).
I haven’t explored MQTT yet either so would prefer not to go there at this stage.
UK based. It’s a room refurb so don’t yet have bulbs or switches, not sure what I want really, open to suggestions. As I’m wiring & plastering I do have the option to run a neutral to the switch position if the most favourable solution is a switch.
Looking for non-cloud solutions also which is something I forgot to mention on my first post.
I can describe for you Milight (with the ESPMH DIY link you mentioned in the first post; RFLink is not an option for Milight as it doesn’t have support for all bulbs and sometimes it does take a good 1 - 2 second for a command to reach the bulb for the ones that are supported):
non-cloud (although you can still use the Milight app on Android/iOS to control the lights as the ESPMH simply emulates the original Milight controller, I see no reason in using it and HA controls are enough);
cheap (bulbs and led controllers ~ 9-10 USD on Chinese sites; larger FUT105, E27 versions of 12W bulbs are among the top available options in terms of brightness);
can use multiple (up to 4 physical or virtual remotes IDs) to control a single light; as a light can be included in up to 4 groups it makes things very pleasant in terms of changing lights (turn off/on, change colors) because there isn’t any delay for the commands to reach individual lights with native lights groups (with groups of independent lights created inside HA it might take 2, even 3 seconds to reach them all; with Milight groups you can control a virtually infinite number of lights - obviously limited by available electric power - without any delay directly from HA); for example: all the lights in a room are controlled by a B0 remote and then each room is a group on a B4 remote and with commands sent from any of the two all the bulbs will change instantly;
although you can setup a hub, communication is not centralized and can use a physical remote (or multiple remotes) to control the lights and the lights are all in sync with HA regardless of the method used to control them (be it wall mounted/handheld physical remotes, ESPMH webpage, HA, Android/iOS app); this also means that, if there is a short power failure or (even if you have UPS) one that takes a significant amount of time and it knocks out the wifi router, HA or ESPMH itself, you can still use the physical remote to control the lights; I have in each room both a Xiaomi Zigbee switch which I use most of the time and, right beside it, a Milight wall mounted remote (which can dim, change color, color temperature) and there have been cases when I had to use the Milight remote; I’m not a big fan of touch remotes thus I installed also the more classic Zigbee switch;
is fully scalable as can be used with an infinite number of bulbs with the same ESPMH or physical remotes (if they are in the range) compared to ~256 for ESPHome (the maximum number of IPs available on the wifi router), Zigbee (~16 per node with cheap CC2531 but can use some powerful Texas Instruments controllers for larger nodes) or Z-wave;
if needed, can use a mesh network with another ESPMH to increase range or to improve rate of success for packets sent;
However:
there are different versions of protocols used by Milight and not all of them are compatible (needs quite some research);
communication is not encrypted (this is basically the reason you can use a physical remote to control the lights even if wifi router, HA or any other control software are down); depends how much you’re worried about privacy and security but the range of such devices is rather limited (below 10 meters; actually in order to control the lights effectively an attacker needs to be within 5-6 meters so it is probably the neighbor right beside you);
requires MQTT broker to be setup in HA; however, developer of ESPMH offers the auto discovery option which makes the things very easy to manage (although I have it on manual as I started on this path quite a long time ago )
GU10 have a design flaw (in my opinion) and, combined with the metal casing of the spots, sometimes packets from controller fail to reach the bulbs (haven’t got this problem with the other bulbs or led controllers) => success rate of packets sent to GU10 is ~ 97-98% while for the newer FUT89 compatible products (mainly E27 and led controllers) is around 99.999% (very, very high and easily comparable to Hue); even as such, I haven’t when controlling GU10 with physical remotes (only from a virtual hub);
the lights are stateless (the hub only sends the command and it is not interested in the state of individual bulbs/led controllers and thus can control an infinite number of lights without any delay in commands - that is if the lights are physically in the range).
There are basically 4 ways of interacting with Milight products:
official Milight hub (limited to 4 controllable groups); with every major version of HA the component seems to be broken; if you’re using physical remotes with the lights they won’t sync with HA; probably sends some data to Chinese govt. if enabled to be controlled from internet;
physical remote (handheld or wall mounted);
ESPMH you linked; most reliable and hassle free after setup (although the setup is not particularly difficult);
other solutions over NRF24L01 (RFLink, Raspberry Pi, etc.)
Very informative, thanks. GU10 may be a deal breaker though. When you say the lights are stateless, does ha/the esp assume it based on physical remote signals or commands from HA?
Basically, there are 2 main settings for HA to get back the state with the ESPMH MQTT devices (and none of them means that HA has actually received feedback from the lights):
include a state_topic (something like state_topic: 'milight_gw/state/0x1/rgb_cct/0' for ESPMH); in this case ESPMH receives the command from HA and sends back to HA the state (actually the assumed state considering the command successfully executed); however, this state is the result of ESPMH internal processing, not the result of polling the lights (i.e: ESPMH actually doesn’t talk to the bulb/led controller but only sends out commands); it is not possible to actually receive real time responses from the Milight devices as they are not sending any feedback (and this actually allows for controlling an infinite number of Milight devices as the hub doesn’t have to deal with feedback from each light; compared to best-in-class Hue hub, which is a monster of a hardware device that tracks each individual light, Milight is based on a quantity, not a quality centric approach);
set optimistic: true; even if state_topic from the above is included, the optimistic mode will override it (so HA will assume lights received the command and executed it successfully, even if HA did not received any reply whatsoever from the hub - namely ESPMH - not to mention the lights).
As a result, if ESPMH cannot effectively communicate with the lights (case the lights don’t have electrical power - i.e: being switched off from a physical switch - or they’re on a different RF channel than the hub and the command from hub doesn’t reach them), then HA will/might show an incorrect state for the lights.
Done a bit of reading and must admit I’m now starting to lean that way.
Couple questions:
I’m new to MQTT. Would the Milights using espMH have a smooth transition between brightnesses? Say, I want to automate a dimming from 100% to 30% over 5 seconds, how would that be dealt with?
I have 2.4Ghz woes. Smart meters with Zigbee that interfere with my wifi etc. How are the Milights with interference from wifi/Zigbee?
I do actually already have the bits to make an espMH and I’ve had some big ‘easyBulb’ downlights with remote for a few years but never really played with them. I do find that the easyBulbs are of very poor build quality though and flicker a lot. Mine are these.
Yes, it works pretty well and the longer the period over which it needs to be dimmed, the smoother the change will appear. Chris added support for the transitions too (without transition support you would need to do a lot of calculations in scripts/automations in order to get the correct timings to send new values to the lights).
See below examples of service calls:
#turn on to 30% (previously off) or dim from any brightness level to 30%
- service: light.turn_on
data:
entity_id: light.bedroom
brightness_pct: 30
transition: 5
#turn off (this service does not take brightness or other light properties but only transition, if specified); this would dim the light to 1 and then switch it off
- service: light.turn_off
data:
entity_id: light.bedroom
transition: 5
What I forgot to mention previously: Milight bulbs turn on with the last known values for color and brightness and this might be looked as either an advantage or a disadvantage if the lights are bright or too dim (for comparison, Hue can either use the last known value or turn on with a default value).
In my case, in order to turn light off I chose first to set the brightness level to 1 and then turn the light off (I don’t use transition from off to a specific brightness level but only between different levels when light is on). As a result, when light turns on again it is at brightness level 1 and it won’t result in a short blindness as if it would happen when turning the lights to full brightness in a dark room. Also, case there is a power failure during the night the lights will turn on to level 1 when power comes back on and the chances of waking up are lower vs. full brightness (or last known level before turning off).
I use 433 Mhz, Z-wave (868.42 Mhz - Europe), Zigbee, Milight, Wifi (both N and AX&AC with only the devices not capable of higher bandwidth kept on 2.4 Ghz; in addition, there are over 20 APs accessible from the neighbors in both 2.4 and 5 Ghz bands) and Bluetooth devices and I haven’t seen major issues with interference except one related to 433 Mhz devices that affect HD TV channels from a particular provider (macroblocks appear on screen for 1-2 seconds when 433 Mhz devices such as motion sensors or door sensors fire in close range, however I haven’t seen it with the other major providers in my country).
So… you have an Aeotec stick still in the box… how about using it with a z-wave dimmer and whatever spotlights you want. Seems like the best solution to me. You will find the widest range of lights available once you remove the need for them to be ‘smart’. Keep the smarts in the dimmer, you then have local control, even if HA is offline
There are RGB options for Z-wave lights, however they’re usually approx. 3x more expensive than Milight (haven’t found a GU10 version):
In the middle you can find Zigbee products which I find the most balanced regarding price&features (these ones from Gledopto are compatible with Hue but at a way lower price; also can be controlled with DIY Zigbee solutions such as Conbee or Zigbee2MQTT).
Just about to push the button on the Milight GU10’s. Noticed there’s some (what appear to be older, much longer form factor) 5W and some (newer?) 4W variants. Have you tried both? Which is best?
FUT106 is a newer bulb version (it is significantly brighter than FUT103 - 90 lm/W vs. 70 lm/W and it seems like a better design compared to FUT103 as it has a larger surface to dissipate the heat; on the other hand there are 2 additional Watts of heat to be dissipated).
Although I haven’t used it yet, from the compatibility sheet it appears to be compatible with newer remote protocol (FUT089).
I used that site and https://futlight.com/ for documentation purposes but I only purchased from Aliexpress (RO country code so they’re probably arriving faster in the UK ; anyway, recent deliveries from China took more than 2.5 months).
There are additional discussions on the ESPMH Github in regard of the compatibility between bulbs and remotes and the settings needed. You might also look into the FAQ for ensuring you will not be disappointed when the bulbs arrive (or otherwise go with Hue/Hue clones such as Gledopto or generic Zigbee; with Zigbee2MQTT you can also bind remote to bulb so that you can control lights even if every wifi/HA/Hue hub device is down - similar to Milight).
Getting to know their performance and compatibility issues will help you set a base point for the expectations. Milight are no match in regard of performance vs. Hue (average response time won’t let you integrate them into Ambilight like clones) however they’re a great cost/performance solution if set correctly.
For the gateway I use also these https://www.aliexpress.com/item/1859110962.html in order to stabilize power supply (or simply use a 4.7uF capacitor) as there are many NRF22L01 knockout clones and some very long Dupont connectors in order to prevent interferences. I use mine with an Asus 10,000 mAh passthrough power bank in order to not loose connectivity case of power failures. Once I removed, by mistake, the power cable from the power bank (it worked for 2 days just fine and would have probably worked even longer if I had not realized it ).
Still struggling to find info - getting into the nitty gritty now.
Been on the Chris Mullins blog and have a couple questions:
The NRF24L01 is not as ‘performant’ as the LT8900 but Chris states in the comments of his blog that mist users are better off with the NRF, though he doesn’t state why. Any ideas?
Just out of curiosity, why do you need power to the hub when the mains is off?
I gather the hub can now emulate the ‘official’ Milight gateway and so can use HA’s LimitlessLED integration instead of MQTT. What’s the pros and cons of each?
)