Here is my vote:
We have 7 LED’s
Set parameter to timer, then turn on
After 1/7 of the time, the topmost LED goes dark/off.
After 2/7 of the time, the next topmost LED goes dark/off.
At 6/7 of the time, the last LED starts blinking once every second indicating the timer is nearing completion (this is how my dumb timer works in the bathroom).
After 7/7 of the time, switch goes off.
Nice, I like that. I’ll see if we can get it implemented.
You can’t just pull an aqara/tuya and violate the protocol for this it’s only for the devices that are affected? Sengled has their mains powered bulbs act as end devices when in reality they should be repeaters for example.
Is Sengled the best example for following zigbee protocol?
What if that topmost LED flashes at a determined pace to differentiate it from the led bar just looking like it’s dimmed down?
That was the point… it’s not impossible it’s already being done?
This wouldn’t actually destroy anything to force a mains powered devices to be an end device (unless it would damage something? It would be isolated to specific devices (those with bad IEEE addresses).
If it would somehow damage communication between the switch and coordinator or the mesh then that’s a reason not to do this of course. But if it’s already being done is that really a possibility?
Without this meshes are degraded if devices don’t have the latest stacks which route through only those with good connections vs the nearest repeater. Devices with the latest stacks wouldn’t even bother using the switches to route traffic because their connections are horrible at best. Most devices don’t get updates so there’s a lot of devices out there that would definitely use the switches to route traffic.
The question stems to is Sengled following zigbee specifications? Just because they are doing it doesn’t mean it conforms to the specifications of Zigbee Connectivity Standards.
I don’t know if it would be possible to restrict the firmware to certain IEEE addresses, but even if something is ‘technically’ feasible, knowing that it violates the protocol alone should make it a non-starter for a company’s official firmware. These devices are also being RMA’d and replaced for free, so that’s the real ‘fix’ for the affected switches.
Latest z2m and 2.08 firmware from HA logs:
Exception in handle_state_message_received when handling msg on 'zigbee2mqtt/Inovelli Blue Office Switch': '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":70,"buttonDelay":null,"defaultLed1ColorWhenOff":null,"defaultLed1ColorWhenOn":null,"defaultLed1IntensityWhenOff":null,"defaultLed1IntensityWhenOn":null,"defaultLed2ColorWhenOff":null,"defaultLed2ColorWhenOn":null,"defaultLed2IntensityWhenOff":null,"defaultLed2IntensityWhenOn":null,"defaultLed3ColorWhenOff":null,"defaultLed3ColorWhenOn":null,"defaultLed3IntensityWhenOff":null,"defaultLed3IntensityWhenOn":null,"defaultLed4ColorWhenOff":null,"defaultLed4ColorWhenOn":null,"defaultLed4IntensityWhenOff":null,"defaultLed4IntensityWhenOn":null,"defaultLed5ColorWhenOff":null,"defaultLed5ColorWhenOn":null,"defaultLed5IntensityWhenOff":null,"defaultLed5IntensityWhenOn":null,"defaultLed6ColorWhenOff":null,"defaultLed6ColorWhenOn":null,"defaultLed6IntensityWhenOff":null,"defaultLed6IntensityWhenOn":null,"defaultLed7ColorWhenOff":null,"defaultLed7ColorWhenOn":null,"defaultLed7IntensityWhenOff":null,"defaultLed7IntensityWhenOn":null,"defaultLevelLocal":null,"defaultLevelRemote":null,"dimmingSpeedDownLocal":null,"dimmingSpeedDownRemote":null,"dimmingSpeedUpLocal":null,"dimmingSpeedUpRemote":null,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.77,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"last_seen":"2022-12-07T12:52:12-06:00","ledColorWhenOff":null,"ledColorWhenOn":null,"ledIntensityWhenOff":null,"ledIntensityWhenOn":null,"linkquality":25,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":null,"periodicPowerAndEnergyReports":null,"power":8.2,"powerType":null,"rampRateOffToOnLocal":null,"rampRateOffToOnRemote":null,"rampRateOnToOffLocal":null,"rampRateOnToOffRemote":null,"relayClick":null,"remoteProtection":null,"smartBulbMode":"Smart Bulb Mode","state":"OFF","stateAfterPowerRestored":null,"switchType":"Single Pole","update":{"installed_version":"2.08","state":"idle"},"update_available":null}' Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py", line 44, in wrapper msg_callback(msg) File "/usr/src/homeassistant/homeassistant/components/mqtt/update.py", line 191, in handle_state_message_received if "installed_version" in json_payload: TypeError: argument of type 'float' is not iterable
12:52:25 PM – (ERROR) util/logging.py - message first occurred at December 5, 2022 at 6:34:44 PM and shows up 3738 times
Invalid option for select.inovelli_blue_office_switch_switchtype: '0' (valid options: ['Single Pole', '3-Way Dumb Switch', '3-Way Aux Switch'])
12:48:51 PM – (ERROR) MQTT - message first occurred at December 5, 2022 at 6:34:44 PM and shows up 7410 times
The TypeError: argument of type 'float' is not iterable error is fixed by this pull request, which is already merged and should be in the next release.
I resolved the invalid option errors I had in my logs by just opening zigbee2mqtt and setting those parameters to the intended value. I suspect they came from a lack of migration between versions of the zigbee2mqtt inovelli converter, but I haven’t looked into how that works yet.
Wanted to flag this firmware bug, just to confirm it is being captured.
It looks like in ZHA, when you upgrade the firmware, it doesn’t look for the updated “quirk” which helps with some of the compatibility. Fortunately, it’s easy to solve.
And I even made a youtube video if some people prefer that.
I’ve finally managed to install my first Blue test device, and was initially able to setup the binding no problem. After firmware updating, and doing the remove/re-add dance as documented above, the device no longer shows the ability to set up a binding on “LevelControl” for Endpoint 1 - only endpoint 2.
Is this a known issue on firmware 2.08 with ZHA?
For firmware 2.08 and beyond, you should be binding from EP2 to EP1 of the group/device being bound to in ZHA. So less ‘known issue’ and more working as intended 
Seasons Greetings folks!
Now that I’m deep into blue series fun I have a small firmware suggestion. I’d like to see a gamma correction feature. This would be a bit different than a simple min/max range but instead specify what shape the curve takes from that min to max. The use case is to “calibrate” LED bulbs which behave quite a bit differently to halogen bulbs as far as their intensity curve. What I would love to see are two parameters or perhaps the equivalent merged into one: shape and value. The shape could be inverse square, exponential, logarithmic, s-curve, linear (default), etc. and the value would be the “steepness” or aggressiveness of the curve shape. What this would do is help stretch the range of low or high values depending on the light being driven. Many LED bulbs struggle with the top end of their range showing little difference though at the bottom end you get lots of little granular steps. Some bulbs behave the opposite of this. Still others struggle near min and max but in the middle feature a really nice dimming range.
This is all about matching dimmer to bulb. Right now I do something like this for some of my lights driven through HA. Hubitat doesn’t really expose enough customization to the average user without writing a driver. I could see how this could be implemented in the driver instead of the dimmer’s firmware but I expect that quantization would be limited by 0-100 available values and the dimmer itself could implement this with 8/16/32… bits of quantization resulting in much smoother dimming function.
ZigBee, unlike z-wave, uses 0-254 for light levels (0xFF is reserved, IIRC), so assuming your driver got down to the level of zigbee commands, you’d have 8 bits of quantization, which is noticeably better than 0-100.
If we were to take your proposal to the next level, if the parameter exists, then someone could write a “calibration” program to run in a hub, using a luminosity sensor, kind of like the way surround sound speakers use a test tone to tune themselves. That sounds like it would require a lot of research and work for a relatively small gain, but it sure would be cool. Maybe someone would do it as a labor of love.
I would second this request. For my LEDs I see very little dimming until I get down to around 10%. Are there LEDs that work better with the blues? Can anyone recommend a brand?
Best performance is going to be with zigbee bulbs that actually dim 1%-100%. Controlling load on LED’s is exceedingly difficult on such low-wattage bulbs across the board. 0-6W is so much harder for precise control than 0-60W.
This is a good suggestion and what I have my Blue controlling but I will say I have some other Lutron setups that dim very low with these newer “Filament” led bulbs. My guess was those have more emitters in series and are less effected but could just be anecdotal.
I have a room with two sets of overhead lights, one controlled with a Blue Series and the other controlled by a Red Series. I’m using Hubitat btw
I’m mostly concerned with how the light turns on/off and dims at the local switch.
The switches are next to each other, so I want them to behave the same.
After messing around for a while I was able to get it.
Is there any reason the driver settings pages can’t be more similar between the two types of switches?
I also noticed the min level between the switches are 10 vs 35 but operate exactly the same.
I also might have found a bug with the red series regarding setting dimmer level command and dimming down with the local button - but I’ll bump the red series thread about that.
Here are my Red Series settings
Blue Series Settings
