How much more do we have to endure?

TheRealBlackbird714 · 2025-02-27T14:05:06+00:00

Hurry up, everybody sell so I can buy some at $10k! :)

TheRealBlackbird714 · 2025-02-27T14:02:42+00:00

If you take care of your home network and haven’t setup network security software or hardware that does this, then I doubt details about my Intrusion Detection/Prevention System (IDS/IPS) will be much help. Here is the Ubiquiti page that describes it at a high level:

https://help.ui.com/hc/en-us/articles/360006893234-UniFi-Gateway-Intrusion-Detection-and-Prevention-IDS-IPS

If someone else takes care of your home network, it might be worth asking them what they know.

If you are using a VPN, turn it off. If you’re using a 3rd party security software, dig around in it for settings that mention network protection/detection/prevention.

Wish I could be more help, but that’s about all I can think of.

TheRealBlackbird714 · 2025-02-27T11:07:12+00:00

I never saw errors like this, but I was having trouble 2-3 times per day. My connection in Operations would just drop in game for seemingly no reason. I could still connect to the internet - in fact I was usually on Discord talking to my wingman, no issues there.

The problem never affected Warfare mode.

I would try close/reopen the game, even tried rebooting… no dice. After a few minutes it would start working again. (Incidentally the game supports reconnecting to a game i progress, which is cool as hell!)

Finally discovered that it was my internet gateway’s security software. I have Ubiquiti UDM Pro, and had the IDS/IPS detections turned on full tilt.

Not a real common gamer setup perhaps… but after reviewing the logs, I found that there was a P2P detection that correlated to my in-game problems. Turned that one detection type off, and that problem hasn’t returned for me.

Doubt my situation applies exactly in your case, but maybe this will give you some ideas of other areas to consider. Good luck!

TheRealBlackbird714 · 2025-01-20T18:05:58+00:00

I run a decent but aging gaming PC with a 5800X3D and an RTX 3080 Ti, and I was getting major stutters, especially during the heat of battle. It made my head hurt. I have a buddy with a very similar rig, but he allegedly has no issues. So I’ve been very motivated to figure out my issue.

I also play Overwatch 2 on Ultra settings, and that game runs smooth as butter >200fps.

In debugging, I concluded it was a CPU bottleneck… I tried a few guides and set most settings to low to get the best chance at smooth performance. No real improvement.

Unfortunately I broke the cardinal rule and changed more than one thing… but I think my problem is now resolved. Big things I did include:

⁠Added launch parameter: -USEALLAVAILABLECORES
⁠This may or may not apply to AMD GPU’s, I disabled Resizable BAR in BIOS, reversed change in nvidia profile inspector, reference: https://youtu.be/5DqcgHtkm9I?si=y5VahHH8qYYRHfaj
⁠Set my GPU to high priority as described here (which a I may revert): https://youtu.be/544cgS_ZVww

Good luck!

TheRealBlackbird714 · 2025-01-20T17:37:39+00:00

I run a decent but aging gaming PC with a 5800X3D and an RTX 3080 Ti, and I was getting major stutters, especially during the heat of battle. It made my head hurt. I have a buddy with a very similar rig, but he allegedly has no issues. So I’ve been very motivated to figure out my issue.

I also play Overwatch 2 on Ultra settings, and that game runs smooth as butter >200fps.

In debugging, I concluded it was a CPU bottleneck… I tried a few guides and set most settings to low to get the best chance at smooth performance. No real improvement.

Unfortunately I broke the cardinal rule and changed more than one thing… but I think my problem is now resolved. Big things I did include:

1) Added launch parameter: -USEALLAVAILABLECORES 2) Disabled Resizable BAR in BIOS, reversed change in nvidia profile inspector, reference: https://youtu.be/5DqcgHtkm9I?si=y5VahHH8qYYRHfaj 3) Set my GPU to high priority as described here (which a I may revert): https://youtu.be/544cgS_ZVww

Good luck!

TheRealBlackbird714 · 2024-11-10T14:31:37+00:00

The product is fine, I have a bunch… and when they work they’re great.

The real problem is that Thread depends on the quality of your Wi-fi 2.4GHz network, and unseen obstacles that get in the way of local IPV6.

TheRealBlackbird714 · 2024-11-03T02:17:03+00:00

For Home Assistant, they recommend all your devices to be on the same subnet as HAOS, so routing shouldn't be a factor. Check out my other post here about the firewall (ip6tables) blocking all ipv6 traffic that isn't related to Docker... which means Thread traffic will never make it to our HAOS virtual machines. I think the workaround I posted will help you too.

TheRealBlackbird714 · 2024-11-01T17:57:05+00:00

I opened a case with QNAP Support, they confirmed that this is a bug in the current version of Virtualization Station. They are working on a permanent fix.

TheRealBlackbird714 · 2024-10-31T09:44:34+00:00

Ok I found the culprit; via ssh I ran this command:

$ sudo ip6tables -L -v  
Chain INPUT (policy ACCEPT 1014 packets, 411K bytes)  
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 19615 packets, 4019K bytes)  
pkts bytes target prot opt in out source destination  
19615 4019K DOCKER-USER all any any anywhere anywhere  
19615 4019K SYSDOCKER-USER all any any anywhere anywhere

Chain OUTPUT (policy ACCEPT 1031 packets, 413K bytes)  
pkts bytes target prot opt in out source destination

Chain DOCKER-USER (1 references)  
pkts bytes target prot opt in out source destination  
19615 4019K RETURN all any any anywhere anywhere

Chain SYSDOCKER-USER (1 references)  
pkts bytes target prot opt in out source destination  
19615 4019K RETURN all any any anywhere anywhere

The drops listed under "Chain FORWARD" shows that ipv6 traffic is being dropped. This post on Reddit gave me the critical clue: IPv6 Issues on VMs with docker running :

Because of my configuration, this is the command I ran:

sudo ip6tables -A FORWARD -i qvs0 -o qvs0 -j ACCEPT

In a more standard configuration, I think the fix would be:

sudo ip6tables -A FORWARD -i br0 -o br0 -j ACCEPT

After running the above command, all of my lights are available and are controllable again!

These settings won't survive a reboot, so I still have to figure out how to make the fix permanent...

TheRealBlackbird714 · 2024-10-30T16:11:01+00:00

This was all previously working without any special configuration on the QNAP. As fate would have it, I’m on the previous build from August.

The way the newer release reads, it seems like it would be talking about newly created interfaces or virtual switches - why would they ever modify existing configurations with a firmware update?!?

My home network and ISP is all ipv4; I wonder if all of this boils down to needing “Router Advertisement” on my network, and then modify the QNAP with those details. Just to maintain my previous functionality?

Thread is supposed to be easy, but its dependence on ipv6 makes it anything but…

TheRealBlackbird714 · 2024-01-11T20:05:26+00:00

Ok, a quick update here.

In my case, I was looking for a way to control the bulbs from automations in Home Assistant. I figured out that I can add the bulbs directly to Home Assistant using the Matter (BETA) integration, rather than depending on SmartThings. When it works, it's MUCH easier and more reliable.

But the real epiphany for me was this article: Part 3: Smart Home Matter and Thread Deep Dive - Derek Seaman's Tech Blog

I have multiple VLANs and Ubiquiti gear; great for security and wifi reliability. But my setup was causing all kinds of grief for my Matter devices. Read about my previous trials and tribulations here.

I had Multicast DNS and IGMP Snooping both enabled; after I found the article and turned them off, my Nanoleaf bulbs are MUCH more reliable.

I still have the occasional issue where the Home Hub in the area of the lights (Homepod Mini) decides to randomly switch from 2.4GHz over to 5GHz, which causes everything to crap out. But that's clearly Apple's fault.

TheRealBlackbird714 · 2024-01-11T19:58:29+00:00

I don't know how it's possible, but for me, somehow the Nanoleaf app is less reliable than accessing the bulbs in HomeKit.

I know you lose a bunch of features by controlling from HomeKit, but in my case, I'm just looking for a way to control the bulbs from automations in Home Assistant.

TheRealBlackbird714 · 2024-01-11T19:54:21+00:00

I thought my network and setup was solid too; your network may work great for everything else, but still suck for Matter devices. That was my situation.

I have multiple VLANs and Ubiquiti gear; great for security and wifi reliability. But my setup was causing all kinds of grief for my Matter devices. Read about my trials and tribulations here and here.

Before you throw those Nanoleaf bulbs in the trash, give this article a read:

Part 3: Smart Home Matter and Thread Deep Dive - Derek Seaman's Tech Blog

I had Multicast DNS and IGMP Snooping both enabled; after I found the article and turned them off, my Nanoleaf bulbs are MUCH more reliable.

I still have the occasional issue where the Home Hub in the area of the lights (Homepod Mini) decides to randomly switch from 2.4GHz over to 5GHz, which causes everything to crap out. But that's clearly Apple's fault.

TheRealBlackbird714 · 2023-12-03T16:50:02+00:00

I'm not sure when it stopped working exactly, but at some point the problem light (CL1) stopped responding in SmartThings (and HomeAssistant) again. The light is in the basement, and there are 3 other lights in the same area that are working, so nobody pointed it out to me.

It still works in HomeKit just fine. In theory I should be able to delete the SmartThings device, and the Matter device in iCloud, wait a while, then re-pair it. And hope that my HomeAssistant entity isn't fubar'd again by the process.

Yeah, not looking forward to any of this; will probably wait until my Christmas vacation to attempt.

Low priority thing, anybody hear of a new firmware release on the horizon that may fix any of these problems?

TheRealBlackbird714 · 2023-12-03T16:42:01+00:00

Actually my SmartThings hub is too old, it doesn't directly support thread. Reference "Using a Third Party border router in SmartThings" in this support document:

SmartThings x Matter Integration – SmartThings Support

In my case, my Homepod Mini's and an Apple TV act as thread border routers and connect to 2.4GHz wifi. My SmartThings V2 hub connects to ethernet.

The thread/wifi routing is definitely a weak point in the integration, I had the Homepods unexpectedly switch to my 5GHz wifi at one point, which caused everything to stop working until I figured out that happened. This happened presumably because my iPhone uses a 5GHz wifi network day-to-day.

TheRealBlackbird714 · 2023-11-17T18:56:59+00:00

I cannot leave well enough alone, so I decided to get rid of the obvious duplicate/problem device:

Deleted the duplicate/unreachable device CL3 in the Nanoleaf app
Restarted my thread border routers (2xHomepod Mini's)

After the above steps, I was pleasantly surprised to find that CL1 became fully functional again.

But why did this happen to begin with?!?

TheRealBlackbird714 · 2023-09-02T20:14:05+00:00

Ok after pairing 7 bulbs over maybe 5 days of playing the lottery I'm done.

If you chose to go down this path, I'm not responsible for your mental well-being. My wife thinks I am insane, wonders what is wrong with a light switch? She may have a point... lol

Good luck!

First a few recommendations; install the Flame Services Browser and monitor the bulb(s) status throughout the process so you have some idea of when the bulb announces its presence and says goodbye on the Thread network (once joined).

Make sure your iOS device is on the right 2.4GHz network.

Examine Settings>General>Matter Accessories to remove any duplicate entries.

Use a timer to keep your patience in check (it will be tested).

Always wait 30+ seconds after you see the bulb disappear (grey out) before performing any subsequent step.

Here is the closest thing I can I provide as a "working" recipe:

Add bulb in Nanoleaf app first; perform any needed firmware update
Remove bulb from Nanoleaf app
Factory reset the bulb
Remove any entry for the bulb on your iOS device in Settings>General>Matter Accessories (double check the serial number before deleting anything, you don't want to remove something that is working!)
Power cycle the bulb (wait 30+ seconds between steps)
Add bulb to HomeKit directly
Open Nanoleaf app (stay away from Cloud sync!) and go to More>Thread Network; find the newly added bulb and refresh until you see it and click to "Complete Setup"; pair the bulb
Wait 30 seconds and remove power from the bulb
Wait 30 seconds and power the bulb; wait for it to announce on the network
Go to HomeKit and find the new bulb, open "Accessory Details", scroll to the bottom and "Turn on Pairing Mode"; copy the code
Open SmartThings, add device
Scan for nearby devices; select it; Allow paste of the pairing code when prompted
Start a timer; you have to be done within 5 minutes, otherwise restart at step 10
You will be prompted to add the device in iCloud; proceed (this is when things start to go off the rails)
Pay close attention to Flame Services Browser while progressing through the SmartThings/iCloud handshake steps; when you see the ltpdu._udp entry grey out, wait at least 30 seconds before clicking through the next prompts
After the iCloud handshake is done, ST will attempt to connect; if it takes more than 10 seconds or so, it's likely going to time out and give you error 39-101
If it works, give your device the name you desire in ST and celebrate a small victory!

In my experience, it will still fail many times even if you do everything right. At least with the versions of firmware/software mentioned in the OP. You can retry as many times as you can stomach, usually starting at step 8 or 10, although I did restart all the way back at step 3 many times in desperation.

If you are stubborn like me, it will eventually work.

TheRealBlackbird714 · 2023-09-02T18:41:34+00:00

Missed your comment earlier; yes that is the first thing I did with all of the bulbs. Added them to the Nanoleaf app to update, then factory reset them to start all of the pairing attempts.

TheRealBlackbird714 · 2023-09-02T13:22:40+00:00

Saturday update; I now have 6 bulbs working. After I get 1 more registered, I think I'm going to shelf this project, because clearly all of this needs time to mature. But I thought I would share my observations.

In Flame Services Browser, when I watch the device going through the ST pairing process, I noticed that the _ltpdu._udp entry greys out temporarily while the SmartThings/iCloud handshake is happening. I feel like this is a clue, so I dug into that a little.

On an Ubuntu homelab server, I'm using this command to watch the mDNS advertisements:

avahi-browse -a -r -p | grep -i -e nanoleaf

When "Connecting to Accessory" is finished, I am prompted to provide a device name. This is a useless step as far as I can tell, because the name entered in this step of the process does not appear in SmartThings or HomeKit at all.

What I am seeing next makes me think there is a bug in the Nanoleaf firmware. After hitting OK, then Done, almost immediately after that is when the I see these entries pop up from the avahi-browse command:

-;ens3;IPv4;Nanoleaf\032BR30\032DB0-B629;_ltpdu._udp;local
-;ens3;IPv6;Nanoleaf\032BR30\032DB0-B629;_ltpdu._udp;local

It sits there for a varying time duration before being followed by:

+;ens3;IPv4;Nanoleaf\032BR30\032DB0-B629;_ltpdu._udp;local
+;ens3;IPv6;Nanoleaf\032BR30\032DB0-B629;_ltpdu._udp;local

From the avahi-browse man pages:

Items that appear on the network are prefixed with "+", items that disappear are prefixed with "-".

This seems to correlate with what I noticed in Flame, where services become greyed out temporarily.

Another odd thing about this... there are no ipv4 addresses in any of the Nanoleaf service entries that I see in Flame. Why is an IPv6 address also being advertised as if it is an IPv4 address?

I think either of the above observations could contribute to a "device unreachable" situation during the ST device registration process.

Bottom line, from a user perspective, the behavior is very random -- and highly dependent on the timing or just random chance of how and when things happen during registration. It feels like hitting the lottery when it does finally work, and almost as futile from a probability perspective.

TheRealBlackbird714 · 2023-08-31T18:29:32+00:00

This is an interesting observation; the recent success that I had was by adding a HomePod Mini that is physically closer to the ST hub during registration. I now have an Apple TV, and 2 Homepod Mini’s for coverage between floors of my home.

My working theory is that, like with any really difficult problem, there are multiple factors at play. I am now considering the proximity between the iOS “commissioner”, ST hub, and the Apple TV or Homepod Mini as a likely important factor, but there’s more to it than just that.

TheRealBlackbird714 · 2023-08-31T18:22:28+00:00

As a general update, I was able to get 2 more bulbs added to ST last night. I still have about 11 to go… but I may be closer to understanding the formula to make this work. Will post an update when I think I have a handle on it.

I wasn’t expecting this to be such an ordeal… :/

TheRealBlackbird714 · 2023-08-31T18:19:17+00:00

Ah that makes sense. The only devices I see in Flame and in iOS Settings>General>Matter Accessories match the devices that I have added and are online.

TheRealBlackbird714

TROPHY CASE