Repository navigation
Zigbee window treatment: extend step timeout, use input step component - #3319
hcarter-775 wants to merge 2 commits into
Conversation
…ponent Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Invitation URL: |
|
zigbee-window-treatment_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against 1373f85 |
Test Results 73 files 545 suites 0s ⏱️ Results for commit 1373f85. ♻️ This comment has been updated with latest results. |
| local LATEST_TARGET_LEVEL = "_latestTargetLevel" | ||
| -- Timeout in seconds for the stateless step accumulation window | ||
| local TARGET_LEVEL_TIME_OUT_SECONDS = 15 | ||
| local TARGET_LEVEL_TIME_OUT_SECONDS = 120 |
There was a problem hiding this comment.
This seems excessively long. What blinds actually take 2 minutes to move through their full range? Was this from a testing situation?
There was a problem hiding this comment.
It definitely can take over a minute, especially to go 0-100 -- to clarify, if the device reaches the final state, it will stop this timer. So it really is just a backup, catchall. I recall Ikea takes a long time. This is mostly cleanup while investigating improvements while I'm doing Zwave.
| end | ||
| local timer = device.thread:call_with_delay(TARGET_LEVEL_TIME_OUT_SECONDS, function(d) | ||
| device:set_field(LATEST_TARGET_LEVEL, nil) | ||
| device:set_field(TARGET_LEVEL_TIME_OUT, nil) |
There was a problem hiding this comment.
This is the only place the target timeout and target level is cleared. You should clear it from the open, close, preset, and setShadeLevel handlers also (which is what matter does). Its needed to avoid a situation where subsequent commands dont have stale data.
Example (all within the 2 min window):
- Step +10 from 50-60
- close command
- report level 0
- step +10; expected to move to 10, but moves to 70 instead.
There was a problem hiding this comment.
Matter is much more comprehensive, I agree. I put a lot of work into making that driver tick in tune, haha. However, I do not think adding a bunch of handling like that is particular helpful, as the case you described is fairly unlikely in my opinion. I would prefer to track something like you're describing, a more comprehensive state-tracking system, in some kind of follow up. One big difference of Matter, for example, is that there aren't 10 subdrivers that might override open/close, etc in various ways. This basically is just a cleanup commit, to actually nil out what should be unset anyway, but just wasn't.
|
|
Description of Change
Extend the timeout for Zigbee blind step to 120 to account for very slow blinds that do not update their state frequently, so that incremented steps (via scrolling or contiguous button presses) are counted as part of the same movement for a longer period of time.
Summary of Completed Tests
Tests updated.