Look at what contains the inbox (JSON), strange unicode characters in label.
Maybe they have to be filtered ?
I added logs in class MatterDiscoveryService.
12:48:57.512 [DEBUG] [rnal.discovery.MatterDiscoveryService] - discoverThing: matter:node:openhab:15928341705496205474 matter:controller:openhab {}
12:48:57.517 [DEBUG] [rnal.discovery.MatterDiscoveryService] - initial label 14 Matter Device:
12:48:57.521 [DEBUG] [rnal.discovery.MatterDiscoveryService] - vendorName 9 SwitchBot
12:48:57.524 [DEBUG] [rnal.discovery.MatterDiscoveryService] - productName 15 SwitchBot Hub 2
12:48:57.528 [DEBUG] [rnal.discovery.MatterDiscoveryService] - nodeLabel 32
12:48:57.531 [DEBUG] [rnal.discovery.MatterDiscoveryService] - fixedLabel 0
12:48:57.535 [DEBUG] [rnal.discovery.MatterDiscoveryService] - final label 47 Matter Device:
The problem is that there is a strange value in nodeLabel but you have everything needed in vendorName / productName.
You should apply a filter on nodeLabel / vendorName / productName to erase unexpected charcaters. Then in my case, nodeLabel will then be empty and your code will then use vendorName / productName. This would lead in my case to āMatter Device: SwitchBot SwitchBot Hub 2ā. An additional improvement would be to not include the vendor name in case the product name starts with the vendor name, so that I will finally get āMatter Device: SwitchBot Hub 2ā.
Considering my capture in my previous message, nodeLabel contains value 0 32 times.
Maybe simply applying trim() would solve the issue?
I have mixed results with this version (Big Ass Fans). Things were discovered and ONLINE, but I am unable to command the fans. Items are updated in OH when changed using fan remote or BAF app, but no control from OH. The one thing I did during the process not mentioned in your post was I turned OFF Decommission Nodes On Delete in the matter controller (seemed appropriate). Tried deleting and adding the things again, and power cycled the fans. No change.
Logs seem normal
2024-12-05 05:51:02.177 [DEBUG] [.controller.devices.types.DeviceType] - Handling command for channel: matter:node:7d7a34ca7f:17881113316361280588:1#fancontrol-percent
2024-12-05 05:51:06.052 [DEBUG] [.controller.devices.types.DeviceType] - Handling command for channel: matter:node:7d7a34ca7f:17881113316361280588:1#fancontrol-percent
Also, saving a thing sets status to UNKNOWN, and that doesnāt resolve until an OH restart.
I need your JSON file to speed up fixing thisā¦ I am attempting to pull the endpoint name from a few different clusters. Endpoints contain a few different ālabelā clusters, there is the BasicInformationCluster and BridgedDeviceBasicInformationCluster which offer vendor name, product name and a node label. Unfortunately is kinda up to the manufacturer to put sane values there. There is also a FixedLabelCluster which offers key=value pairs of labels for the endpoint, as well as a UserLabelCluster which is similar (but user provided). I cycle through all of these if they exist trying to build a logical endpoint name. I know this is something i need to come back to once i have enough examples of real world devices out there. Its not clear to me how manufactuers are using these togeather.
Just reading your second post, iāll take a look at that, I only trim the final value, so yes i could see iām matching on these null characters, although iām still curious what the JSON looks like to know if i should also be fixing my node serialization logic on the typescript side to prevent this from even getting to openHAB
As previously mentioned, the problem in my case is in nodeLabel contains 32 0 !! That is not a valid string.
I see that in addition to discovery code, this is also to be considered in MatterBaseThingHandler.updateEndpointInternal
Thanks, iāll look at fixing that. You can also just disable/enable the thing from the UI and that will bring it back online.
Ok, yes, i think i can guess the issue. Now that we have channel groups, i need to update the logic to pull the channel id without the group id in it when matching channels. Iāll update that today, its probably affecting a few device types that have multiple channels.
Thats a very odd node label, do you know what the significance is there, why the vendor may have set that (maybe you have context, iām not familiar with that hardware) ? I was hoping Node label would be the primary endpoint label (sounds like it should be) .
Our underlying matter library is failing to process the response data due to formatting issues, its expecting something to be there thats not. My guess is this is a tasmota issue, but i canāt be certain just yet. I would need to run this by the matter.js devs for help, its at a low level of the protocol i donāt usually play in.
Maybe a bug somewhere ?
Maybe a bug in Switchbot firmware ? Bad understanding of the standard ?
But we can try to be robust and handle this case. You already tried to do it as you handle the case of an empty nodeLabel.
Dan, I sent to you the full JSON.
Here is a small extract showing what is the problem:
Donāt know if the problem is the tools we are using / developing or in Switchbot device itself.
I now see unstability for all my Matter devices, not only the Tapo smart bulb.
The Tapo Plug:
19:15:17.857 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:node:openhab:priseTapo1' changed from ONLINE to UNKNOWN (NOT_YET_READY): Node Reconnecting
19:15:18.669 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:node:openhab:priseTapo1' changed from UNKNOWN (NOT_YET_READY): Node Reconnecting to ONLINE
The Switchbot Hub 2:
19:15:24.523 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:node:openhab:hubSwitchbot' changed from ONLINE to UNKNOWN (NOT_YET_READY): Node Reconnecting
19:15:24.529 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:boutons' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
19:15:24.532 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:temperature' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
19:15:24.536 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:humidite' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
...
19:15:28.947 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:node:openhab:hubSwitchbot' changed from UNKNOWN (NOT_YET_READY): Node Reconnecting to ONLINE
19:15:28.954 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:temperature' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
19:15:28.970 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:humidite' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
19:15:28.984 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'matter:bridge-endpoint:openhab:hubSwitchbot:boutons' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
...
It is in my opinion clearly the most critical issue with Matter.
It is repeated every few minutes.
I thought it was a bug in Tapo Smart Bulb, I have now a big doubt. It looks rather a bug in the binding (or matter.js).
Just for information, I noticed no improvement for the Tapo Smart bulb if I placed it at 5 meters from my WiFi router.
Edit: restarting OH seems to resolve this issue for these two Matter devices.Strange and big mistery. There is a bug somewhere but it does not trigger always.
So i would need to see the logs from matter.js as well to understand the issue.
Yeah, given your JSON data, i would say the Switchbot is not using the matter standard as it should (like no labels on bridged endpoints!).
I just posted a new jar which i think will fix this, let me know how it goes.
That fixed it. All is working now.
Additionally I picked up a TP-Link plug on a Black Friday deal to test and it connected fine. Thanks for the work on this.
Dan, just outstanding job
How to enable matter.js logs?
Maybe I setup Matter in Switchbot app before setting labels.
I could retry Matter setup.
Edit: does not change anything.
Iāll work on this some point today, i think i have a good idea on a fallback method for labels that should work pretty well in this case, its actually a good thing to have devices like this early to test with.