White Series Dimmer (VTM31-SN) - Bug/Enhancement Thread

Apple fumbled a bit on this. The latest Apple TV with WiFi only does not support thread. Only the 128gb WiFi + Ethernet model does.

2nd gen atv 4k all models do.

1 Like

If you have a solution for that I would be very intereested to see it.

Ok this will be a bit picture heavy but this is what’s worked for me and I have 15 of them. Main thing to remember is that Siri is stupid and you have to treat it as such in naming conventions.
First order of business, combine the switch into a single tile if it’s separated. Then click on the tile that has a square looking switch.


Rename this to something that you’ll know what it is but it won’t trigger Siri. For my naming convention it’s just the first letters of whatever fixture it’s controlling. G Inovelli Dimmer for a garage, FP for front porch, CFL for ceiling fan light, etc etc. close it out after renaming and saving.

Next go to the other tile related to the same switch that brings up the two sliders. Click the cog icon in the bottom right.

Then click accessories


Click one of the two accessories. Either the light or the led bar. Click its cog icon again in the bottom right. Rename the light to what you want Siri to recognize and set an icon if you want. For the led bar I just used the previous naming convention “G Notification Bar” or whatever you like that won’t be obvious to Siri just make sure it doesn’t have the actual lights name in it, select an icon.

Now separate the switches again.

End result should look something like
G Inovelli Dimmer Switch
Garage Lights (name of switched load)
G Inovelli Notification Bar

Hopefully that helps someone. I can share additional photos but post only allows 5. Pm if needed.

1 Like

No Thread or Zigbee dongle in use at Chez Vreihen, just one for Z-Wave. My HomePod Mini is my only border router and default Thread network.

Since I run HA in a virtual machine that needs to have the USB port manually re-added to it whenever it cold reboots for Z-Wave, I’m liking the thought of being liberated from dongle hell by the White series and HomePod…

1 Like

That is very useful. What happens however if someone says (in your example) “Turn on the Exterior Lights”? Are we back to the same place? I haven’t tested that but I will later on today.

It seems to me that if we could get the Light Bar (LB) and the Switch into different rooms then we would have something that we could use more easily.

I did manage to do that by adding the switch to HA (as a Matter device) and then exporting the Switch and the LB back to Homekit. At that point all is good since we have two independent switches and the LB can go in a separate room and stay away from everything else. The LB is available to HA and Homekit but using a combination of your naming scheme and a different room it’s not going to be get activated accidentally.

However in doing that the programmable switch element is lost in HomeKit so double clicks and holds have to be handled in HA (I’m so far using the excellent Blueprint by @francesc0 from this thread and passing the result as a toggle that is exported to Homekit (but I’m sure there is a better way to do it).

This is only my first week using HA so its been a steep leaning curve but I wonder if someone who is smarter that I could figure out an extension of @jvm33’s also excellent template (which I also have “working”) to export the programmable switch elements as well.

Note: @jvm33’s template gives me a switch rather than a dimmer for the installations that do not use dimming which I also like.

What I have now is anything but perfect and I hope that Inovelli can come up with new firmware that will resolve these issues without needing the “HA filter”, but it seems as a group some progress is being made.

UPDATE 4: Turning on ipv6 in my router settings appears to have improved stability issue when using 2 Google home devices with Thread Radios. However, my son disconnected a thread border router and a couple switches remained offline after that. I think I’m done trying to figure this out. There is definitely a Google issue here, and likely an Inovelli issue as well. I hope the firmware update fixes this.

UPDATE 3: The google device network was stable for 3 weeks with a single router. I’m currently testing turning on ipv6, which I somehow missed as being a critical part of thread.

UPDATE 2: Only having one Google router device fixed my reboot required disconnection issues. I am somewhat saddened because I’m not sure I can turn off the thread radio in my 2nd Google device, which makes a great bedroom clock.

UPDATE 1: I managed to get most signal strengths Green by recommissioning them. STILL having some disconnect issues though…

ORIGINAL: I am currently using 15 white switches with 2 Google border routers (Google Home Max and Nest Hub). I have had an issue with the most distant switches disconnecting from smart controls and never reconnecting without rebooting the border routers. These are my basement light and front porch switches. The twist is I have 2 front porch switches and 1 of them usually still works.

Signal strengths for my switches are all over the place (Green/Yellow/Red), but I mostly have issues with the distant ones, which really are not that far away. I do wonder why the network mesh is not self repairing. It perhaps it is, and it is a Google reconnect issue.

1 Like

I’d say a potential work around for that would be to create a scene called the exterior lights and only include the lights you wants for that phrase?

I haven’t encountered that particular issue since most of my lights are automated based on cameras with person and vehicle detection and motion and mmWave sensors. I don’t frequently talk to Siri but for individual lights, that has worked for me. I can try that call for exterior lights thing but I’m fairly sure you are correct in that sense as it is considered a light and it will turn the entire “room” on for that. That was my only thought as to why a scene would potentially work if its name is particular to a whole room

Its an Apple issue, not a Inovelli firmware issue. Inovelli follows the Matter standard. Apple needs to fix their UI. I’ve posted several comments on Apple’s feedbackassistant.developer.com about needing to be able to put different Matter endpoint devices into different rooms or an option to tell Siri to ignore certain device endpoints. I did receive a vague response that they are going to do something about this in a future iOS release. What that will be and how long are all unclear. Hopefully enough people reach out to them about the issue that they actually do something to fix it.

1 Like

Is there a way to put the switch into pairing mode without a factory reset? That would be very helpful if there isn’t already a way to do that.

3x config or pull the air gap.

I have. I have both Sky Connect and Home Pod’s/Apple TV’s. My switches are not re-connecting effectivly.

If I make a change from inside HA like adjust the dimmer light value, the switch responds. However, the switch does not update HA to the event.

If I turn off light(1) manually inside HA, the LED bar turns off. No action appears in the log book. A few seconds later it turns back on inside HA, but not at the switch. (HA now reports light as on and at 100%, the switch LED is still off).

The switch is receiving commands, but not communicating changes or events back to HA.

1 Like

There are absolutely some bugs in HA’s Matter implementation. I’ve experienced a lot of what you have, but I feel fairly confident it’s a change in the Matter SDK they’re using.

See issue report here: Matter - Device state not updating · Issue #124503 · home-assistant/core · GitHub

FWIW, they pushed out 6.4.2 today, which doesn’t sound like it contains any bug fixes per the changelog:

@Eric_Inovelli – I’m 9 switches into the install of the 70 (+ a bunch of AUX) that I got. Here’s where I am so far.

Information on my setup:

  • Running an OpenThread Border Router (OTBR) implementation on a SkyConnect (Home Assistant’s solution-on-a-stick) connecting to HA via their approved/standard path. Nothing exotic or home-rolled about the software side of this.
  • Everything’s in a single VLAN, IPv6 connectivity is fine, and commissioning of the Matter devices proceeds without a hitch.
  • Switches are scattered about among a handful of gangs between two floors. By my estimation, every switch is within 30 feet of almost every other switch. There is one gang that hosts 3 of the White switches side by side; this is the only multi-gang that hosts more than 1 of the White switches.
  • The house is standard construction, no concrete walls or floors, no crazy metal plates. Typical drywall, lumber, plywood.
  • I killed 2.4 GHz WiFi on channels 1 and 6, and have left Thread channel at the default 15. (I already had very low traffic on the 2.4 GHz side, but I felt it was prudent to eliminate this as a source of interference after trying everything else I could think of).

Rough rundown of steps so far:

  1. Commissioned devices one at a time to add them to the network. Started upstairs, since the OTBR is up there. Connectivity initially seemed okay, but I noticed that I had to keep my OTBR USB device completely out of the closet to get a decent connection to the first switch I commissioned. This surprised me, but didn’t think a ton of it – the USB device has a fairly weak radio in it, supposedly only about 5 dBm, so I thought it’d just need a solid connection to a nearby switch to make this work well.
  2. Finished installing upstairs switches, and connectivity seemed okay from what I could tell through light testing. I put the OTBR back in the closet, since it now had a switch essentially right next to it, outside the closet door. And indeed, I was typically seeing green connectivity indicators on the switches, although not consistently. Again, did not think a ton of it, figuring the network would strengthen as I added switches.
  3. After adding downstairs switches (the 3 in a multi-gang side by side), first noticed what appeared to be significant connectivity issues where those downstairs devices would randomly report “unavailable” in HA for periods of time. Surprising, since the multi-gang was only needing to send signal through the floor and maybe the wall to get to the next switch in the chain. Confirmed that this is essentially the signal path that’s being attempted by looking at diagnostics in the OTBR – very weak link appears from one of the multi-gang switches up to the switch on the second floor.
  4. Figured I should add a handful of additional downstairs switches to confirm that there wasn’t some freak interference in the specific path just between the upstairs and downstairs switches I’d already installed. Added three more switches downstairs, each in a single gang, spaced out a bit from one another. All the links from upstairs to downstairs are weak, and importantly, the OTBR itself tends to be the most stable of those links (albeit a weak link) to one of the downstairs switches, despite it having a supposedly weak radio. The poor performance continues.
  5. Killed the WiFi channels as mentioned above, eliminating potential sources of interference. No real improvement here, same weak links observed, which was expected due to how lightly the 2.4 GHz was being used here.
  6. Finally went back to remove the OTBR from the closet again, thus allowing at least some potential paths from it to other switches downstairs and maybe improving strength of signal to any switches that could reach it. Fascinating result: I got an explosion of links directly to the OTBR, some of which are stronger than the links I’m getting between switches themselves. Again, the OTBR dongle in question is supposed to have a weak radio. I am currently seeing it connect to 8 of the 9 switches (!!) (EDIT: minutes later, now seeing “just” 6 direct connections). Uncertain yet whether this is going to yield better overall reliability in the network, but it’s hard to imagine it not being so.
  7. Went around doing the “network strength” config button test on each White switch just now, since it’s been a while since I looked at those. 4 show green, 2 show red, 3 blink red (no connection?). Funny enough, probably not a coincidence, the green ones are the ones that are in the multi-gang within centimeters of one another, despite being furthest far from the BR of all the switches, and the one that is within 3 feet of the BR. (Important question, not explained by doc: what does “network strength” actually mean? Link quality to the strongest link of one other router? Link quality to all linked routers, averaged? Measured route cost back to the BR? Something else?)

Deductions, take with a grain of salt: It feels like I’m getting symptoms of either A) weak transceiving between the switches (either low transmit power, or poor reception, or both), or B) interference between the radios all attempting to establish links as REEDs. I am guessing at both of these, but I don’t know how else to explain what I’m seeing so far, and no way to test the theories (yet!).

Here is what I think I need at this point to diagnose and ultimately solve connectivity issues before I can commit to the remaining 60 switches in my overall install:

  • An understanding of the transceiver power on the switches. I looked for documentation on this, including trying to look up info on the MG24 itself – but I think this comes down to the user of the chipset to tell the radio what to do. Thus, I assume this is ultimately a firmware thing.
  • Any (hopefully inexpensive) suggestion on how to test the actual signal strength, plus any interference getting in the way, from one of the switches in a real world setting. It’s one thing to say “this radio should be transmitting at +10 dBm” and another to see that the signal is actually strong a mere 20 feet away. All I have at the moment is a diagnostic report coming off the OTBR indicating relative (ordinal) link quality between nodes, and I don’t know how trustworthy that is (besides it being hard to diagnose anything when the network itself is deciding upon the linkages).
  • A very nice-to-have would be the ability to set the transmit power on the radios via config. Since there will be a lot of multi-gang setups, it feels crucial to me that the user be able to specify one of the switches in the gang to have full transmit power, while the others have low transmit power, such that at least one of the switches is very likely to “break through” any interference from the other switches and reach a more distant switch/gang.
  • I also feel it would be practically a necessity in a large installation like mine to have the ability to set the role of each device in the Thread network via configuration. E.g., in a multi-gang setup, I need to be able to specify one of the devices to act as a REED, while the others are set “down” to just FEDs. (Ideally, we’d use the REED setting in combination with a higher transmit power where necessary, while the FEDs would likely be set to lower transmit power).

Any comments at this point appreciated, even if only “message acknowledged, we’re talking!” :slight_smile:

1 Like

Actually, 6.4.2 allows some disablement of features/reversion to the Matter SDK being used. So I think the steps as suggested by the developer could be followed if you’re having these issues, to see if they help. Or you can just follow along and see what other folks are experiencing before making your own similar changes:

1 Like

I’m finding that I’m having a hard time keeping the White switches online in Home Assistant, even when the switches that I added separately to HomeKit remain accessible in HomeKit.

I’m using a Thread network through my Apple TV and two HomePods. HA is running on a raspberry pi.

I have two White switches in a test setup: One added to both HomeKit and Home Assistant separately (Switch 1) and one added to Home Assistant and then pushed through to HomeKit using the HomeKit bridge (Switch 2).

I set up a Home Assistant automation to tell me if any of my Thread over Matter devices go offline. Occasionally (once a day or two), they all pop offline and then most of them come back online after a while. But usually, one of them stays offline for a long time (30 minutes).

When Switch 2 goes offline, it goes offline in HomeKit, too, obviously because it’s not visible to the HomeKit bridge.

HOWEVER, when Switch 1 goes offline in HA, it still works fine in HomeKit. And, oddly, I can ping the switch from HA and the ping is successful, yet the device remains offline. And, I can re-interview the device successfully, yet it still stays offline.

Why is the switch working in HomeKit but HA can’t see it? Why can I ping it and re-interview it in HA, but yet the device stays offline? And, really, what’s causing everything to flicker offline briefly every day or two anyway?

Any help or leads to the right direction are much appreciated.

1 Like

The way Matter over Thread works is if you have the switch connected to multiple controller systems (each being referred to as as a Matter “fabric”), the devices essentially set up separate mesh interconnections for their communications. That is, there is a first Matter “fabric” which connects to iOS, and a second Matter “fabric” that connects to HA. Even though they may route through the same border router, each fabric can set up its own routes through devices. So, when a device loses a connection, its entirely possible that one fabric has some node disconnects, while the same nodes on another fabric remain working as the routes rebuild.

Some relief may be coming - I’ve been testing tvOS 18 beta 8 and it does seem to work better as a border router, so I think Apple has improved that software. People are guessing that tvOS 18 will roll out as early as next week as Apple has their scheduled September event where they usually announce their new iOS / tvOS version.

And as for the HA “ping” - never really figured out what that does. HA doesn’t really give any clear indication of what is happening when you use “ping” on a non-working node.

2 Likes

This is super helpful! Thank you!

I haven’t noticed any problems with my Matter devices (and Inovelli switches) that I connected directly to HomeKit, but the HA connections seem to break down every day or two and I can’t determine a cause. Adding my Inovelli switches directly to HA and then using HomeKit Bridge to add them to my Apple Home is my preferred way of setting these up. But if I can’t rely on the devices staying connected in HA, then I’m hesitant to set them up this way.

Is there a way to help ensure my HA fabric stays solid? I have an Apple TV (Ethernet) and HA running on a Rapsberry pi (also Ethernet).

Ha! Isn’t it strange, though, that I can re-interview the switch in HA without error, even though the switch is showing “offline”?

1 Like

I had a few Inovelli devices that were not reconnecting this morning after I did a HA reboot. I switched to the “beta” version of the HA Matter Server, and suddenly everything worked. Maybe HA fixed something in their Matter Server. I’d expect that to roll out within the week (Version 6.5.0 of their matter server), or you could try the beta matter server.

2 Likes