-
Notifications
You must be signed in to change notification settings - Fork 703
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
Add Tuya vibration door sensor _TZE200_kzm5w4iz
#3246
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #3246 +/- ##
==========================================
+ Coverage 88.25% 88.33% +0.07%
==========================================
Files 302 304 +2
Lines 9434 9497 +63
==========================================
+ Hits 8326 8389 +63
Misses 1108 1108 ☔ View full report in Codecov by Sentry. |
Thanks for adding tests btw! |
_CONSTANT_ATTRIBUTES is a good proposal, I've moved the constant attributes. |
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.
I think the quirk looks really good. Added a few small comments.
zhaquirks/tuya/ts601_door.py
Outdated
# Initialize remaining battery to 100% until a proper measurement arrives. | ||
# Device measures battery in 1% steps, while the ZCL specifies it in 0.5% steps. | ||
self.update_attribute( | ||
attr_name=PowerConfiguration.AttributeDefs.battery_percentage_remaining.name, | ||
value=100 * 2, | ||
) |
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 is done in __init__
, this will update the attribute to 100% if HA is restarted.
Something like if attr_id not in self._attr_cache
could be added before, but I think I'd just remove this for now.
HA should still initialize the sensor. It should just show something like "unknown". How long does it take for the device to report a value?
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.
Removed for now.
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.
As far as I've noticed, the device reports battery state when there's a change in percentage. This doesn't happen too often: either when there's some variability in the measured voltage (e.g. moves from 80% to 81% then back to 80%), or when there's an actual drop. Since this is a door sensor and is supposed to be used frequently, the value will probably get initialized fairly soon, so I'm fine with this decision.
zhaquirks/tuya/ts601_door.py
Outdated
def __init__(self, endpoint: Endpoint, is_server: bool = True): | ||
"""Init constructor that initializes the major IasZone attributes.""" | ||
super().__init__(endpoint=endpoint, is_server=is_server) | ||
|
||
# Initialize zone status until a proper update comes. | ||
self.update_attribute( | ||
attr_name=IasZone.AttributeDefs.zone_status.name, | ||
value=0x0000, | ||
) |
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.
Same thing here. This will update, as soon as the sensor is opened/closed once, right?
Do we really need to put "fake" initial data here?
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.
Removed for now.
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.
Same reasoning applies: the opening sensor will probably get used fairly soon, it doesn't matter much if it doesn't get initialized.
zhaquirks/tuya/ts601_door.py
Outdated
def __init__(self, endpoint: Endpoint, is_server: bool = True): | ||
"""Init constructor that initializes the major IasZone attributes.""" | ||
super().__init__(endpoint=endpoint, is_server=is_server) | ||
|
||
# Initialize zone status until a proper update comes. | ||
self.update_attribute( | ||
attr_name=IasZone.AttributeDefs.zone_status.name, | ||
value=0x0000, | ||
) |
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.
Same thing here.
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.
Removed for now.
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.
This is where I disagree. Significant force is very rarely applied to most doors (in fact, my sensor only detected such change when I was manually testing the quirk, but never since then). This leads to an unitialized entity for quite a long time, which I personally don't really like to see on a UI. Initializing the vibration state to "no vibration" seems to me the lesser evil :)
_TZE200_kzm5w4iz
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!
I've removed initializing the attributes for now, as they'd always initialize to the defaults specified when rebooting HA.
If the defaults are really needed, they can be re-added with adjustments I mentioned here. For now, the entities should stay unknown until the first update report.
class CustomBasicCluster(CustomCluster, Basic): | ||
"""Custom Basic cluster to report power source.""" | ||
|
||
_CONSTANT_ATTRIBUTES = { | ||
Basic.AttributeDefs.power_source.id: Basic.PowerSource.Battery | ||
} |
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.
Not sure we need this, not an issue for now though. Was it shown wrong on the HA device page?
That data comes from the node descriptor though.
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.
ZHA displayed the power source as "battery or unknown", which was bothering me a little, and in hopes of fixing that I tried setting it this way. However, it didn't really help, so I guess that is solely based on the device signature.
Hello, I have the same Tuya vibration sensor (TS0601) but the manufacturer is _TZE200_iba1ckek. EDIT : ooop, it's not strictly the same sensor, mine is only a vibration one. I will create a new entry. |
Hi, it really depends on whether the Tuya DataPoints that it reports are
the same or not. Can you do a quick analysis on that?
…On Fri, 20 Sept 2024, 12:19 Jimfizz, ***@***.***> wrote:
Hello, I have the same Tuya vibration sensor (TS0601) but the manufacturer
is _TZE200_iba1ckek.
Are you able to deal different sensors (of the same type) in the same
quirk or should I create a new topic ?
I use it to detect the sound of a doorbell and I would like to manage the
sensitivity of the sensor.
—
Reply to this email directly, view it on GitHub
<#3246 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AITBLK2QKGKKFBNWUITMG2LZXPZBJAVCNFSM6AAAAABKRSL57SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRTGM3TMNBVHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Thank you @adam-zlatniczki : in ZHA the sensor does not report any door state (open/closed), only vibration detection (with reset), battery level (CR2450) & identifier |
Proposed change
Added quirk for the Tuya Vibration Door Sensor, which didn't have any matching quirks before.
Additional information
--
Checklist
pre-commit
checks pass / the code has been formatted using Black