Hello. I just wanted to do a quick sanity check in case I am missing something.
I have started testing a simple “Sengled WiFi Smart Plug” which is matter certified (see Amazon.co.uk)
If I try and add the device directly to OH using the pairing code supplied it is not found.
If I add the device to Alexa first and then generate a secondary code from the Alexa app I can then add the plug to OpenHab using this secondary code.
I have read through this forum and can see mention of needing to commissiong some devices first using their native apps or Alexa etc - so I just wanted to check if this is expected behaviour?
Part of me expected it to work - i.e. using the original pairing code.
My concern is I also expose OH items back to Alexa for voice control, so now I will have the Sengled plug appear twice - once directly in Alexa (comissioned as a Matter device) and then the version I have added to OH and then exposed back.
I don’t think (although haven’t tried) I can delete the original from Alexa and for the OH version to keep working.
So just wondering - if everything I am seeing is expected and correct?
Will it be possible to directly pair a WiFi plug without needing Alexa (or other system) first? There was mention of an “app” being created.
Or is this a limitation of the Sengled plug - will other WiFi plugs work directly?
Hi, so for Wifi devices (or thread) like this you do need to use a mobile app (like Alexa, Google, Amazon, etcc) with bluetooth to pair first as those setup wifi as part of the process over bluetooth first before continuing over IP. Hopefully we will have this in our mobile app as well soon (i have something working now).
You can safely delete the device now directly in Alexa, or you can use openHAB to delete that Matter network (fabric) from the device, there are thing actions on the device that both list the connected fabrics of a device (look for one called “Amazon” and note its fabric #) , and another action that allows you to “unpair” from those. This will have no effect on the openHAB pairing. This is one of the strengths of Matter, that devices can join multiple fabrics independently.
Thank you for the confirmation. At least things are working as expected. I have deleted the Alexa instance now and, yes all continues to work.
Look forward to the update in the app to add devices in the future.
One final question for now - and it is a really minor point - in the gui - the item shows with question marks against device type. Is this expected also?
I probably need to look at the metadata associated with that channel (tags in the channel xml definition) , they may not be right, but it won’t affect functionality, just what icon is displayed by default.
This is not strictly OH related, but does anyone have any experience with Aqara Matter/Thread devices?
I’m having terrible trouble getting their Matter/Thread Motion Sensor provisioned via my Alexa Echo TBR. It always gets to the “Alexa is getting your device ready” stage before failing, normally with an error code RN002 but occasionally with an error code GS013. I need to provision them this way first to get them connected to the Thread network before I can add them to OH.
Initially I thought the device was faulty so returned it to Amazon and ordered a replacement, but the replacement does exactly the same thing.
I’ve tried raising a ticket with Aqara support, but to be frank, they have been less than helpful.
Any advice/tips/other experiences would be welcome.
Do you have any other thread devices that are working? My guess is that Alexa was able to initiate and talk to the device over bluetooth and give it the credentials needed for joining the TBR, and then waits for it to appear on your IP network as a IPV6 device, but never is able to find it to continue the process over IP. Not sure what the issue is as IPV6 should be working link locally from the TBR to the Echo as they are on the same device.
@digitaldan Yes, I have 5 Onvis Matter/Thread plugs all working fine via the Echo TBR so I’m as confident as I can be that the TBR and IPv6 etc are all fundamentally working.
I have connected an Aqara Motion and Light Sensor P2 (Matter) using Apple TV and HomePod as the Thread Border Router, running on openHAB 5.1.1.
The corresponding openHAB Thing is very unstable and frequently switches between ONLINE and ERROR states.
I am monitoring the Aqara Thread IPv6 address using an IPv6 ping via the network binding. The ping is always successful, but the round-trip time sometimes reaches up to 8 seconds.
Could this latency be the cause of the unstable Thing status?
Disabling and re-enabling the Thing is only very rarely successful.
However, restarting the binding using bundle:restart most of the time brings the Thing back ONLINE. In some cases, the Thing remains ONLINE for several hours, but at other times it starts flapping and fails again after only a few minutes.
So battery devices need to sleep and so the stack handles keep alive messages differently , we should be handling this , but let me check with the matter.js devs about this situation , there might be something we need to tweak , I might have to buy a few of these to test with . I assume a sleepy battery device will wake up if pinged , but could take a few seconds , of course this would cause battery drain , but I’m not 100% how pings work on these devices , I’ll try it on my thread lock tomorrow .
Hi Dan, I’m not sure this is related to sleep mode. The sensor continuously updates both illumination and motion detection, and in the Apple Home app the sensor data is always current.
For reasons unknown, the binding sometimes loses communication with the sensor. Once the Thing enters the ERROR state, it remains there until the Thing is disabled and re-enabled.
I currently run a rule every 10 minutes to bounce the Thing if it is in ERROR. Sometimes it returns to ONLINE afterward, but this is not reliable.
COMMUNICATION_ERROR
java.util.concurrent.TimeoutException: Request nodes:initializeNode timed out after 180 seconds
I’ve collected TRACE logs from the binding while the Thing is in the ERROR state, as well as TRACE logs from when the binding is restarted using bundle:refresh. I can share these logs if they help with the investigation.
Please let me know if there’s anything else I can test or any additional data that would be useful.
By the way, the binding is stable with my Shelly sensors, which use Matter over Wi-Fi with IPv4 addresses. The issue only appears with the Aqara sensor running Matter over Thread with IPv6.
Maybe not, but battery devices are always considered “sleepy” in matter, and have special requirements. You already have shown that where pings can sometimes take 8 seconds for a round trip, thats likely the device in low power mode. Yes, it sends data consistently, but is also constantly trying to return to low power mode. Its own detections wake it up instantly, but trying to wake it up from the matter controller over IP is not instant. We have a mechanism where we are constantly sending empty no-op messages to devices, which then respond with an ACK. This is used for a hearbeat and ultimately for the Thing’s ONLINE/OFFLINE status. This is done differently for sleepy devices, but my hunch is its related to this somehow, but i won’t know until i try it out. I also doubt this has anything to do with IPV6 vs IPV4 , other then thread will always use IPV6. When there are IPV6 issues its usually all or nothing, it works or it doesn’t at all.
I just amazon’d this sensor, will be here tomorrow, so i’ll have something to test with.
I actually rebased it yesterday and am testing today (the lock converter changed a lot since i opened that) , will probably get it submitted tonight or tomorrow.
I’ve also implemented IKEA Dirigera Hub and 2 window sensors Myggbett as well as one temp/hum sensor Timmerflotte, which are all Thread devices. In first step I connected the sensors to the Dirigera hub via IKEA Smart Home app. Then I installed in Openhab 5.1.0 the Matter Binding followed by creation of the controller thing. I’m using the Dirigera hub as Matter client, not as Matter bridge. In the controller thing, I added each sensor via “pair a matter device” and by searching for the pairing code for each device which I created before with the IKEA app (a new pairing code needs to be created as the initial one was already used to pair with the IKEA hub). Everything worked well, devices were found in the scan, things were created and added to the inbox and went online. Then I created the corresponding items from the channels offered.
The Timmerflotte temp/hum works and frequently updates temperature and humidity items. Instead, the 2 window sensors have problems and status updates are with significant delays between 5 and 20 mins. In the IKEA app status changes (removing the magnet) are shown immediately all the time without any delay. Thus, there seems to be something in the connectivity between Dirigera Hub and Matter Binding.
What I see from time-2-time in the log is that a window sensor thing is going from Online to Offline(Communciation Error):Node reconnecting, then from Offline(Communication Error):Node reconnecting to Unknown:waiting for data. Then the contact change made few minutes before changes the item state and the thing goes online. When I change the sensor states (magnet) right after the thing went online in the log, the following item changes also come without any delay. See log excerpt below. But then disconnects after some time and changes come again with big delays.
14:43:37.986INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node Reconnectinginfo_circle
14:43:41.239INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from OFFLINE (COMMUNICATION_ERROR): Node Reconnecting to UNKNOWN: Waiting for data
14:44:14.924INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)
14:44:34.401INFOopenhab.event.ThingStatusInfoChangedEventThing 'matter:node:51xxxxx4f0:528xxxxxxxxxxx422' changed from UNKNOWN: Waiting for data to ONLINE
14:45:20.990INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from ON to OFF (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)
14:45:27.247INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)
14:45:33.495INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from ON to OFF (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)
14:45:37.036INFOopenhab.event.ItemStateChangedEventItem 'Fenster_Buero_Ost_Kontakt' changed from OFF to ON (source: org.openhab.core.thing$matter:node:51xxxxx4f0:528xxxxxxxxxxx422:1#booleanstate-statevalue)
Just to add: Also the Timmerflotte temp/hum sensor shows strange behaviour in the log, although it frequently updates item states:
16:23:00.910 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from ONLINE to OFFLINE(COMMUNICATION_ERROR): Node Reconnecting
16:23:13.376 INFO openhab.event.ItemStateChangedEvent Item 'Luftfeuchte_Bad' changed from 50.82 to 50.79 (source:org.openhab.core.thing$matter:node:51xxxxx4f0:1266xxxxxxxxxx960:2#relativehumiditymeasurement-measuredvalue)
16:23:14.400 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from OFFLINE(COMMUNICATION_ERROR): Node Reconnecting to UNKNOWN: Waiting for data
16:24:08.582 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from UNKNOWN: Waiting for data to ONLINE
16:28:25.628 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from ONLINE to OFFLINE(COMMUNICATION_ERROR): Node Reconnecting
16:28:35.352 INFO openhab.event.ItemStateChangedEvent Item 'Luftfeuchte_Bad' changed from 50.79 to 50.75 (source:org.openhab.core.thing$matter:node:51xxxxx4f0:1266xxxxxxxxxx960:2#relativehumiditymeasurement-measuredvalue)
16:28:36.531 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from OFFLINE(COMMUNICATION_ERROR): Node Reconnecting to UNKNOWN: Waiting for data
16:29:30.559 INFO openhab.event.ThingStatusInfoChangedEvent Thing 'matter:node:51xxxxx4f0:1266xxxxxxxxxx960' changed from UNKNOWN: Waiting for data to ONLINE
It seems the problem is the Dirigera as Thread Border Router. I’ve found also github issue on HomeAssistant project where people report same problem with Dirigera and Matter.
I tried to monitor the network traffic and it seems that after some inactivity timeout between sensor and OH (in my case 2 minutes) the sensor (or Dirigera) stops sending the updates and no more network traffic is comming until the sensor is reinitialized by Matter binding.
I lent one of my MYGGBETT sensors to a colleague who uses Apple HomePod as TBR and he reports that for him the MYGGBETT works fine with Matter binding.
So it could be a bug in Dirigera Thread Border Router. I’m going to build an ESP32 OTBR so I can at least use those MYGGBETT and MYGGSPRAY sensors I’ve bought.
I called it “Matter Test” some month’s ago.
I cannot remember or find any config where I set these name
I uninstalled the binding and removed all the matter config stuff I could find, but it is still named ‘Matter Test’ in e.g. the Apple Home as other connected Service.. (of cause I removed all connections within Home before readding them).
Are we talking about the matter bridge service, so exporting openHAB items as matter devices to Apple through tagging, or the Matter Controller, so controlling other matter enabled devices? There are no “Things” like your example if exporting items using the matter bridge service (which is not the same as a openAHB bridge Thing type, Matter uses this term as well)
I also don’t understand what a esp32 or homekit has to do with this?
