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.
4 Likes
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.
3 Likes
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.
2 Likes
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 
2 Likes
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.
6 Likes
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.
2 Likes
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
1 Like
The Blues have a lot more capabilities than the gen2 Reds (500-series zwave). But the new gen3 Reds (800-series zwave) will have capabilities similar to the Blue and the driver settings pages will look very similar
Are you running the most current device handler from the Inovelli website (not the Hubitat built-in one)? Earlier versions had a couple of those parameters reversed
1 Like
I’m using the inovelli drivers not the Hubitat ones
1 Like
Are you using the most current Inovelli drivers? Earlier Inovelli drivers had them swapped
I believe so
1 Like
You showed the driver for the Blue Series. I was talking about the driver for the Red series since that’s where you said you found a bug
1 Like
