Good news. . . though also a bit strange.
Everything just started working normally. Out of the blue. Perhaps it was one of the settings we tried and by setting them and unsetting them a few times we “jostled something loose”. . . but I can now use the aux switches to dim the lights again. And I can’t make the issue return even when I now match all settings to the screenshots provided above.
Thanks again for bearing with me on this. I guess it’s resolved. I’ll post again if it returns
Forgot to come back and let you know but turning off adaptive lighting fixed the issue with the lights coming on. Thanks!!
@EricM_Inovelli I updated a few switches to 1.1.5 and noticed I lost the TX Power setting (at least in Home Assistant) that was present in 1.1.2. Did that get removed?
@philip Yes, that option was added to do some testing of various tx power settings but was removed for the production firmware.
Bummer! That was a really highly desired feature by me. Is there any chance that can come back in some form? I have switches that are in a bad spot and really need a power boost on each end of the chain to consistently establish connections.
I’m running a pretty big Thread mesh — right at 184 devices — and I’m seeing a very high level of instability since the 1.1.5 update. My new best friend, Claude, and I have been reviewing OTBR and Matter logs, and it seems that the frequent mass device unavailability events I’m seeing daily now are related to CASE session failures triggering at state 4, mid-session-establishment, where the device stops responding partway through the CASE handshake. The failures seem to be seeded by 1-6 specific devices at a time, then cascade to 30-50 devices within minutes, and pretty soon the whole thing is down. This has happened 4 times today at roughly 2-3 hour intervals.
I was chasing a separate issue with OTBR that complicated the diagnosis — a file descriptor leak in otbr-agent stemming from what I guess is a known bug introduced in HAOS 16, where the Docker container FD soft limit was dropped to 1024. I believe the leak itself is in otPlatInfraIfHasAddress() and accumulates at roughly 7-25 FDs/hour per border router. I’ve mitigated it with aprlimit command but it’s not a permanent fix. That issue is separate, I think, and I’m reasonably confident it’s not what’s driving the cascades. I’m seeing the same CASE session storm pattern on days where FD counts seem healthy.
Environment: HA Yellow (primary, OTBR, Python Matter Server) + 2x HA Green (pure OTBRs), HAOS 17.1, OTBR add-on v2.16.5, Thread channel 15, ~32 Thread routers in mesh, mostly White Series 2-1 dimmers with a handful of fan switches and 3 fan modules.
When it is up and running - I’ll have all 184 devices up and seemingly rock-solid, then it all folds at once. It rebuilds in under an hour, but this crashing behavior is making me feel a little crazy go nuts.
That sound familiar to anyone? Is this being addressed?
I have about the same size network with a lot of inovelli devices. All are on 1.1.5 and I don’t see that behavior at all. python matter server had a lot of CASE errors. now I use my apple thread network with HA instead of OTBR. Have you considered the matter-js matter server instead of python. When I used to get cascading failures like that it was because my wifi routers were moving channels and would clobber the thread network channel. you are on channel 15, which is close to wifi ch6. I know if this used to work that seems unlikely, but any other changes while solving the OTBR problem? Did you change the channel?
My WiFi is set to channels 1 and 11 I believe but it’s been awhile since i have looked at it. I will double check. How many border routers are you utilizing? My perception is that the matter server I’m running now is the “best” one for HA and best supported, but I haven’t really investigated a change there. I’ll look into matter js. Would making the switch require reprovisioning / pairing devices? Thanks!
Oh I understand RE matter server. I am going to flip the beta toggle and run js as you suggested. Not sure how I missed that. I’ll report back.
That definitely seems to have solved my problem. Seems to have fixed the FD leak as well, which was also crashing the mesh. Thanks!
To answer your question, I have appleTVs as border routers spread across 2 structures, all wired. Glad you found the beta, it has been really solid.
Anyone having issues with the LED effects? I am getting everything else to work but the effects aren’t working on any of my switches.
I gave them a quick try a couple of weeks ago they seem to work just fine.’
Just took a quick video as an example.
Hello,
I just noticed that my SmartThings routines triggered by the double-tap (2x) button press have stopped working since updating my VTM31-SN to firmware version 1.1.5.
All other triggers (3x, 4x, 5x, and press-and-hold) are still working correctly, but the 2x trigger is not.
I found that there was an error in the routines, and I had to reselect the trigger because its name changed to “Pressed Twice”. However, even after fixing that, the routine still does not trigger.
In the device history, I can see that the event label appears differently (e.g., “2 presses detected”), which makes me think there might be a small glitch with the SmartThings Edge driver.
I’ve attached some screenshots to help illustrate the issue.
Thanks for your help!
I just updated to 1.1.6r1 because guests (and my girlfriend) were complaining about hitting the switch but it not always turning on which I think is related to the debounce change. Most switches seem fine, but I have one with 2x aux switches in smart bulb mode controlling several lights via Matter bindings that now seems to reboot after a tap or freeze and not respond until I pull the air gap.
The issue only seems to be with physical button presses. Toggling via HA seems to work fine.
Hi @EricM_Inovelli – How close is firmware 1.1.6 to production release?
Posting here because I can’t find the other thread, but is the white on/off ever going to get a firmware update? I have a handful mixed with my dimmers, and with all the nice features the dimmers have been receiving (specifically the notification bar), those on/off switches are starting to stick out like a sore thumb.
VTM30-SN (White On/Off Switch) Rev 1.0.5 was released on May 27th.
It has pretty much all of the features in the latest VTM31-SN software (incl. LED Effects).
However on checking online it appears not to have made it into the production DCL yet. That means you will have to wait until it gets into the production DCL or download it from the beta channel. If you have HA that is easy enough to do.
@EricM_Inovelli When do you expect VTM30 1.0.5 to make it into the DCL?
Eyyyyy! Good timing. At least I know it’s getting some love. I’ll be on the lookout for the official release.
