So, this works, but.. man..
It seems the device or Homey buffers up to 18 clicks and then releases it, or releases it after a small delay with no input. So if you rotate it for a while, then stop, you’ll get 18 → 18 → 18 → … → n (where n is the remainder). My best idea is to capture all into a variable, and on variable change, change the relative dimming the value of the variable. (Gotta check if 18 → 18 counts as a change, too).
This is ugly. Anyone with better implementation or better ideas?
Yeah, I already use Better Logic, so I’ll make that swap, that’s a good suggestion.
Here are all When cards (and I’ve double checked that there are no variables or And or Then cards):
The “ was pressed” is triggered once per “buffer release” (so continuous rotation gives 1 “clicked” per 18 clicks, whereas the “ was pressed times” set to 1 time, only triggers if the actual released buffer was just 1.
If you’re increasing or decreasing something based on the rotating of the scroll wheel, why not just check for “1 up rotary was pressed” and then increase something based on that? You can set a relative dim value for lights (add 10% dim level each time you rotate the scroll wheel up one click) for instance, or you can increase and decrease numerical variables:
Logic: calculate <numerical variable> as {{<numerical variable> + 1}}
Well, mostly because then I can rather use the new two button remotes from IKEA instead of this. I could then just “when button long pressed” and start dimming up. If the rotary doesn’t work to continuously dim, it’s essentially wasted to have one.
I use it as a dim button for 2 dimmable lights (one Zigbee and one Matter) and to “dim” the volume om my TV (through IR). Works a treat. Continue to rotate it up → the light (or volume) will continue to dim up. The same for down, obviously. And I press the scroll wheel for on/off (or, in case of the TV: mute). For the TV I also added long press (pause/resume) and double press (on/off).
There’s only a slight lag of maybe 1/10 sec which is not too annoying.
It’s a good point. The 18 click buffer already means there’s delay, since something only happens once every 18 clicks if you rotate continiously (which takes some time). I’ll continue exploring. Didn’t work as seamless as I hoped Thread+Matter could provide
I have a battery powered dimmer-remote from Robb (Zigbee) which directly reports the dim level, so you can just set the absolute dim level directly based on a change of the dim level of the remote. Which sounds easier, but it’s the exact same number of cards. Just a different method. The only advantage is that it responds quicker to a quick rotation: if you want the light at 100%, just give if a mighty shove and it’s at 100% immediately. I wouldn’t want that for the TV volume though…
Also, the way this was implemented, you can use this for things that need a value outside of 0-100 which I can’t do with that dimmer remote. Here’s my simple flow:
Yeah, this card
should have a tag available like this card below has; In that case the “dialed” number (1~18) will be available in (Adv.) Flows as tag to use in connected card(s)
Then, this would be possible:
To dim a light, with the range from 0 - 1, you can use the balue of a numvar per logic calculation card with the expression
{{ round ( [tag with dialed number] * 0.05555 ,2 ) }}
as dim value in the light card itself
(the “round (x,2)” mathjs expression rounds the result to 2 digits)
min:
1 * 0.05555 = 0.05
max:
18 * 0.05555 = 0.99
Ex:
Maybe you can discuss adding a tag to the dial card with the app developer
Yeah, I’m very curious about the limitations that go into the up-to-18-clicks-per-event. But a naive approach like waiting for the scrolling to stop would prevent anything happening along the way. A poll rate where you send how many clicks have gone into the last period could tell you how fast someone’s rotating and give easy acceleration too. I can see if I can make a suggestion to the app dev
