If you could put the binding in TRACE mode and PM the logs when you have occupancy events that would help. Also are you on the latest version of the binding? And are you manually installing or installing from the marketplace? Make sure there are not two versions of the binding installed (like one left over in addons, and one installed from the marketplace).
I moved to the Marketplace version. I will update from the Marketplace today. If problem persists I will PM the logs.
Hi! I read the readme, did what was in it but no luck.
I am running OH on an RPi4 with openhabian (4.3.2) and the latest Matter Binding.
My matter bridge at home is an Apple TV 4K. I have an EVE energy plug which is already connected to the ATV.
So I go to the Home App on my iPhone, go to the plug settings and Turn on the Pairing Mode. This gives me a new setup code. I type this code in the Scan input field, press scan and nothing is found.
The only thing I am not sure of is my IPv6 setup (not a lot of knowledge there, sorry).
Anyone has some pointers?
You mentioned you read the README, but did you follow enabling-ipv6-thread-connectivity-on-linux-hosts ? Can you can confirm this is working and those values are set (it specifically mentions raspberry pi)?
Also logs in TRACE mode would be helpful when you scan.
That seems to be a ābugā Apple is having as soon as multiple Border routers are in te network ā¦ then such strange stuff sometimes happens ā¦ I do not know any way to prevent that beside not using apple with multiple Border routers (aka multiple own network instances So Thread repeaters and such is fine but BR
FYI i have new version of the binding up that fixes Occupancy Sensing, which i recently broke in a refactoring.
Hi Dan!
Yes I did follow the ipv6 entries in the readme section, edited the 2 files too. This morning I saw that the value for net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen was not kept though. So I reset it to 64 again and did 2 scans
pverhoye-matter.log (54.6 KB)
logfile.csv.log (85.2 KB)
Thanks @pverhoye , thatās very helpful. @Apollon77 this log file is interesting, it seems to fail at commissioning step 7.1 . Is this Apple TV Thread related or do you think its something else?
As commissioning fails in step 7.1 it seems that your device isnāt able to store the certificate for the openHAB fabric. This seems to be the same problem as I had at first when I paired my device with too many controllers.
Did you already paired your device with five controllers which is the standard maximum for matter devices? You can see already paired controllers for your device with iOS in settings ā general ā matter-devices ā āyour deviceā. You can also delete and unpair them there. When there are four controllers listed you have already five paired controllers because they donāt list themselve there (Apple Keychain is an extra controller).
Hi!
I have 4 matter devices connected to my ATV and 3 of them are connected to only the ATV.
The 4th one, the one I was testing was for some reason already added to āanother Homeā.
So I removed it and did another scan.
And it was found! In the meantime it was added to OH, linked and is working as expected.
The eve device is an outlet. In OH it only shows as an ON/OFF and no other channels. Does this mean I can only turn it on/off? Because in the eve app you can for example also see the amount of energy used among other thingsā¦ just asking 
Thanks already for your help!
That was an excellent observation @lrabius , thank you!. It would be great if we could catch the step the error fails at and give a better message to the user. Iāll put that on the list.
Great !
It sounds like this device has a non standard vendor cluster for this that is not part of the official matter spec. I may end up adding this as a one off at some point since its a popular device.
BTW the battery percentage is shown in Alexa, SmartThings and Apple Home. So there must be another cluster or they all have implemented this specific Eve cluster. Maybe the specific cluster could also be the heating schedule or something like that?
Looking at the JSON data from my device again there is this descriptor cluster on endpoint 0
{""Descriptor"":{""id"":29,""name"":""Descriptor"",""deviceTypeList"":[{""deviceType"":18,""revision"":1},{""deviceType"":17,""revision"":1},{""deviceType"":22,""revision"":2}],""serverList"":[29,31,40,42,47,48,49,50,51,52,53,56,60,62,63,70,323615744],""clientList"":[41],""partsList"":[1],""clusterRevision"":2,""featureMap"":{""tagList"":false},""attributeList"":[0,1,2,3,65528,65529,65531,65532,65533],""acceptedCommandList"":[],""generatedCommandList"":[]}
with device type power source (17) and server cluster power source (47) which should support the remaining battery percentage and seems to be already implemented by this binding. But the power source cluster doesnāt show up in the rest of the data. Does the device sends wrong data for that cluster and it got skipped or should the JSON data log contain every supported cluster of a device?
Ah, good catch again. That is unusual, every device i have seen to date puts these types of clusters on a non root endpoint, these seem to be attached to the root. I can kinda see this making sense logically, but i donāt think its standard procedure in the matter ecosystem to date.
I did recently put a filter on the clusters we try subscribing to on the Root endpoint do to issues with some cluster that i canāt remember ( @Apollon77 this may interest you since i borrowed this list from you edit, actually not an issue in this case )
Iāll add the power related cluster to this allowed filter and we can see if this just starts working (it should). I may need to invert this filter from an allowed list to a disallowed list, but that will take a bit of time (since i canāt remember which clusters were an issue) .
Actually looking at it more and reading the spec, the power source cluster may be pretty common on the root and should be part of our allowed list.
I have an updated jar posted if you want to give it a shot.
Thanks for your help! The battery channels are working now.
Error 9 on commissioning means that this bridge already is commissioned to this fabric ā¦ Sooo ā¦ So is the device already added to OpenHab ?
The next matter,js Version will make the error message more clear.
Interesting, so maybe the device actually commissioned in an earlier attempt, but failed towards the very end and did not complete in mater.js ? In that case, i guessing then that using another paired controller to remove the fabric, or hard resetting the device is the only option to fix then ?
Yes ā¦ or is is just commissioned and user forgot that it is already But yes using e.g. a Controller app where it might be paired too and remove the OpenHab fabric is the way to go
Oh I saw this when we were discussing about the thermostat! Remember that the cluster had a difference somewhere?
That was the same behavior, it would get adopted, I could see the logs , google home showed the new fabric too, but OpenHAB did not show anything in the inbox.
Iām using the binding as a bridge with Alexa. When using the Alexa app, trying to turn on a light to a certain brightness doesnāt work and it just turns on to full brightness. Once the light is on, setting it to a brightness works ok.
openhab.log (13.4 KB)
In the log Iāve spotted skipping sending bridge event for levelControl.currentLevel = 112 which might be relevent.