@digitaldan I also have some ideas how the Matter binding in OpenHAB could be improved in a future release:
Controller:
I think it would make sense if the controller thing in OpenHAB also had settings for the adminFabricId and the adminFabricLabel. I noticed that when the same adminFabricLabel is used to connect to a bridge, the label in the fabric of the second paired controller is empty because the label also has to be unique on the bridge for some reason.
The adminFabricId should only be configurable when adding a new controller because it cannot be changed afterwards. But the adminFabricLabel can be changed after the controller is added with the method updateFabricLabel of the CommissioningController. This also communicates the new label to each connected node.
Bridge:
I think it make more sense if the bridge in OpenHAB would also be represented by a thing, just like the controller. This way multiple bridges could be added each with separate item and group filters, just like in the HomeAssistant Matter Hub. This way various subsets of items could be exposed to each external system. And also you would have the more advanced elements in the Main UI where you could expose Information about the bridge.
I think adding a fabric label makes sense, my gut is not to do fabric id as the matter code will now use a random id using crypto.randomBigInt, but i need to think about it some more before i make a decision there. Iām not sure what the use case would be for that other then making it more complicated for users.
Things do not normally, or ever interact with items, as far as i know, that would be a big violation of the architecture of openHAB. This is why we have IO bindings that do not operate on things, but instead can interact with the Item registry. I would have to think about how we want to support multiple bridges, but i think it would probably be done with how you tag items, so adding an optional bridge identifier. I have not given this much thought since its not super high on my todo list.
Hi, since one device wasnāt already supported by nativ OH binding, I started to use Matter binding instead.
I have that device as a node together with a Matter controller running, 3 channels, no further telemetric data and also made the Matter Bridge starting, converting one of the homekit= items converting to matter=.
My question is now, with Homekit it was crucial to keep the /srv/openhab-userdata/jsondb/homekit.json save, in case of restore, rebuild, image or device change. That prevented to have to setup and sort again everything from scratch in Apple Home (App).
Is there a similar file out side OH config files necessary to save for the Matter Bridge function in OH?
I have another question about the level control (brightness) of lights. I found out that there is a difference in the on/off behaviour of the DimmableLight and the ColorLight in OpenHAB:
On the controller side I have two methods moveToLevel and and moveToLevelWithOnOff.
When I control a ColorLight item I can use either one of them to turn the light off and on.
When I control a DimmableLight item I can use either one of them to turn the light off, but none of the methods work to turn the light on. I even get a timeout when trying to turn the light on because there is no response from OpenHAB. But the message is received by OpenHAB, I can see that in the log.
Is this difference in behaviour intentional or is this a bug?
I also noticed that on both moveToLevel methods is an executeIfOff option in optionsMask and optionsOverride on the controller side, but they also donāt seem to make any difference. Can you explain what those options are for and if they are even implemented in OpenHAB?
Itās kind of crucial to save and restore all the files in that jsondb folder. Thatās where almost all your configs created through the REST API get saved, and some bindings save stuff there too including Matter and MQTT.
There appears to be other data related to the Matter binding saved to $OH_USERDATA/config/org/openhab/matter.config. That folder is where all the bindings put the add-on configurations (i.e. the stuff that cannot be configured through a Thing).
And like many other add-ons, the Matter binding creates itās own folder in $OH_USERDATA: i.e. $OH_USERDATA/matter.
I donāt really know what is in there but they look important.
In general, you want to save everything in $OH_USERDATA except for cache and tmp to get a full backup. to restore somewhere else.
Thatās most probably right, I just saved from time to time homekit.json ā¦
Already searched the openHABian system for any files related to Matter. I just find my own created .things files and the 2 above mentioned in JSON folder ā¦
Converted a few devices from Homekit to Matter. Switches (actuators) are straigth forward. My Temperature & Humidity sensors also, easier and more straight forward compared to Homekit.
But I struggle with Thermostat head I used to test Matter, its kind of available in Apple Home, but looks different to the Homekit mapped ones and I miss documention. Mapping possibilities, what is runningmode, systemmode and looks again like its designed along the anglo-american world ā¦
And I have seen Matter does accept photovoltaik (solar) systems & battery storage, but the OH Matter bridge doesnāt seem to offer the possibility to map that into Matter ā¦ those devices will be the very last ones ever speaking nativ Matter.
I would have to check, but iām pretty sure moving a level from off to > 0 will turn a Color item on (we usually just send this level raw to the color item), although iām fairly sure moveToLevel does not turn a light on by it self in the matter spec officially, unlike openHAB, Level and OnOff state are separate clusters (although are related, one of the few special cases in matter that are) . So it could be compliant controllers always send ON first before changing level. matter.js handles much of the logic for the bridge features, coordinating the āwithOffā versions of commands, the openHAB code gets called back with OnOff, CurrentLevel, Current Saturation and Temp in Mirids if i remember right (iām assuming you are talking about the bridge device here).
Iām also trying to understand how exacly Matter handles this. I guess the bridge could inform controllers with the executeIfOff flag how it handles the on/off change over the level. The OpenHAB bridge sends this flag as false for all ColorLight and LevelLight devices.
I found out where the addon is setting the brightness for both types of lights:
The difference is that on the DimmableLight there is a check if the light is currently on. If it is off nothing happens, not even an error is returned. This check does not exist on the ColorLight.
I also found this withOnOff attribute in the matter-js implementation of OpenHAB. As far as Iāve seen the moveToLevel and moveToLevelWithOnOffare completely separate commands in the Matter protocol. So they could also be handled differently.
If the executeIfOff is indeed to inform controllers how the on/off is handled I would suggest that OpenHab setās this flag to true for every light, because the default behaviour in OH is to turn lights on and off with a brightness slider. But at least the behaviour should be consistent for both light types and there should be errors returned if a command was not accepted.
Or maybe even better, just make different decisions based on the withOnOff attribute. If it is true just set the brightness every time and if it is false return an error if the light is in the wrong on/off state.
By the way, I just released the source code if my Integration for the Remote 3 here:
I currently also send the on/off command on level changes to fix this. You can take a look at how I currently handle the brightness here.
The only problem I had so far is that sometimes the on/off state is not perfectly in sync and then the on/off command is not sent and this could result in an error.
No problem, looking at the logs the device is not responding to our matter discovery broadcast over MDNS, Apple would also be using the exact same mechanism, so either something is blocking that, the device is faulty, or the pairing code is not correct (or expired). The Leviton app uses a TCP/Proprietary protocol for communication and likely traditional mdns for discovery (or upnp, not sure), so at least TCP connectivity is working, it might try the last known IPV4 address if mdns is not, so its not clear if thats working. Since Apple is also having this issue (and its great you had this also to test with), its likely something network, device, or code related. Since MDNS disco is not detecting anything, we donāt try a IPV6 connection yet, so its probably not IPV6 related.
Is the device on the latest firmware ? In the app, there is a setting menu for the device that lets you check, although I donāt think they have released anything lately. I occasionally have to reset one of my Levitons (i have 20+ of them), but its seems to be pretty rare over the last 6 months, i have also noticed sometimes they just pop back on the network after a few days offline on their own
Hi @digitaldan
It appears the issue with my Matter devices is neither the Matter protocol, the device, nor OH
I switched my ISP to AT&T Fiber.
Iām running Unifi DMP with Network 9.5.21
AT&T advertises a prefix delegation of /60
Unifi requests a PD /60 and gets a single /64 (NOT RFC compliant by AT&T)
AT&T not only does not delegate a PD /60, if the router makes multiple PD /64 requests, AT&T will only honor 8 of the 16 available in a /60
Unifi gives the prefix to the first vlan it feels like.
So AT&T ipv6 support is a steaming pile of ā¦
There are various horrible workarounds out there, but I want standards compliance from my vendors.
I also have some questions regarding the matter binding and moved my topic into this thread
I just updated to 5.0.2 and tried the matter binding together with my iPhone HomeKit.
It is just awesome work you did.
Thank you so much.
Two things made me a little bit confused.
I have a couple of z wave devices for thermostat for example. When I add the metadata for matter than there is a mapping.(see #1) This mapping is later on complained by the matter binding.(see #3). So this does not work.
I tried the fixed labels tag. But somehow they are not taken into consideration by apples iPhone. ā When I pair the matter binding with the homekit within iphone, the rooms I assigned in openhab are not considered. Everything goes into Standard room. Nevertheless, the labes are considered.
That is what I can tell so far I try to get some screenshots to show what I am trying to explain
Error: org.openhab.binding.matter.internal.client.MatterRequestException: Error: Error initializing oh-bridge.aggregator.ZWave_Node_021.thermostat Cause: Error: Validating oh-bridge.aggregator.ZWave_Node_021.thermostat.state.systemMode: Conformance āAUTOā: Matter does not allow enum value Auto
I need some advice on how to correct from not following the upgrade instructions properly. I have 2 OH systems, and on one of them I followed the upgrade instructions from the beta Matter binding exactly. But on the other OH system I delayed, forgot about this, and then updated from an earlier OH5 milestone build to the OH5 release without following the Matter upgrade from beta instructions. So, what do I need to do now to correct this? I donāt have a lot of Matter devices connected - should I delete everything and re-add? Something else?
