bigDvette

Yes, has been since .18 came out and for clarity you could add matter WiFi devices even earlier than .18 but with .18 you can add thread matter devices albeit they are all just on/off.

works same with IOS. I can add thread devices and they do hang in UDI and only have on/off.

@Guy Lavoie try updating EISY and adding your nanoleaf bulb now. I was able to add mine after the update today to _18. It is a dimmer bulb but only has on-off functionality, but it did commission and I can turn bulb on and off.

To be clearer on what I meant. When you share the device from the first one, you are getting a new commissioning code and when you use your mobile device to commission to that ecosystem/fabric, the app shares the credentials for that ecosystem so it can join. So even when you use home assistant and declare Apple as the Thread Network, if you commission to HA and then commission to Apple by sharing the device you have 2 fabrics using the same thread network as a matter controller / bridge ... This is a good source for matter fabrics and such. https://matter-smarthome.de/en/know-how/what-is-a-matter-fabric/

Guys, I think you are pissing up a rope until UDI fixes their matter fabric / server for thread. A device can be a part of 1 or more thread border routers but only 1 thread network. When you are asked if new or existing installing the device, that is determining if it is being added to a new thread network TBR or not. The nanoleaf app is not going to help you. You can add the device using Bluetooth and it will see your devices on the existing thread network. when you add a device to the first matter controller (Apple, Alexa, google, OTBR) you are putting it on the thread network and first fabric and establishing the credentials. When you share the device you are sharing the credentials to commission on a second fabric. That fabric talks directly to the device because it has the credentials to do such and does not go through the first fabric. Each fabric needs a TBR to hat can talk between thread and WiFi / lan networks so that you can talk to that device on the network. Nanoleaf are working fine now. obviously UDI haven’t figured out the ability to put a thread device on their fabric which is what it sets up so you can control them from the admin console / eisy. Watching the network it seems like it isn’t getting the Mdns messages that would tell it the ipv6 address so it can interview and setup the device. I haven’t seen anyone get a thread device working yet.

To your statement, I think you are conflating topics. The post that said iOS devices don't work had a specific error and it specifically stated that it was an issue with BLE Wi-FI commissining and it said Matter should work for IP, Thread and previously commissioned devices. So based on that, my use of iOS should not be a problem and that is not the error I get. Thread devices are on an ipV6 network managed by the TBR in my case Apple TBR via Apple TVs. My HA instance use Apple as the TBR to communicate with the device. The device is commissioned in HA. I also shared the device via QR code adn commissioned it in to Apple Home which would be a separate fabric and that works fine. When I share the code to commission in to UDI, it just doesn't ever see the device. To further my suspicion I have only 4 matter over wifi devices (sonoff relays). I shared the code the same way and they commissioned just fine via iOS using UD Mobile. I moved my UDI in to the same VLAN to rule out MDNS issues across VLANs. So the issue seems to be with Thread devices which should really only differ in that they work via a TBR using ipv6. With HA to commission a device on the Apple Network using Thread you have to share the Apple Credentials to to commissioning App to do the initial commissioning. I assume that is why the statement made was that it should work for previously commissioned devices. I hope someone from UDI is reading the forums. Happy to help test, I have 98 Thread devices and 4 matter over wifi devices consisting of on/off plugs, motion sensors, light switches, fan switches and matter buttons.

So, we do have different experiences. I am using Home Assistant with Apple as my border router. I updated to 1_13 and don't get same error, HA generates a QR code so that isn't the issue and I'm not resetting my devices as they are paired all to HA and i have not problem sharing the pairing to Apple Home from there as well. I can scan the QR code and I get "Adding Matter Device" pleas wait and on the UDI Admin console the Add a device to the Matter network pops up with Listening for MAtter devcies to add to network, but it never works. My guess is given people have gotten Matter over Wifi devices to work, UDI is having problems with ipv6 traffic. For home assistant there were serveral ipv6 hop params needed to listen inside a container. I have no idea of UDI is working. Now it seems to be a listening issue.

I had 5.9.1 and just updated and it is installing 1_13 as I watch the log.

My issue with the post is that the only devices I have tried to commission using IOS were already commissioned devices when I got the error.

Oh, I had problems. 1 of my soft starts on my AC units died and some other stuff not to mention the thousands spent replacing switches and that's before all the time (which honestly, I enjoy problem solving so yeah). I have a claim with Tesla.

I am using the Inovelli White Switches 2-1 dimmer, fan module, canopy and waiting on the on/off w/humidity to come out. I detailed in another post my issues with the tesla powerwall and insteon switches / communication issues. I've been on insteon for like 20 years (maybe little less) and it has been great, but was showing it's age. I took the opportunity to move to what I assume will be the next generation to be around a while and decided to incur the pain of matter/thread. I am doing thread only if I can. I'm currently using some wifi for specific applications. I haven't replace some of my on/off switches, none of my leak sensors and have kept my keypad lincs.. Waiting for inovelli on/off with humidity for bathrooms, inovelli has an upcoming scene controller and since I'm ubiquity I may use their upcoming product release for leak sensors. I use elk for alarm panel, but may transition to ubiquity protect for alarm at some point. I currently would like to commission my matter light switches that are linked to insteon keypadlincs to manage the syncing of those buttons in eisy instead of home assistant automations and was trying to see how far I could take that, but it is working fine in HA. https://community.inovelli.com/t/my-journey-from-insteon-to-inovelli-and-matter-thread/18613

I’m pretty up on all the networking requirements for matter. I don’t think the matter dongle can work as a thread border router given the requirement to use thread is that you have to have a border router in the 5.9.1 release notes. My real reason for wanting to know if anybody’s gotten a device set up is because there’s no mention of whether or not the Zmatter / EISY need to be on the same vlan as the thread border router. With Home Assistant I had to make sure that the matter server was in the same vlan as the thread Apple border router. My assumption is the EISY is running its own matter server much like Home Assistant has to run its own matter server to provision devices. so far I haven’t been able to get matter servers talking to one other except in the same vlan and at the moment my EISY is not in the same vlan. United States. I’m kind of hoping I can use one of the Wi-Fi connections and stick the Wi-Fi adapter in the vlan of the matter servers instead of having to move the EISY to that vlan but there’s no information on how any of the networking works and a flat network simply doesn’t cut it with all these IOT devices

Has anyone got a matter device paired. I am looking forward to this because I am still using KPLs for scene controllers even though all my switches are now matter over thread. I was hoping to add the to Eisy and then put them in scenes to remove the automations I have built in Home Assistant to keep switch and KPL in sync. I too am getting the error reading QR code message. The 5.9.1 notes talk about wifi settings change, but I'm assuming it doesn't have to turn on the wifi radio as eisy is not acting as a TBR so it doesn't "need" a wifi signal like the TBR does to communicate with thread devices.

You can also add it manually. Just add the device by typing https://IP_ADDRESS:8080/desc in the window that pops up. It adds it locally. If it ever finds it on the network you will see it as eisy.local. I have 1 Mac I can't get to find it automatically. I know it is the network setting to allow local access. There is process to reset all of that I just haven't messed with yet.

I keep seeing red blinks on some switches when locally pressed. I've had the issue with device being randomly turned off and now I've had 2 times where all the devices came on (like if you do on with the my lighting scene). Then last night no device presses would work on switches but I could control them from ISY. Looked and all the links in the PLM were gone. I don't think I accidentally held in the button when plugging in. Restored it fine and then all lights came on at 4am. Sound like a failing PLM?

thanks I have done that. It isn't at a specific time. I'm having home assistant monitor the wifi bulb and send me a notice when it goes offline so I can find a time, but there isn't any specific time. It is strange it is only the v.43 modules. They are a pain to replace. I can write an automation in Home Assistant to turn back on the micro modules when light goes unavailable, but that is a hack. I'm wondering if some electrical noise is causing them to turn off at the switch. Like I say, when I see the light bulb become unavailable, if I look at ISY it still says it is On until I query and then it shows off so I don't think Eisy is getting a message to log.

For about the last month my micro on/off switches will randomly turn themselves off. I don't have any programs that use them. I have restored their links to see if that was the problem. The only on/off modules that have this problem are the v.43. These switches are left continuously on since I went to wifi bulbs in those outdoor floods a year ago, but this problem has only recently started. Has anyone else had strange behavior with micro on/off switches? I don't get any off event in the log and the status of the light doesn't update until my query all program runs at 5am. I can see that this particular day the bulbs lost power at 2:33am. I'll wakeup and the lifx devices are offline and these on/off being off is the problem.

I too am using the devlist.yml without problem. you don't have to put it in the nodeserver directory, you can just put it in the directory you login to (home director) and then put in a config var. key = devlist value=/home/admin/{filename}. There are a lot of exception messages all the time getting bulb color and stuff, but seems to work. Home Assistant isn't any more performant ( i have it setup there too) as it also has to poll.

Just out of curiosity after you deleted and added node servers and such, donations a refresh on the mobile app and have it clean up the devices?

Just installed and discovery went fine. All statuses were updated on initial creation of nodes. Didn't have to redo any programs. Thanks!

I am getting states on startup. I removed all nodes and started over. If there is way to make the top level prefix configurable as it doesn't require a subscription per device, then I think it work well. My states represent what I see in MQTT explorer with the contact sensor gate not getting values for lock or obstruction so makes sense they are unknown in AC.

Interesting, I am using a mosquitto service on my docker cluster. Now I don't know if you are using it in dry contact mode or in version 1 or 2 mode, My gate is in contact mode and only shows availability and door values. I don't see anything in the json that indicates what mode it is in (for instance dry contact mode does not support a light or lockout. My lockout in AC never changes from Unknown no matter how many times I operate the door even though I do have a lock and it is locked it always shows unlocked. That may be because my garage door is an 8500 and uses v1 protocol.

Those statuses are always there if I disconnect and reconnect MQTT Explorer even before any elements are updated in MQTT. This is the case for all topic / sub-topic items in JRD-Automation top level topic. I can confirm in HA it pulls in the current state in the MQTT device when it subscribes to the Broker as I have status even before any devices have been controlled.

Not sure if anyone else is using manual add, but I can confirm this still works in the release. Cheers.

I don't know if I followed all that but for sure RATGDO allows you to set the topic prefix and you can change the discovery prefix. Mine is homeassistant for discovery as I didn't change it and you use it as well. The topic prefix is something you have to define in HA if you are using the MQTT plugin (UI discovery) with an external MQTT broker. There you define and can only define a single Topic Prefix to listen for. i had a bunch of other devices (weather, raspi stats) all using an external broker with a common prefix. It would seem that RATGO devices and your plugin support same format as tasmota. In my case my topic prefix is JRD-Automation. In HA i set that as the topic prefix and all devices show up under JRD-Automation as devices and their discovery definition are in home assistant. So in this case you have fixed the "broad topic prefix" to ratgdo/ under that are the devices There is no reason you couldn't have actually left the broad prefix at tasmotans/ as long as you setup the device to publish to that topic it doesn't matter if there are other devices in that topic does it? I changed the MQTT_TOPIC_PREFIX in the API.py file and discovery works just fine and only "Sees" the ratgo devices and adds them to the nodeserver. Home assistant for their MQTT plugin only sees a single topic_prefix but you can have all kind of devices under that topic. So in many ways the broad top level topic is arbitrary and is simply the thing that is subscribed to. I don't think I was proposing a subscription per device which is what it sounds like you are thinking the change I requested would require. So for clarity, I'm using the current plugin, changed it to use my existing top level prefix and it seems to see, find and report status for all the ratgo devices in that topic just as if that top level prefix had been what you had fixed at ratgdons/. Now one thing the plugin doesn't do is get current state when the plugin starts up and simply shows unknown for door state, obstruction and lockout . After the doo is operated it sees the state changes and updates, but obstruction stays unknown because nothing has triggered a change. You can see all states are set in the MQTT device data but the plugin still shows unknown in AC. So I don't think you need to support multiple subscriptions unless people want you to talk to multiple brokers and then you can just install the plugin more than once. As such (since I can see this is working), all that is needed is an ability to override the default top level prefix unless I am really missing something it would seem to be trivial, but as I said I didn't follow all of your response because some of it seemed to not make sense with what I see happening in the plugin already. Happy to beta test any work on this plugin. I have 3 RATGDO devices working with HA and in ISY now.