-
Notifications
You must be signed in to change notification settings - Fork 835
Add Senoro door sensor _TZE200_ytx9fudw
#4086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #4086 +/- ##
==========================================
+ Coverage 91.20% 91.25% +0.05%
==========================================
Files 335 339 +4
Lines 10889 10930 +41
==========================================
+ Hits 9931 9974 +43
+ Misses 958 956 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…oro Window Sensor code
… class definitions for improved clarity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. I've added some comments.
zhaquirks/senoro/senorowin.py
Outdated
.tuya_switch( | ||
dp_id=16, | ||
attribute_name="alarm", | ||
entity_type=EntityType.STANDARD, | ||
translation_key="alarm", | ||
fallback_name="Tamper Alarm", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the "Tamper alarm" is a switch (and not a binary sensor), what's the difference in device behavior when the switch is on or off?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Senoro.Win is a window/door contact that can report the open/closed/tilt status (low-power device). At the same time, it offers burglary protection in the form of an alarm. This is sent via Tuya data point 16 (boolean). If the alarm is triggered, the device switches to a normal device and you can write boolean false to data point 16 to deactivate the alarm again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay. That's interesting. I guess this is fine then.
Just curious, what do you mean by "If the alarm is triggered, the device switches to a normal device"?
Like, the sensor won't make any sounds or lights when the alarm is on, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can see the device here: www.senoro.de
It is primarily a door/window sensor that sends the Open/Close/Tilt statuses. The device is battery operated. If a burglar shakes the window or tries to force it open, the device registers this by vibration. The device then makes a very high-frequency sound via a siren (like a smoke detector). From this moment on, it switches to a different mode and allows writing to data point 16 (not possible before) in order to switch off the siren (the alarm) again.
zhaquirks/senoro/senorowin.py
Outdated
.tuya_switch( | ||
dp_id=16, | ||
attribute_name="alarm", | ||
entity_type=EntityType.STANDARD, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, should the "Tamper alarm" not be a configuration entity (default for quirks v2 switches) instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is supposed to be a binary sensor, we should also set:
device_class=BinarySensorDeviceClass.TAMPER,
entity_type=EntityType.DIAGNOSTIC,
fallback_name="Tamper",
No translation key is required then, as the default device class name will be used, which is "Tamper".
The fallback name will not be used, but still needs to be present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I'm not very familiar with the ZHA integration, I just started with it and tried to integrate this device.
I did this by trial and error with a custom quirk under /config/custom_zha_quirks in Home-Assistant. The only important thing here is that you need to be able to read and write boolean on Tuya datapoint 16.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, all good. I've never come across something where you can turn on/off the tamper alarm yourself.
I think a switch for this should be fine then. No device class that's really applicable then. We can maybe set some alarm icon (which could be done here after a quirks bump PR with the quirk is merged to HA).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
_TZE200_ytx9fudw
zhaquirks/tuya/tuya_door.py
Outdated
.tuya_switch( | ||
dp_id=16, | ||
attribute_name="alarm", | ||
entity_type=EntityType.STANDARD, | ||
translation_key="alarm", | ||
fallback_name="Tamper alarm", | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this switch cannot be turned on (when it's off) to turn on the alarm manually, we should think about doing the following instead:
Have a binary sensor entity (for dp 16) (with BinarySensorDeviceClass.TAMPER
to show nicely in HA) and also provide a "write attribute button" to reset the dp back to 0
/clear.
Implementing the button might require us to map the dp with tuya_dp
and just use normal binary_sensor
and write_attr_button
(instead of the Tuya variants), or just use the mapped dp from tuya_binary_sensor
then. That might work as well, but I'll take another look at this, since it's not exactly easy.
I think the approach with a binary sensor and button to reset might be a bit nicer than a switch entity though (that you cannot turn on).
I'll come back to this, but the beta cutoff for 2025.6.0 is already tomorrow, so we likely won't make that, as there are still some other things I have to take a look at.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you had time to think about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheJulianJES fyi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove the "Tamper alarm" from this initial PR? We can hopefully get the other stuff into 2025.7.0 then.
I've not had much time yet, unfortunately. You can immediately create another PR with the same "Tamper alarm" switch, so it's not forgotten about.
When I get to it, I can try to push/comment the button/binary sensor alternative. But if you can get that working, that'd be great too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheJulianJES
ok, so I removed the tamper alarm switch. But currently, if the alarm turns on, you can't turn it off. The device activates the alarm for three minutes, then it turns off, or you have to remove the batteries...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll come back to you with the button and binary sensor entity for turning off the tamper alarm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I'll come back to you regarding the binary sensor and button for the tamper alarm.
But for now, this looks good.
@TheJulianJES, @ChristianGr1974 So HA 2025.7 will contain the first Sonoro support for ZHA without a possibility to disable the alarm? |
For anyone who has the sensor, please test this PR and let me know if it works as expected: The PR adds a binary sensor entity for viewing the current alarm state and a button dedicated to resetting the alarm state. |
Proposed change
Support for the window/door contact from Senoro.
Additional information
Currently not supported.
Tested with hardware device as external quirk.
Checklist
pre-commit
checks pass / the code has been formatted using Black