The button is tough to pair correctly, may take a few tries. Delete it and try again, it eventually works.
Hopefully the pairing tricks in the post work (next to the hub, wait few seconds before scanning).
If it is not recognized as RODRET Button it’s not loading this driver and the configuration will be incorrect. If it’s recognized as ZIgbee Thing you have to delete it and try again too.
Edit: I understand it’s the button events what doesn’t work. If it’s only the battery, as @TapioX says in the next comment, may take some time to report the level.
Got it working. Paired it a couple of more times and eventually it just worked.
It got paired as a Zigbee thing the first times but I changed driver manually (something I have done successfully with other devices in the past but for some reason that didn’t work fully now). The last time I paired it I had it setup (although not working) with your driver and reset the device without removing it from smartthings - I just searched for a new device and when it was found it out showed up with your driver directly - then it worked. Not sure if that was a coincidence but could be with trying if others have the same problem.
Thanks, glad it worked! Yeah, it has specific configuration steps that won’t be executed when switching from Zigbee Thing. I’ll make it clear in the pairing tricks section just in case.
If the bulbs are zigbee, you could explore the idea of direct binding, this would bind the remote directly to the bulb(s) you want to control. You would do this by binding the remote both to the st hub, and then again to the bulbs using the dni.
@mocelet if you have a look at the source code for my tradfri group drivers, they also support direct binding. I don’t think group binding would work on this firmware, but direct binding to a single or multiple bulbs should work.
Should just be as simple as a new setting for a user to enter the dni, and then a couple of lines of code to do the device binding. This would mean the dimming commands flow directly from the remote to the bulb(s) and they don’t have to be interpreted by st hub.
Thanks for the ideas! I’ve looked at it. Zigbee binding code scares me a bit to be honest , so far I’ve treated all that stuff as a black box. I’m more at ease with handling button events like that STYRBAR arrow puzzle.
Looking at your code it probably would be easier to add the RODRET fingerprint and the Level.ID binding to your driver which already has the direct binding feature, after all the RODRET is pretty much a TRADFRI on/off switch, although you’re right and new IKEA remotes no longer support Group cluster.
I don’t even have Zigbee lights -they’re Matter-, so I prefer to focus on the smart button features that I use everyday and can maintain properly.
Matter is going to eventually support a binding feature, which is very similar to Zigbee binding, but most manufacturers are not using it yet.
Both Zigbee binding and Z wave direct association are really very simple once you strip away the technical terminology.
Each gives a trigger device permission to send messages directly to a target device on the same network without having to go through the hub first.
That has both pluses and minuses, depending on the use case.
Pluses: fast, reliable, local, works even if the hub is not working. Classic example is motion sensor which triggers a light to come on. Or in a two-way/three-way setup, having the auxiliary light switch always actuate the master light switch.
Cons: you can’t put any conditional filters on this, like, maybe making the motion sensor trigger only actuate the light when it’s dark. Or disabling something in a guest or party mode. once you have set up The binding, the trigger always actuates the target, no matter what. Also, it may be hard to keep the target device’s state synchronized in the hub’s app since the hub may not know what happened.
With matter, it’s going to allow binding between devices of different protocols and different brands, which is new. But again, the manufacturers don’t seem to be particularly interested in doing this.
Just wanted to mention it, because, even if you stick with only matter devices for the future, this issue may come up.
Actually those Cons are the reason why I am replacing my WiZmotes for WiZ lights with IKEA smart buttons now that I have the SmartThings hub (until recently I just used Google Home).
The WiZmotes are kind of a proprietary direct binding for WiZ bulbs (they use ESP-NOW protocol), but they just control a group of lights and can’t do anything else. No conditions, no individual control of multiple devices with the same button, no “toggle action”, they feel so limited compared to a smart button with good automations.
I haven’t, but it’s just the stock Tradfri on/off driver with minor modifications. In the implementation notes of the post you have the three changes that are needed, it’s just changing the fingerprints of course, adding the Level.ID binding to do_configure, the battery binding which needs a :to_endpoint(1) and the battery percentage handler which needs to divide by 2 the value.
device:send(device_management.build_bind_request(device, OnOff.ID, self.environment_info.hub_zigbee_eui))
device:send(device_management.build_bind_request(device, Level.ID, self.environment_info.hub_zigbee_eui))
-- tweaks: battery fix inspired by Vallhorn drivers by the great Mariano (Mc)
device:send(device_management.build_bind_request(device, PowerConfiguration.ID, self.environment_info.hub_zigbee_eui, 1):to_endpoint(1))
device:send(PowerConfiguration.attributes.BatteryPercentageRemaining:configure_reporting(device, 30, 21600, 1):to_endpoint(1))
local battery_perc_attr_handler = function(driver, device, value, zb_rx)
-- tweaks: rodret and somrig send double the value like the vallhorn, again Mc to the rescue
local percentage = utils.clamp_value(utils.round(value.value / 2), 0, 100)
device:emit_event(capabilities.battery.battery(percentage))
end
And that’s all the changes for basic RODRET support, the handler is exactly the same of the Tradfri on/off switch.
The fingerprint, just in case:
- id: "IKEA/RODRET Dimmer"
deviceLabel: RODRET Dimmer
manufacturer: IKEA of Sweden
model: RODRET Dimmer
deviceProfileName: two-buttons-battery
Binding doesn’t work well with all devices. @lmullineux created driver for some ecosmart remotes couple years ago that were available for purchase with bound lightbulb. They could be reset (unbound) and bound back to different bulb(s). Problem was that binding would spread to all lightbulbs of same manufacturer, and suddenly one remote started controlling all bulbs at the same time. Binding same remote with Ikea plugs worked well. Binding depends on how is implemented on individual bases. @JDRoberts Matter binding has been introduced on new Aqara M3 hub, that is not available yet. @mocelet i like your Ikea drivers the way they work now. They are not to complicated, but they are fast.
Thanks, speed is merit of the SmartThings team because the hub’s hardware is modest but they are good at optimizing stuff so everything runs smooth.
Most of the time a driver’s work is receiving a command (e.g. ON) and generating a event (e.g. Button2 pushed).
There are features that need to complicate things to work though, let’s say you want to create an actual dimmer switch with the RODRET like we talked. It can be done, you would have to periodically fire a timer while the button is held and update the brightness since the button doesn’t generate any event. That’s more load for the hub which needs to keep track of more stuff and more logic in the driver to take care of the timers.
I was thinking about dimmer when you said on one of your posts, that you can start timing on event. You would need setting for rampTime - period or speed it takes to get from 0 to 100% and rampRate - what percentage increases every second or millisecond(s), or something similar.
Any function comes at some cost. Some are worth and some are not, and that depends on users.
That is where that button ‘release’ can probably be used. I am not programmer, just user with some ideas.
In both Z wave and Zigbee, the typical way of handling a “multilevel“ controller (a dimmer for lights, an audio dial for speakers, etc.) is to first issue a “pressed” report, and then issue a “released” report. Some devices will also include a “starting level” value, but many will not.
The idea is that by looking at the timestamps for the Pressed and released reports You’ll know how long the control was held for, so you know how much to change the level.
This is supposed to avoid any issues with latency during communications, or any debounce algorithms being used on the device itself. You just get the official pressed timestamp and the official released timestamp.
SmartThings has very rarely implemented this approach, however, which is why you ended up with things like the official integration for the Sylvania Dimmer switch only being able to do on/off, no dimming. Even though it could do dimming on pretty much every other compatible platform.
Anyway, if there’s an additional report being sent, look to see if that might have the “start level“ value. That’s supposed to be so you would know that, say, an interval of one second meant to go up 25 from the starting position, so if the starting position was zero, the new level would be 25. If the starting position was 50, the new level would be 75. And so on.
Like I said, not all devices do this the same way. Some only send one report which includes the start level. Some actually do the calculations on the device itself and so only send the final level. Others force the device to reset to zero first and then set it to the new level. There’s just a lot of variation.
Depends on the device, but yes, “Held“ is common in devices which have a debounce feature so that the switch is going to do its own calculation before sending the start report.
Other devices may not distinguish between press and start they just send the first one when the switch is depressed, and then send the “release” if the switch was held for longer than a certain count. There’s just quite a bit of variation in this.
Introducing double-tap! And triple-tap and… sextuple-tap! That’s up to 14 actions to put the SOMRIG’s 6 actions to shame! Not that it’s a competition .
Fully configurable, including the waiting time for next tap so single-taps are not penalized like happens in the SOMRIG - which has massive ~1 second delay. Feel free to pick 200ms for fast-paced multi-taps.
The update is already published, will take a few hours to auto-update as usual. I’ve been testing it for some days because I didn’t trust timers but looks like they are reliable and on time .
If the feature is disabled for a button it will work as always, triggering events as soon as they arrive with zero delay.
SOMRIG was feeling low and wanted to be on par with the recent RODRET tweaks so I’ve just added both Toggled-Up on long-press release and Multi-Tap emulation to allow triple-tap up to sextuple-tap .
Definitely not a good fit for multi-taps: SOMRIG might just ignore presses if they are fast-paced. Also, you can’t choose the waiting window because the device already has a large one for its native double-tap and you just have to adapt to it.
It works though. Find a good slow-ish pace and you’ll have 8 more actions to trigger. I’ve been having fun changing the color of a light depending on six different number of taps with high success-rate.
A good use case for the extended multi-tap would be different brightness levels, for instance single-tap for turning on and then double tap for 20% brightness, triple for 40%, etc. Or switching day/evening/night scenes.
I’ve added another custom feature that I’m sure @milandjurovic71 will find useful as well as users of @Mariano_Colmenarejo Zigbee lights driver.
Just learnt here that his driver supports changing the brightness level by steps instead of absolute values like happens in stock SmartThings drivers.
The driver can automatically repeat the Held event while being held so you can set these actions for each button and emulate a dimmer switch without needing to physically press the button multiple times:
@mocelet thank you for doing this. There is a lot of potential with this approach. If this can be applied to other buttons, that means that many devices can become dimmers too. I am sure that other devs are going to implement this approach.
Anyway, can this or similar approach be applied on Ikea’s old and new Symfonisk controller. It has press, double press, held and rotate (level) capabilities, if i am correct. I think that rotate capabilities can be also used as single events CW and CCW (clockwise and counterclockwise). It could be simple remote or dimmer. Maybe you have something already?
, so far I’ve treated all that stuff as a black box. I’m more at ease with handling button events like that STYRBAR arrow puzzle.
.
.
. Also, you can’t choose the waiting window because the device already has a large one for its native double-tap and you just have to adapt to it.
