I actually think it’s directly related to Thread network complexity and signal reliability @EricM_Inovelli. Having read a number of forum threads with the people complaining about the flickering, it’s folks who seem to be using a lot of the switches (as I am) or who have some kind of challenging signal issue. For example, before you released the radio power improvements with the recent firmware versions, I was seeing at least 2x more flickering than I am today, but only on some of the switches (the ones that required a challenging signal path jump). Now it’s more uniform, with flickering all over the house at random, but again easily reproducible if I reboot the entire Matter network.
Will also say that I don’t believe this is a bulb issue (Philips bulbs everywhere, except some expensive GU10s that are made by a company called LTF). And everybody notices the flickering – we’re talking full off-on cycle that’s long enough that everybody comments on it (like “uh oh, power going out?”), not just an LED strobe sensitivity or similar.
Should also say, we are a full neutral wire deployment across all 80+ switches, and the switches exhibiting the problem have nothing special about their power sources – just an LED bulb on the load side, typical residential circuit breaker. And I’m running the latest Matter add-on in Home Assistant as the server.
There is a pretty simple solution for this issue if you are using Home Assistant.
In Home Assistant, whenever you set the notification LED by an automation, start the automation with a “Scene Create” action to capture and store the current state of the notification LED, and then restore that state on exit from the notification.
For example, I use the notification LEDs to indicate if certain doors are locked or unlocked. When setting those LEDs, the automation follows the pattern …
If door is unlocked
Then “Scene Create” to capture current state of notification LEDs I want to change
Then change the notification LEDs
Then wait until the door is locked again.
Then “Scene Activate” to restore the captured state to what it was before the automation.
This works well if you only have one notification that can trigger a change in the notification LED state (or as long as there isn’t a race condition where different automations can capture the state and restore it out-of-sequence). For me, this techique solves 95% of cases where I want to change the LEDs and then restore them to what they were before.
@jvm33 I know how to get HA to make my house and leds do just about anything.
I thought this was a bug / enhancement thread.
Regardless of all the things I “could” do it still doesn’t turn off the led at night, I can’t change the default load color or its brightness and instead have to hijack the notification LED and manage all state changes through programs and scenes to do what a parameter already does?
Anyway, thanks for taking the time to document a potential way to manage some pieces of this issue, but I’d like to reiterate that having access to the ability to change the led brightness for the load (and color) as a parameter change would be an extremely useful feature say compared to the ability to change the switch from leading to trailing dimming that’s likely set once and never changed again.
@jvm33 Good point, and I may have unintentionally done that yesterday before seeing your message. I wrote several scenes a large script in HA to send various notifications to the switches (severe weather alerts, grid outage, water leak, package detected, thermostat turned off, etc.). One of them is for the alarm system being armed and it just so happens I have other automations that auto-arm at 10 PM and disarm at 7 AM so it is just a matter of finding a good color.
Fair point, I was only pointing out a way of handling in the meantime.
There are two sub-points to this.
I’m 99% sure that many of the configurations you are looking for are already exposed by the device through a Custom Cluster (0x00122ffc31) found on Endpoint 1. What needs to be done is this custom cluster has to be added to the Home Assistant Python Matter Server Code, and then to the Home Assistant Matter Integration. The task here for Inovelli is to fully document this custom cluster so this work on the Home Assistant side can be done.
Many of the features could also be expressed through Matter-standardized “Mode Select” endpoints - this would be preferred, particularly for “pick one of the following choices” type items as using Mode Select is already supported in HA and no further customization of HA is required. This does require firmware changes to the VTM31 (and I think some are being considered). The complexity here is there are problems with Google Home non-support of the feature (it makes a mess of the UI in Google Home), which limits how a vendor can use this feature.
Possible bug: The Inovelli White dimmer switch in “dumb bulb” mode doesn’t support transitions when starting from 0 brightness.
I’ve set up several scenes that are a mix of smart light bulbs and Inovelli White dimmer switches in “dumb bulb” mode. When setting the scene from Node Red (see attached image) the transition value is not respected for the switch when starting from 0 brightness, but IS respected when starting from any brightness >=1.(The transition value is respected by all of my smart bulbs regardless of the starting brightness of the bulb.)
The same thing occurs when using light.turn_on directly with the single switch, rather than turning on a scene.
I’ve experimented with setting the brightness on to 1 before setting the scene with a transition, and it works, but it feels like a lot of extra steps across all of my scenes.
Is this a bug? Has anyone gotten transitions to work from brightness=0 (ie, off)?
The Matter standard requires that Level Control values for lighting devices be between 1 and 254, so if the level control cluster is showing a 0, that’s the bug. For lighting devices, sending a 0 level should result in the on off cluster being set to off.
This behavior is specific to lighting devices. The level control cluster can be set to 0 for other device types. There is a specific feature flag on the level control cluster that indicates to the controller that the device has this behavior.
Also, I think setting 0 causes the device to capture the current level as a Global Scene and any later turning of the device back on through the on/off cluster recalls that last scene. I think this is all carry-over behavior from Zigbee.
This is a long and perhaps overly detailed way of saying you should not be starting any light transitions from 0!
This is from memory, but 99% sure I have it correct here.
FWIW, I also had this thought and tried it. Even at 1%, the light is still fairly bright compared to actually off. I ended up just manually setting my bedroom switches to LED brightness off = 0. It means my switches don’t have the dimmer light when off during the day, but it’s not a huge deal.
If Inovelli / HA ever gets that param properly exposed then I’ll go back and automate it so it changes with day / night.
how can we get inovelli to publish this stuff so someone on the HA front can work on this? Seems like something that should get done to support the matter/thread ecosystem… It seems it’s a chicken and egg game with matter/thread. Someone has to take the extra steps to push, help and co-develop.
@EricM_Inovelli do you have any other updates or info from the engineers on the issue with the load flickering during storage R/W? This is driving us insane.
EDIT: Follow-up to that – I believe a contributing factor to this problem in my case is that there are still some switches that have a weak enough signal to the next hop that it causes rolling network outages routinely. E.g., if one node fails, and it happens to have been selected as a router for others, then it’s going to cause a chain reaction of nodes that get kicked offline. This causes a lot of send/receive all over the place, which then further loads the network and causes other nodes to potentially fail their keepalives. I’m going to request again that you put some kind of transceiver power configuration on the switch so I can do some tweaking on the switches that are some of the known problem areas and see if that alleviates the issue.
Related question on this: is there any reason that the transceiver power is set to what it is (typical Thread device specs for the use case, industry standards, etc.), or is it sort of a finger-in-the-air guess?
The CSA also announced a new FastTrack Recertification Program and a Portfolio Certification Program that lets companies certify multiple products more efficiently. A complaint I’ve heard frequently from smart home companies is that getting devices certified and recertified by Matter when they make a change or an update is a laborious and expensive process that slows down their development work. The CSA says these two new programs simplify both processes and make them less costly and complicated.
Add the ability to disable the “Clear Notification via 2x Tap of Config/Favorites Button” feature for implementations that are using the LED bar (via an automation) to designate status. This feature is already available (param 262) on the blue switches. The current default for this feature is “on” and there is no way to disable it.
I’d suggest that the better mechanism to detect the double-tap at your hub and then for the hub to clear the notification. That ensures that your hub has the understanding and and control of the device’s current state.
The issue that I’ve seen is the other way around. I don’t want the LED color (notification) to be automatically cleared. I’m using multi tap on the config button to control fan speed. I’m also setting a color on the LED bar to designate that the fan is running. With single tap, triple tap and hold I can have the HA automation just change the fan speed once the color has been set once. In the case of double tap the LED color is reset to default. I can work around this by just having HA set the LED bar color a second time after the automation which works fine. However it would be desirable to have all of the config taps work the same way. In the case of the blue (and I think red) switches there is an option to disable this behavior. What I’m asking for is the exact same option to be added to the white switches.
I have a large commercial thread network covering 25k sqft with about 200 REED’s.
I have Inovelli White series all over this place. They work great. I talked to Eric some point recently about some problems we had with firmware updates but after further investigation on my side, I was able to isolate that problem to my Nanoleaf bulbs (ultimately they were breaking the mesh). Ever since I ditched Nanoleaf, the overall firmware, responsiveness, and uptime has been flawless. This is a commercial grade product, great job Inovelli team.
But something interesting is happening. I only bring this up because it sounds like a problem others may face as well…I have exactly ONE switch in this office that is exhibiting some kind of flickering behavior similar to the flickers others have reported.
Coincidentally, this problematic install is EXACTLY in the center of my commercial office (in the kitchen) where the Thread density and coverage is very good. I’m absolutely certain this issue (in our case) has nothing to do with the radios and it hardly correlates with anything real happening on the software side of things.
One day we came into the office to find the breaker for this switch had fallen into some weird state where it wasn’t “on” but it also wasn’t “tripped” either. The kind of thing that makes you say “this breaker might be bad.”
So our current suspicion is that the breaker is our problem. That being said, the flickers never seem to coincide with any downtime or unavailability on the network. By all means, it appears from the logbook that the switch has constant and stable power. Like I said, the uptime has been flawless ever since the Nanoleaf REED’s were decommissioned from my fabric.
We’ll probably replace our breaker (and then replace the switch if it continues) at some point, but currently we’re still busy finishing up the installation and commissioning of our remaining Thread nodes. The flicker is hardly something people notice…even when they are in the kitchen when it happens.
I had same issues with Nanoleaf until I got the on the latest firmware which took 2 hops. After that no problems but these are thread bulbs. Have you checked the wiring at the switch? I had one flicker and it was the termination at the switch. It is easy to accidentally push the wire behind the screw instead of under as sometimes they come screwed in slightly from factory. Normally that squishy breaker is a gfi or afi breaker trip and they will sit middle and have to be flipped off and then on.
