That sounds exactly what could be the problem, most all other devices Alexa pairs with are cloud ( and skills in the cloud ) matter and hue are the only local devices it tries to connect to , I bet it’s using a device in your second location , it has to pick just 1.
I agree that could be the issue, but I’ve plugged in 3 Tapo Matter wifi switches and Alexa finds them just fine. I’ve never had an issue with Alexa not finding something until OH. There’s something different about OH.
I’ve been searching unsuccessfully to find out how Alexa chooses an Echo device for pairing. Haven’t been able to find anything relevant.
I got it to work! The OH is running on a NUC that only uses a hardwired LAN. It’s plugged into the router that supplies wifi, but it didn’t use wifi itself. I enabled wifi on it and tried again and Alexa found OH instantly.
Any idea why wifi is required in this case? And why Google Home doesn’t need it on the NUC?
No, thats super odd. My openHAB is only hard wired , but Alexa finds it no problem. I agree, i would think GH would have the same issue. If you are plugged into a router that offers wifi, then it probably has some advanced configuration ? I would check and see if there is some MDNS setting there between physical links, but again not sure why Google worked in this case.
@digitaldan : I tried also with managed items and they are also not set at OH startup. And matter node things are also concerned (in fact all things) like in my example (one item is defined in file and one was defined with Main UI):
For this Tapo matter plug, if I change its state outside OH, I can see the items are immediately updated.
So the problem is really only at OH startup.
I would not be totally surprised if this is in link with dynamic thing types and their storage (I see these two files: org.openhab.binding.matter.internal.MatterChannelTypeProvider-ChannelGroupType.json and org.openhab.binding.matter.internal.MatterChannelTypeProvider-ThingType.json).
Edit: something important to mention: my things are defined in a config file.
Dan, logs sent to you when my matter smart bulb went OFFLINE.
I just have to wait 2 or 3 minutes…
I followed your instruction for log4j2.xml but the resulting file contains strange characters. Here is the pattern I set:
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} - %m%n"/>
I’m going to debug this today, i also have some changes to bridge status as well i’ll post
Can you post or PM your thing file for matter?
I figured out the issue, it was a order of operations problem. I was updating the states of the channels before all the custom channel/thing types were persisted. I’ll push a release out today once i test a bit more and clean up.
@Lolodomo there’s a new build with the channel/item fixes
Dan, confirmed to work. Well done!
Thanks, i just uploaded a new jar, i broke the color control initialization , but thats fixed now.
I just received one of the Inovelli matter switches - wow, this is an incredible device.
Yeah, i agree, its pretty feature packed, its also been rock solid for me which has been nice. I’m waiting a bit to see if there are some off the shelf OTBR that will come on the market as will need to install several across my home for coverage, but once that happens, i may standardize on these. I love the idea of the switches glowing red when my alarm system is going off, pulsing a color when its arming, or when a door or window is open, etc…, turning bright white when theres motion in a room to act as a night light… so many possibilities
Why multiple routers? If you have enough devices won’t one router cut it?
These GE Cync bulbs are painful. They seem to hate my Eero router. There are tons of complaints about them constantly losing connections.
Thread devices do mesh, like zigbee or z-wave. In my experience however, a large network that depends on these types of low power mesh routing are fragile and always have random stability issues. It’s complicated to actively keep mesh routing tables up to date, and even small changes to a device’s locations or local interference can lead to trouble across portions of a network. There are also congestion issues when too many messages are sent on the mesh and there is a significant delay in communications when you start having to send through multiple hops.
One of the things I love about thread is a thread border router at its core is simply a gateway to your IP network, much like a wireless access point, so you can put them anywhere you have network connectivity, and have thread devices attached directly to your network. In fact the next version of thread specifically supports wifi vendors adding thread radios to their access points, and allows better roaming/failover of thread devices on multiple routers (just like a wifi device). Ideally the majority of your devices are directly connected to a routers and independent from each other, and can fall back to mesh if a router is down or just too far away. Hopefully, this means things just mostly work.
How about the physical depth? Do they fit into the box easily? The early Zwave are a nightmare, later ones are thinner. I hope Innovelli kept the slim profile.
@digitaldan do you think it’s possible to move files in userdata to another PI to avoid re-pairing everything when moving OH to a new server?
I believe they have a blog post about this somewhere, and purposely made the devices slimer so multiple of them fit in gang boxes better after hearing the same feedback about z-wave/zigbee devices.