Dan, can you please move to 0.11.8? it looks like they fixed a bug in LevelControl few hours ago.
Are you talking about bridge or controller functionality ? I have not noticed any issues on my side.
I’m aware of the change, but it does not affect us, it was simply adding level control command options to bridged devices, which we don’t use. I usually update to the latest version with 24 hours of them releasing in my own branch, test, and eventually push it up when i’m happy with it.
Ok, it is working again.
This light is just unstable.
It is now at less than 5 meters from my WiFi router. Let see if this is better.
Hi @digitaldan
I updated the jar today to use use the bridge mode. It works fine. After that I m trying to add new matter device in OH using the Discovery steps. But nothing happends.
This is I see in logs
2024-11-30 22:02:11.720 [DEBUG] [r.internal.handler.ControllerHandler] - refresh
2024-11-30 22:02:11.724 [DEBUG] [nternal.client.MatterWebsocketClient] - sendMessage: {"id":"c2114d76-74ff-49ac-b99e-ec3c65f9f7d2","namespace":"nodes","function":"listNodes","args":[]}
2024-11-30 22:02:11.737 [DEBUG] [nternal.client.MatterWebsocketClient] - onWebSocketText {"type":"response","message":{"type":"resultSuccess","id":"c2114d76-74ff-49ac-b99e-ec3c65f9f7d2","result":[],"error":"undefined"}}
2024-11-30 22:02:11.740 [DEBUG] [nternal.client.MatterWebsocketClient] - result type: resultSuccess
2024-11-30 22:02:11.742 [DEBUG] [r.internal.handler.ControllerHandler] - refresh done
2024-11-30 22:02:11.744 [DEBUG] [nal.discovery.MatterDiscoveryService] - startScan complete
Anything I m missing after update. I also did the reset of the Matter binding.
I m on openHAB 4.1.2
As stated at the top of the README, you need to be on recent versions of 4.3 milestone builds, this will allow you to enter the pairing code during discovery.
2 Likes
thank you for the quick reply.
Regarding pairing of Switchbot Hub 2, would it be possible to have name having more meaning to differentiate endpoints ?
It is the case of a device (same node) with several endpoints, one for temperature, one for humidity, …
For the humidity endpoint, I am surprised that the proposed number dimension for the item is temperature.
Maybe it is the default proposed by Main UI for any Number item ?
I tried to link to a Number without dimension and to a Number dimensionless but in both cases the value is 0.5% instead of 48.0%. Value is correct in Google Home.
The problem could be at this line (why do you divide the value by 100?):
Regarding the temperature endpoint, it seems to work well:
OH version 4.3.0.M4
Matter Plugin 4.3.0-SNAPSHOT downloaded from GitHub matter-v1 tag
I installed the Leviton D26HD dimmer and My Leviton app.
I upgraded the dimmer firmware to 2.1.25 to support matter
I successfully setup the OH Matter plugin
I successfully discovered the Leviton D26HD and setup the only Channel with an Item using defaults
OH can control the dimmer
I added the Leviton Dimmer to Apple Home using the QR code generated by OH
Both OH and Apple Home can control the dimmer and state changes made in one platform are reflected in the other.
Now the differences
Apple Home and My Leviton apps, the light level changes with a gradual transition
OH the light level changes with a snap transition
Is there a way to configure the OH transitions?
Awesome work!
The Hub 2 can also expose 2 other endpoints, each of them with such channel:
Switchbot calls that “ON/OFF Button”. It certainly is in relation with the OFF button and the ON button present on the hub. But it is only a number with value “Position 1” for both of them in openHAB.
I am not sure if I can just receive triggering information when these buttons are pressed on the hub or if I can also trigger the action behind these buttons from openHAB using this channel ?
Here is the interesting cluster (the same for both endpoints) with its “momentarySwitch” feature set to true:
Here are logs when I click on the first button:
23:56:45.259 [DEBUG] [internal.client.MatterWebsocketClient] - onWebSocketText {"type":"event","message":{"type":"eventTriggered","data":{"path":{"nodeId":"15928341705496205474","endpointId":6,"clusterId":59,"eventId":1,"eventName":"initialPress"},"events":[{"path":"undefined","eventNumber":"65550","priority":1,"systemTimestamp":14008943,"data":{"newPosition":1}}]}}}
23:56:45.267 [DEBUG] [internal.client.MatterWebsocketClient] - eventTriggered message {"path":{"nodeId":"15928341705496205474","endpointId":6,"clusterId":59,"eventId":1,"eventName":"initialPress"},"events":[{"path":"undefined","eventNumber":"65550","priority":1,"systemTimestamp":14008943,"data":{"newPosition":1}}]}
23:56:45.275 [INFO ] [openhab.event.ChannelTriggeredEvent ] - matter:endpoint:openhab:15928341705496205474_6:switch-initialpress triggered {"newPosition":1.0}
and the second button:
23:56:47.978 [DEBUG] [internal.client.MatterWebsocketClient] - onWebSocketText {"type":"event","message":{"type":"eventTriggered","data":{"path":{"nodeId":"15928341705496205474","endpointId":5,"clusterId":59,"eventId":1,"eventName":"initialPress"},"events":[{"path":"undefined","eventNumber":"65551","priority":1,"systemTimestamp":14011663,"data":{"newPosition":1}}]}}}
23:56:47.985 [DEBUG] [internal.client.MatterWebsocketClient] - eventTriggered message {"path":{"nodeId":"15928341705496205474","endpointId":5,"clusterId":59,"eventId":1,"eventName":"initialPress"},"events":[{"path":"undefined","eventNumber":"65551","priority":1,"systemTimestamp":14011663,"data":{"newPosition":1}}]}
23:56:47.992 [INFO ] [openhab.event.ChannelTriggeredEvent ] - matter:endpoint:openhab:15928341705496205474_5:switch-initialpress triggered {"newPosition":1.0}
I see this trigger channel is triggered at this line. The problem is that this channel “switch-initialpress” does not exist I believe for this thing.
I have also 2 other endpoints that are discovered by openHAB but none of them is providing channels. Dan, I will send to you the big JSON.
Dan, I have edited my messages.
IDK, the channel xml has this as just Number type.
b/c matter emits this as a value of 0-10000, similar to other measurements, where 10000 == 100%
I’ll take a look at the JSON, i think that cluster converter probably needs a little bit of tweaking to map to openHAB correctly.
Well, i will release something tomorrow which is going to alter this quite a bit, but i am trying to assist in adding any labels to the channels if they exist (the code is already done) .
I am removing the concept of an Endpoint thing. Instead we will have a Node thing. With mappings like so:
Matter Node → openHAB Node
Matter Endpoint → openHAB Node → Endpoint channel group
Matter Attribute → openHAB Node → Endpoint channel group → channel
For Matter bridged Endpoints (like ikea, hue, etc…) , this will create a new Thing called a bridge-endpoint which will be a child of the node thing, they have their own reachability status (online/offline), so warrant their own thing (plus would be unwieldy as additional channel groups)
Matter Bridge Endpoint → openHAB Node → openHAB Bridge Endpoint
Both Node and BridgeEndpoint support the same channel-group → channel structure, including nested children, this will allow for support of whats called ‘compose’ devices, or endpoints with child endpoints of both regular endpoints and also bridged endpoints.
This of course will require users to remap channels to items (and recreate all the things), but will not require users to have to re pair any devices (so long as they recreate the controller thing with the same name/id)
I’ll look over the issues you mentioned here more in depth tomorrow once i take a breather from the refactoring today.
I will provide logs tomorrow.
As the value is properly displayed in Google Home, it is probably not a bug in Switchbot firmware but more probably a bug in the binding.
I am sure that the channel has in fact two options, “Position 0” and “Position 1”. I am just not sure what matchs each position… I don’t know if it is supposed to be a read-only channel or a writeable channel ? We can’t change the value of this channel in Main UI by selecting one of the available options because it is a Number channel and Main UI is rather displaying the chart when you click on it. I see that you did not build command options but only state options and the handleCommand method is empty, so this lets me think this channel is supposed to be read-only. Is it correct ? Or is it just not yet implemented ?
By the way, the main purpose in the case of the Switchbot hub 2 is to know when each of the two buttons are “tapped” and this will be working through the trigger channel. We just need to have this channel created by the binding.
Here is the log for the humidity cluster:
12:23:32.222 [TRACE] [internal.client.MatterWebsocketClient] - Cluster RelativeHumidityMeasurement={"id":1029,"name":"RelativeHumidityMeasurement","measuredValue":5400,"minMeasuredValue":null,"maxMeasuredValue":null,"clusterRevision":3,"featureMap":{},"attributeList":[65528,65529,65531,65532,65533,0,1,2],"acceptedCommandList":[],"generatedCommandList":[]}
measuredValue is 5400 so it is as you expected. If we divide by 100, it leads to the expected 54.
Why do I finally get a displayed value of 0.54% instead of 54%? A problem with PercentType ? Should DecimalType be rather used ?
I am also asking myself if you should not consider a Number:Dimensionless for this channel.
I set my humidity endpoints to Number, Dimensionless(one), and unit one. No need for State Description. Works well. Item list is off by a factor of 100, but every where else it is correct, including the % sign.
1 Like
The way to fix the humidity problem (values divided by 100) is to replace this method:
by
private DecimalType humidityToPercent(Number number) {
int value = number.intValue();
return new DecimalType(value == 0 ? 0 : value / 100);
}
that is using DecimalType instead of PercentType.
Edit: a rounding could also be applied instead of a truncate to the lower integer.
It then immediately works well either with Number item or Number:Dimensionless item.
3 Likes
Please Read this before upgrading to the latest Jar!!!
I have done a rather large refactor of the structure of things. Having a Thing per endpoint was not going to be a good long term solution.
Before installing the new jar its very important to follow these steps to avoid having to have to reset and pair the physical devices again.
- Write down the Controller ‘id’ of your controller (not the label) , we will need this to recreate the controller thing
- delete all the Endpoint things from the MainUI.
- delete the Controller thing (you wrote down the id of this, right?)
- install the new jar
- Create the controller thing from the main UI, give it the same ID as before
- In the main UI scan for new matter things without a code, this will pick up the already paired devices.
The reason this works is we are not destroying the matter fabric files when a controller is deleted (yet), so if you create a controller with the same id, it will pick up the existing matter network and paired devices. Very handy when testing.
Now, for the changes…
There is no longer a Endpoint thing, this has been replaced with a Node thing, which maps 1:1 with a Matter Node.
Endpoints are now Channel Groups on the Node. Many simple devices may only have 1 channel group right now (endpoint 1), but that will change as we start supporting Diagnostic clusters which will show up as another endpoint (endpoint 0).
Here’s one of my more complicated devices, a Inovelli light switch, this used to be 6 different things, which was very confusing, now its a single thing, with channel groups for endpoints:
For Bridged devices (Hue, Ikea, BAF, etc…) The bridge itself will show up as a Node, but when thats added, the inbox will have discovered the bridged devices as thier own child things. While technically these are just endpoints, bridged endpoints have their own reachability status, and can contain child endpoints, so warrent being thier own thing as a child of the Node thing type (and be offline independent from the node if not reachable) .
Mapping the new channels to existing items will be necessary, if using files, this was a simple find and replace exercise for me. The README has been updated to reflect these changes.
3 Likes
Awesome! I have fixed this in the latest build.
Yeah, there are options when sending commands to support transitions which i think i’m ignoring, so will need to look into supporting that