Closed vlape closed 1 year ago
Hey there @dmulcahey, @adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration (zha
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
zha documentation zha source (message by IssueLinks)
I was doing one fast test and the closing DA was working OK but not the opening one.
Little testing and found that ZHA was putting in Device offline
instead of LUMI lumi.sensor_magnet.aq2 Opening opened
that was making the automation not working OK. And the close is getting open as trigger !!
Deleting all automatons for the device and making new ones and forcing the right triggers then doing them and both open and closing is working OK.
Can you looking how your automatons is looking in yaml ?
My fixed automatons made from device card looks like this:
alias: LMO
description: ""
trigger:
- type: opened
platform: device
device_id: 689023bb85a9fb6320aef0483a01f2cb
entity_id: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening
domain: binary_sensor
condition: []
action:
- event: zha_event
event_data:
Data: Open
mode: single
And
alias: LMC
description: ""
trigger:
- type: not_opened
platform: device
device_id: 689023bb85a9fb6320aef0483a01f2cb
entity_id: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening
domain: binary_sensor
condition: []
action:
- event: zha_event
event_data:
Data: Closed
mode: single
So its looks like on bug in ZHA / HA automation logic here.
@TheJulianJES Do you having this device ?? Perhaps its can being repeated with other devices so i shall trying doing the same with LIDL magnet and reporting back.
I think perhaps our @puddly have doing somthing that making the linking from the DA to the automation GUI not working OK or it have never working OK so perhaps hi was not to blaming :-)))
Was trying adding DA made automatons to LIDL magnet and its using IAS Zone and not OnOff cluster but i is getting the same then adding them.
ZHA DA => HA Automation editor GUI DA Opened => Device offline DA Closed => LIDL Magnet TY0203 Iaszone opened
So somthing spooky is going on here !!
Both devices is working normal and reporting opened and closed OK as events in the log and also on the device card status only the DA mapping looks being broke.
To confirm: the automations editor in the frontend creates a wrong YAML automation which has incorrect triggers?
Yep and if correcting the trigger or doing one new from automation editor its working as it shall do.
Was looking but IKEA motion sensor with quirk is working OK (we was fixing the DA also for the last 24.5 firmware) but the 2 different types LIDL motion sensors without quirk and is using IAS Zone is also wrong:
"manufacturer": "_TZ1800_fcdjzz3s",
"model": "TY0202",
"class": "zigpy.device.Device"
LIDL Motion 1 TY0202 Iaszone started detecting motion
=> Device offline
LIDL Motion 1 TY0202 Iaszone stopped detecting motion
=> LIDL Motion 1 TY0202 Iaszone started detecting motion
And the same with:
"manufacturer": "_TZ1800_fcdjzz3s",
"model": "TY0202",
"class": "zigpy.device.Device"
Edit: Interesting thing is that the different LIDL models is still using the same device ID from tuya but is completely different devices.
Was testing HUE Motion sensor SML001 and:
Wohnzimmer BM Rechts illuminance illuminance changes => Device offline
Wohnzimmer BM Rechts temperature temperature changes => Wohnzimmer BM Rechts illuminance illuminance changes
Wohnzimmer BM Rechts occupancy became occupied => Wohnzimmer BM Rechts temperature temperature changes
Wohnzimmer BM Rechts occupancy became not occupied => Wohnzimmer BM Rechts occupancy became occupied
Wohnzimmer BM Rechts on_off started detecting motion => Wohnzimmer BM Rechts occupancy became not occupied
Wohnzimmer BM Rechts on_off stopped detecting motion => Wohnzimmer BM Rechts on_off started detecting motion
The rest DAs is doing the right trigger in the HA automation GUI but its looks somewhere is the list hoping to wrong post in the list of functions.
If i remember right is some devs having this devices so shall being easy pointing out what is going wrong in the code.
2023.5.0b0 includes a new frontend release. Could you check if it works with that?
Normally no problems but all my working test systems (3) is running RCP with OTBR and i dont like distorting them then its on the way in the production system and my Windows 10 have stopping running WSL so cant running docker on it for fast tests that i normally was doing. If i remember right is our Puddly also having one SML001.
I am not sure if it matters, updated Home Assistant Operating System to 10.1 this morning. Same results. Here are zha_event from a different lumi.sensor_magnet.aq2
sensor. Same behavior. Opened window. Closed window.
Let me know if there is anything else useful I can provide.
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 1
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:15:57.532550+00:00"
context:
id: 01GZ1YVPAW2BJAPQEZE4HXCWGJ
parent_id: null
user_id: null
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 0
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:15:57.560614+00:00"
context:
id: 01GZ1YVPBRX0RTT06VEMK67A2F
parent_id: null
user_id: null
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 1
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:15:57.659037+00:00"
context:
id: 01GZ1YVPEVTSHJD1483871Z1JE
parent_id: null
user_id: null
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 0
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:16:02.381616+00:00"
context:
id: 01GZ1YVV2DEEYQDZN84AA645W2
parent_id: null
user_id: null
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 1
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:16:02.433468+00:00"
context:
id: 01GZ1YVV41BRTBNEVNHAQXRKXA
parent_id: null
user_id: null
event_type: zha_event
data:
device_ieee: 00:15:8d:00:09:46:57:83
unique_id: 00:15:8d:00:09:46:57:83:1:0x0006
device_id: cd7b738bc4bdef360f32c1e9086c5073
endpoint_id: 1
cluster_id: 6
command: attribute_updated
args:
attribute_id: 0
attribute_name: on_off
value: 0
params: {}
origin: LOCAL
time_fired: "2023-04-27T18:16:02.449030+00:00"
context:
id: 01GZ1YVV4HJR0E5413NHG7JAFQ
parent_id: null
user_id: null
So the "Example YAML snippet" initially posted is working correctly with a lumi.sensor_magnet.aq2
on 2023.4.6 for me.
That automation does not use device automation triggers at all, as it uses a state
trigger.
Thezha_event
s sent when opening/closing the window indicate that the attribute (cache) was correctly updated too.
@MattWestb You mentioned that you get wrong device automation triggers when creating the automation from the frontend? Can you post a screenshot how you're exactly creating the automation (and from what browser) and what YAML is produced by creating that automation with device automation triggers?
I also created an automation using the lumi.sensor_magnet.aq2
and device automation triggers for opened and closed (instead of directly using state triggers) and they also worked just fine.
From the device card: clicking opened and getting: And if clocking closed i getting: The yaml is also wrong so its the linking in ZHA that is getting problem.
Opened:
description: ""
mode: single
trigger:
- device_id: 689023bb85a9fb6320aef0483a01f2cb
domain: zha
platform: device
type: device_offline
subtype: device_offline
condition: []
action: []
Closed:
description: ""
mode: single
trigger:
- type: opened
platform: device
device_id: 689023bb85a9fb6320aef0483a01f2cb
entity_id: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening
domain: binary_sensor
condition: []
action: []
Google Chrome Chrome is up to date Version 112.0.5615.138 (Official Build) (64-bit)
Edit: The zha_events is very OK also the logbook on the device card and the HA long is OK and the icon on the device card is working OK. Its problems with the linking from the device card to the automation editor that is getting wrong. I war refreshing the browser between clicking on make on automation but the same resolute.
If correcting the trigger in the editor all is working OK but its still one bug here.
Also one PM that i think (not 1110% sure) that is not 100% hitting the bug than i have seen some times its was OK but very rear. I also have seen that later versions of HA is not doing all steps in time trigger that putting light on and off have running but have not all steps but i was thinking it was interference that was doing the Zigbee to delivering the command but its not any error in the log and in the log book HA have not doing all steps and its happening 2-3 times in the week so can being one python bug that is doing strange things in the automatons.
The tests was done on one RCP 4.2.2.0. = EZSP 7.2.2.0 and also tested devices that is in production system and they is doing the same.
Lumi Magnet2: Diag Test system zha-90202c43129e6a74f5081ca4b796a4b4-LUMI lumi.sensor_magnet.aq2-689023bb85a9fb6320aef0483a01f2cb.json.txt
Lumi Magnet2 inside one smoke detector. Diag production system zha-998bc857058111eb90e2ad6d9c6e46a8-LUMI lumi.sensor_magnet.aq2-62550608096e11eba461ed53132982ef.json.txt
From the device card
Oh, I've never created a device automation trigger by going from the device page. Using "Device" as a trigger and then selecting any device automation trigger does not cause the issue:
I can reproduce the issue when going through the device page though. Pretty sure that's a frontend issue. Your best bet is to open an issue in the frontend repo, include those screenshots, mention with what device it's happening, and that it seems to be off by one.
From what I can tell, the initial issue is a different one that's possibly caused by bad sensor placement. The provided YAML in the OP is correct and works well for me.
Transfer the issue to the fronted and we dont need redoing all postings.
The initial issue is a different one that's possibly caused by bad sensor placement. The provided YAML in the OP is correct and works well for me.
OK so we is having 2 different bugs here then i reading the initial post.
The initial issue is a different one that's possibly caused by bad sensor placement. The provided YAML in the OP is correct and works well for me.
I am not sure placement is the issue sinve multiple sensors via multiple routes from the same vendor are producing the same result. Each sensor is no more than 15 feet from a router. I have only put 9 of these sensors on the network. The zigbee network was built as follows: Home Assistant Yellow as coordinator. Three TRADFRI outlets and two Sengled E1C-NB7 outlets were joined to a new network. I waited a week before adding the Aqora sensors Each Aqora aensor was added via the nearest hub. ZHA map indicates the sensors are connected to hubs. There is little physical obstruction between sensors and hub. Do any of these dataponits help?
Screenshot from your initial post:
You're seeing the state bounce. So you see a open/close/open in the same second (even though you're likely just opening it). The sensor sends multiple updates. So either your sensor/magnet is placed badly or it's defective.
You think all nine of them are defective or have badly placed magnets? The reference lines for the sensors and magnets are +/- 2mm. Distance between sensor and magnet is approximately 5mm, well below the maximum of 22mm as indicated in specifications.
In the opening posted log all commands is OK send with unique TSN so its not made of the network, every one is being sent from the device that have detected status change.
The magnet sensor can being defect but normally sending closed then its open only false open then being closed. Thais barbecue its one hall element that is in one glass tube with vacuum or gas and if the vacuum or gas is leaked and getting oxygen in it the contacts is not getting good contact and its working more like one vibration sensor. To diagnostic knocking with one back of one screwdriver on the sensor then the magnet is in range and if its sending status changes its defect (I have only 30 years experience of this things from alarm systems).
I think its not very likely all your magnet sensors is defect and if not mounted very badly they shall working OK. You also can here a very silent clicking then the elements is changing status but is not easy hearing if mush sound around.
I was testing one more time in my test system and i cant getting my device sending false closings then opening it in "normal" working conditions in the working range of the magnet.
The code tracing i leaving to other doing that have more knowledge of that.
Edit: I was reference measuring the the distance on flat surface and with the reference markings in the right position and opening is 22 mm and closing 20 mm (its having some hysterics build in for not getting multiple detentions then doing one clear open or closing) and the arrangements up / down is not so critical then the magnetic fled is prity large around the magnet and the sensor is tolerant for it.
@MattWestb I do hear a single click on open and close. Tapping lightly on the sensor with the window open, nothing happens. A firm tap will indicate closed. Will not show open egain until it passes the magnet. I assume this is due to a shock and would be acceptable. With the window closed, there is no change in status
All sounds OK but if knocking hard then its open it can getting fast close and then closed it jumping away and need being re triggered with the magnet for working agen.
The working principle of the detector is one Reed switch and is the how its working is described well here: https://en.wikipedia.org/wiki/Reed_switch its pure mechanical but normally working well.
Can you post a picture of the device installation please?
The most important is mounting the magnet in the right direction or you can getting strange behavior like double triggering or reverse function of the element.
@dmulcahey Attached @MattWestb the reference lines on the magnet and sensor are facing each other.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
The problem
Recently installed several Aqara
lumi.sensor_magnet.aq2
sensors. Automations to detect open and close state to start timers were not activating correctly. Opening contact would start both open and closed timers however in trace, it did not indicate both were executed. Opening the contact, logs indicated open, close, open events. Closing the contact indicates one close event. I have tested with seven of these sensors, same results when opening contact. This is a fresh install, no other autoamtions have been configured.This is the sensor that should be seen in the debug log IEEE: 00:15:8d:00:09:49:ea:8a Nwk: 0x273f Device Type: EndDevice LQI: 96 RSSI: -76 Last Seen: 2023-04-24T21:11:19 Power Source: Battery or Unknown Quirk: zhaquirks.xiaomi.aqara.magnet_aq2.MagnetAQ2
Home Assistant Yellow Home Assistant 2023.4.6 Supervisor 2023.04.1 Operating System 10.0 Frontend 20230411.1 - latest
What version of Home Assistant Core has the issue?
2023.4.6
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Zigbee Home Automation (ZHA)
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha
Diagnostics information
config_entry-zha-de5761abbba567abfcd192b06be7492f.json.txt
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
Automation Open Trace
Automation Close Trace