It is already verly late in the night in France, I will do that tomorrow 
1 Like
One other thing, watching the logs, i feel like Google, Apple and Alexa all are very relaxed about pinging clients, much more then matter.js who is quite aggressive. I wonder if thats part of the issue, matter.js is just way to sensitive and introduces unnecessary timeouts and backoffs? Iâll bring it up with the matter.js dev.
Youâre my hero, now all works as expected, big thanks!
edit: except for the TemperatureSensor
Number Temperatur_Wohnzimmer âTemp. WZ [%.1f °C]â (gPersist,Temp,TempHum,TempHum_WZ) {channel=âjeelink:lacrosse:Wohnzimmer:temperatureâ, matter=âTemperatureSensorâ [label=âTemperatur Wohnzimmerâ]}
gives me -1.0° in the alexa app and alexa says its -274,2°
real temperature is 22,5°C
but nothing to hurry, my kid is very happy to control the color bulbs again 
edit2: problem has fixed by itself over night 
now it has the correct value
maybe the battery is low and the value is not pulled every 5 secs or something, i dont know
but it works!
1 Like
@digitaldan do you have any plans to implement groups for Matter devices in OpenHAB?
I would hope we support most matter features. Groups is not something I have looked into , Iâm not aware of anything using them yet .
1 Like
Make totally sense.
Usually I use the latest Binding jar you provide.
My observations so far show in in one case with an earlier version of the Matter binding that the devices themselves had to be restarted.
Since then I had issues with just one device (my WiZ LED Lightstrip). It:
- works well after a restart of openhab,
- after some time of steering it via OH it is not possible anymore to switch it off via OH.
- I then switch it off via Apple Home (where it still works without issues).
- I have no issues switching it back on via OH, but off remains impossible.
- restarting on the OH side resets the issue, meaning I can steer the device totally from OH again for a certain undefiniable amount of time.
I will have look to get something reproducable. Maybe I get some logs in a working âswitch offâ situation and a non-working⊠So far I cannot tell what makes the device start being nastyâŠ
Did you check your thing status ? Is it always ONLINE? Especially when you encounter problem with the ON/OFF command.
I will need to see DEBUG logs when you switch it on and when you switch it off from openHAB. It also might be helpful if there is a log when switching off from Apple in openHAB when its not working. Also what does the item look like you are sending an OFF command to ? Is this the color item?
Thats very odd indeed. All temperature in Matter are in °C, but the values you mentioned look like conversion errors in Alexa. -1.0° seems like a general error with the value and -274,2° looks like it converting °C â Kelvin which doesnât make a whole lot of sense.
One other thing i have noticed is that the Alexa App is not doing conversion correctly based on my preferences (Imperial), it shows everything in metric , although asking Alexa with voice does get the right converted value. Seems like the alexa app is not quite hardened yet with matter devices.
Okay, I got some logs and info:
I operate on the colorcontrol-color channel/the color item. I am switching the lamp via a scene that sets hue, saturation & brightness (in a rule triggered via a Philips Hue Wall switch). Off is done also in the same rule also triggered via a wall switch module by doing an item.sendCommand(âOFFâ).
When the error occurs, the item is marked as âonlineâ in OHâs GUI.
Here a screenshot:
The lampâs json:
WiZ_LED_LightStrip.json (9.7 KB)
Here now the logs (tracelogs, I took them before your last message). These logs are taken after a "crash2 of the lamp.
- The âswitch-offâ log via OH. Without any effect on the lampâs state - it stays onâŠ
01_switched_off_via_openhab_but_lamp_not_going_to_off_trace.log (15.7 KB) - Then I switched the lamp off via Apple HomeKit, it switches finally off:
02_switched_via_apple_and_lamp_goes_to_off_trace.log (6.0 KB) - I switch the lamp back on via OH. This works. I got light in the room:
03_switched_on_again_via_openhab_and_lamp_goes_to_on_trace.log (16.8 KB) - As the first point: Switching Off via OH. Nothing happensâŠ
04_switched_off_via_openhab_but_lamp_not_going_to_off_trace.log (10.5 KB)
After that âpower cycleâ I simply âpausedâ the things and initialized it again. And all is working well againâŠ
I hope that help to understand that weird thing.
Also, I tried to provoke a crash by switching the lamp via my OH rule âOn/Offâ but I had no chance to achieve a crashâŠ
In Apple Home I had no issues at all so far. It always worked well, even when it did not via OHâŠ
Iâm a little confused here, the logs show:
hue:device:001788fffe2d3081:a1c6840b-3b88-4ec8-b074-470849a7353f:button-last-event triggered 1000
13:48:41.103 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'WiZ_LED_Strip_ColorControl_Color' received command 195,2,100
That does not look like you are turning something off.
This is the same command you are sending when you tried to turn off in #1
Again your logs show you are sending the same command to turn the light on to full brightness no matter what. This seems like an issue with whatever rules you have and not this binding.
Okay. This is an interesting point. I really promise/swear that I have take that log for switching onâŠ
Here my rule that is triggered:
//var HSBType = Java.type('org.openhab.core.library.types.HSBType');
var item = items.getItem('WiZ_LED_Strip_ColorControl_Color')
var item_brightness = item.rawState.getBrightness().floatValue()
if (item_brightness == 0) {
rules.runRule('Standard_BathRoom_Slot_01', {})
}
else if (item_brightness > 0) {
item.sendCommand('OFF')
}
Here the âSceneâ CodeâŠ
items:
WiZ_LED_Strip_ColorControl_Color: 195,2,100
triggers: []
conditions: []
It really puzzles me as it does you!? Is there a possiblity that the devices sends/receives/or whatever sends a wrong âbrightnessâ? Since that brightness is the thing I use in my if-statement. The rule itself runs fine for all other devices (these are Philips Hue devices via the Hue Binding).
I will keep an eye on that, but right now I do not know what I could have done wrong as everything worked until a certain point and then I get that missbehavior!?
Have you tried Controlling this device in the Main UI from a color widget in addition to a rule? This would at least allow you to see what we think the state of the device is and help troubleshoot your rule.
How is this triggered? And when you say âSceneâ Code , is that the âStandard_BathRoom_Slot_01â rule? Can you be more specific? Also what does you item configration look like ?
Okay, I hope I got all info you need. (BTW thank you very much!)
I did use the Main UI for controlling the device before creating any logic/rules. That worked well. I used a âColor Widgetâ and an âOn/Offâ Widget (the latter linked to the colorcontrol-color channel). Just to make sure - a screenshot of what is hopefully the widget ;o)
The rule is triggered by a trigger from the Hue wall switch module.
configuration: {}
triggers:
- id: "1"
configuration:
event: "1000"
channelUID: hue:device:001788fffe2d3081:a1c6840b-3b88-4ec8-b074-470849a7353f:button-last-event
type: core.ChannelEventTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: |-
var item = items.getItem('WiZ_LED_Strip_ColorControl_Color')
var item_brightness = item.rawState.getBrightness().floatValue()
if (item_brightness == 0) {
rules.runRule('Standard_BathRoom_Slot_01', {})
}
else if (item_brightness > 0) {
item.sendCommand('OFF')
}
type: script.ScriptAction
The scene I sent is the âStandard_BathRoom_Slot_01â rule. Correct.
The item config is here (I hope that is what you need):
My thought so far: I get the impression that for a certain reason the brightness might be wrong after âthe crashâ occured.
Concerning the widgetâs behavior in the âcrashâ-state: I have to check again (I think to remember that they did not work anymore correctly, but I will check that).
After (re-)initialization of the MatterDevice/LED Strip the widgets âOn/Offâ and âColorâ work correclty. And so does the rule, triggering the lamp on and off.
The logs show that actually the brightness does not change (anymore). A fact I just did not see. (Sorry) So I would conclude so far that the brightness (and thus the On/Off state) of the Lamp is not correctly transmitted to or handled in OH as Apple Home is still doing the correct on/off.
You might want to add logging to your rule, print out the H S B values of the WiZ_LED_Strip_ColorControl_Color item. Also i would look through your logs for when the state of the item changes, those lines will begin with ItemStateChangedEvent
Okay I implemented that and did a Matter trace log.
BTW: Did I send a log file in a working scenario??? Maybe the difference to the âcrash logâ helps⊠Here a no-issue-log (already including the HSB values) for one power cycle:
on_off_cycle_trace.log (25.5 KB)
EDIT: BEFORE and AFTER are here (probably on could be enough):
EDIT2: Added complete rule code & format
var HSBType = Java.type('org.openhab.core.library.types.HSBType');
var item = items.getItem('WiZ_LED_Strip_ColorControl_Color')
var item_brightness = item.rawState.getBrightness().floatValue()
var item_hue = item.rawState.getHue().floatValue()
var item_saturation = item.rawState.getSaturation().floatValue()
console.log('BEFORE')
console.info('HUE: ' +item_hue.toString()+ ', SATURATION: ' +item_saturation.toString()+ ', BRIGHTNESS: ' +item_brightness.toString())
if (item_brightness == 0) {
rules.runRule('Standard_BathRoom_Slot_01', {})
}
else if (item_brightness > 0) {
item.sendCommand('OFF')
}
console.log('AFTER.')
var item_brightness = item.rawState.getBrightness().floatValue()
var item_hue = item.rawState.getHue().floatValue()
var item_saturation = item.rawState.getSaturation().floatValue()
console.info('HUE: ' +item_hue.toString()+ ', SATURATION: ' +item_saturation.toString()+ ', BRIGHTNESS: ' +item_brightness.toString())
Just to clarify: I did log HSB values while I was testing and building the rule. And in general the rule works until âthe crashâ occurs. Using the WiZ Binding for the same lamp the rule also works. I encounter that strange behavior I describe only when using the Matter Binding. In Apple HomeKit (paired via Matter) I have also no issues, even when I have them in OH.
Hopefully, the logging you suggest will give more information. But therefore I have to wait until the next crashâŠ
This is confirmed from the Matter Application Cluster Spec (and from BAF):
4.4.6.1.2
If a client attempts to write an unsupported value (such as On), the FanMode attribute SHALL be set to High.
For anyone else testing with a Big Ass Fan, if you have any kind of switch or scene controller that controls ON/OFF of the fan (and you want to turn ON the fan to the last known speed), here is my solution:
- Create an unlinked item with Type Number. I just called mine Current Speed.
- Leave your Switch/Scene Controller unlinked as well.
2 rules:
- When the speed of the fan changes, update your unlinked Item (Current Speed)
var Speed;
Speed = items.getItem('GuestFanSpeedControlMatter').numericState;
if (Speed != 0) {
items.getItem('GuestFanCurrentSpeed').postUpdate(Speed);
}
- Then for the Switch/Scene Controller
if (items.getItem('GuestFanPower').state == 'ON') {
items.getItem('GuestFanSpeedControlMatter').sendCommand(items.getItem('GuestFanCurrentSpeed').numericState);
} else if (items.getItem('GuestFanPower').state == 'OFF') {
items.getItem('GuestFanSpeedControlMatter').sendCommand('0');
}
When I open or close my window, I see the change of state in Basic UI in less than 0.5s. it takes around 3s to be updated in Google Home.
As everything is local, I was expecting a faster change in Google Home.
I donât know if most of time is passed inside OH/matter.js or in Google Home.
It is a window detector managed by OH and exposed as Matter by the Matter binding.
Dan, do you notice such delay?
For a light controlled by Z-Wave, change of state is immediate in OH, it takes around 3s to be updated in Google Home
No, not in Alexa or Apple (have not tried GA yet) but you can check and see in the logs, there will be a message like sendMessage: {"id":"c44ce1ae-ab83-4b0c-b8ff-3255e1acae9d","namespace":"bridge","function":"setEndpointState","args":["F1_Office_Shades_Group","windowCovering","currentPositionLiftPercent100ths",2400]} as soon as the state changes . Apple at least shows it closing immediately, Iâll check on GA a little later when i run through some other changes iâm making.
Apple Home does show something strange sometimes , like its stuck closing (spinning), so i need to look into something maybe we are not setting right.
Window Covering is actually pretty important. Shockingly, matter has no barrier control clusters, like garage doors, gates, and other motorized barriers, not even in the recently released 1.4 spec. Both zigbee and z-wave have had these for a long time.
So Window covering is being use for that pupose by early device makers b/c it support open/close functionality. I have added quite a bit of customization for window coverings so you can use multiple item types and also map OPEN/CLOSE to custom values.