Matter Ikea Scroll: Add global scroll state

[hcarter-775]

Description of Change

Add global state to check for upper and lower bounds within a time frame for the ikea scroll. This should halt extra rotateAmount events from being processed after the threshold for "100%" has been reached.

Summary of Completed Tests

Tested on-device

[github-actions]

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/Boj0aZpDV6MA

[github-actions]

Test Results

   73 files    516 suites   0s ⏱️
2 911 tests 2 911 ✅ 0 💤 0 ❌
4 808 runs  4 808 ✅ 0 💤 0 ❌

Results for commit fb7fe8b.

[github-actions]

File	Coverage
All files	91%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/init.lua	87%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/scroll_utils/event_utils.lua	41%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/embedded_cluster_utils.lua	38%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/utils.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_handlers/attribute_handlers.lua	96%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_handlers/capability_handlers.lua	84%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_utils/device_configuration.lua	94%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_utils/utils.lua	98%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/attribute_handlers.lua	80%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/event_handlers.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/capability_handlers.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/init.lua	96%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/scroll_handlers/event_handlers.lua	73%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/aqara_cube/init.lua	95%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/third_reality_mk1/init.lua	95%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/eve_energy/init.lua	91%	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against fb7fe8b

[gharveymn]

Is the idea of the timer rather than just always tracking the state that we get protected for a certain amount of time, but still allow the device to send us new out of bounds events just in case, if if we were to get the state tracking wrong? Is it possible for us to ignore any valid events?

Also, is the behavior like the following?

1. User scrolls to 150% -> Driver clamps to 100%
2. User scrolls down 100% -> Driver sees this as scrolling to 50%

Does that feel intuitive? I'm not arguing for or against, just wondering if you've tested to see how it feels.

[hcarter-775]

Is the idea of the timer rather than just always tracking the state that we get protected for a certain amount of time, but still allow the device to send us new out of bounds events just in case, if if we were to get the state tracking wrong? Is it possible for us to ignore any valid events?

Basically, yeah. The timer basically protects us within a context window that we can be fairly confident about for this device. But as to why we need a timer, imagine this is scrolling a dimmable bulb. In the moment we can cap between -100 and 100, but what if later the user moves the level to 30? Then scrolling "up" should definitely do something. I think this strangeness speaks to the fact that this work is kind of a "stopgap" while the logic is moved to the bulb step logic more directly. So yeah, technically a >100 scroll is totally valid and so in a way, this would be ignoring "valid" events, but those >100 scrolls are not used by our current production logic.

Also, is the behavior like the following?
User scrolls to 150% -> Driver clamps to 100%
User scrolls down 100% -> Driver sees this as scrolling to 50%
Does that feel intuitive? I'm not arguing for or against, just wondering if you've tested to see how it feels.

Yeah I've tested all this and as far as the current use cases for the scroll, this is totally fine today, since past 100% there is no way the dimmable bulb would have anywhere more to go up, vice versa for down. However, User scrolls down 100% -> Driver sees this as scrolling to 50% is kinda wrong in the current implementation, it would actually go down to 0% if they did that, since the global state is clamped at 100/-100. Because we don't care about the scroll state past 100%, so we don't track it as different than 100% here.

[gharveymn]

Discussed offline for a bit. Clarified a typo in my original comment which should read "User scrolls down to 100%", and confirmed the originally postulation for the behavior was correct. Also confirmed that the behavior makes more sense having an arbitrary gate at 100%, where there might not be any tactile feedback on where that 100% is.