Hi,
Maybe you can permanently save the value, with persist=true. This survive to hub or driver restart:
device:set_field(key, value, {persist = true})
and retrieve value in the init lifecycle with
device:get_field(key)
2 Likes
Thanks for bringing this topic! I actually had that implemented for the preset feature until I read this in the official documentation:
Similar to the transient_store, this is for use for driver specific information, however, unlike the transient_store, information written here will be stored and persisted through restarts. This carries with it a cost in wear, as well as time delays associated with the writing and reading. This should also be accessed through the
device:set_fieldanddevice:get_fieldmethods. A good example of a target for the persistent store would be something like the number of lock codes a lock can support. This is something that only needs to be read once when the device is first joined, and wonāt change for the lifetime of the device. This could be read every time the driver restarts, but it is reasonable to read once and store for the lifetime of the device. In order to protect the longevity of your hub device, we limit how frequently values are actually written to flash. This does, however, come with a potential loss of information. When the persistent store for your driver is āwrittenā it is cached in memory and will actually be written to flash on a schedule and on graceful shutdown. This means there is potential information loss in the case of a power loss.
It was scary enough to not use it for something that is going to change even multiple times in few second 
1 Like
If you have to write many times then you can still use the last state of the capability, which is saved in permanent memory. It could has some delay in store value.
You retrieve the value in the init lifecycle.
active_scene= device:get_latest_state(component, capability.ID, capability.attribute.NAME)
If active_scene == nil then active_scene =0 end
3 Likes
You are right!! Have to test it, thanks!!
Edit: It works indeed!! 
The latest_state function even has a parameter to return a default value so it returns the cached one or the default one.
device:get_latest_state("main", active_scene.ID, active_scene.scene.NAME, default_scene)
Ā”MuchĆsimas gracias! 
The new update is: 2024-04-05T12:05:19.300512731
3 Likes
New update (2024-04-06T13:00:07.436768095). Mandatory bugfixing and:
Detects unwanted side-effects and potential infinite loops when a scene number activation triggers some changes that trigger a routine that also changes the scene number. I bet 99% of the time you donāt want the scene to activate again or change, for that 1% you can disable it in the settings.
It sets a small 800 milliseconds window where it will ignore certain commands like Initial, Final, Default and Scene N to set the scene number after itās been just changed. There is also another window for all the other actions (disabled by default with 0ms) that can be used as a generic debouncing mechanism for smart buttons.
(BTW, the 800 ms comes from the observed 300-600 milliseconds that would normally take a routine to activate a scene on a brightness change after being triggered by another scene activation that changed the brightness of a light)
2 Likes
I donāt know why, but Iām reminiscing back to the days when Smartthings was fun. @bravenel
6 Likes
Thanks! Iāve been using SmartThings as main platform for just two months but I know in the groovy era there were lots of cool āsmart appsā so thatās quite the compliment! That Rule Machine, the Advanced Button Controller, etc.
Itās funny because this journey started with a secondhand hub just because it was the cheapest alternative for my automations with Matter sensors to work locally. Little did I know I would end up creating drivers for it! 
I like the balance between ease of use and functionality.
2 Likes
Since this tool can do too many things, and more coming 
, Iām publishing tips or small tutorials from time to time like the blinker few comments above. Eventually will link them in the first post.
Tutorial: Make any button multi-tap capable
You can add double-tap, triple-tap and more to most buttons compatible with a SmartThings hub. Supports all single-tap buttons as well as buttons with native double-tap to extend them to triple-tap and beyond.
Follow instructions in first post to install the driver and create the first Switcher if you havenāt already.
-
In your button, assign the Pressed action to the Register Pressed action of the Switcher. If your button has native double-tap, do the same with Double Pressed and Register Double action.
-
Done!
Now you can create multi-tap routines depending on the Switcherās active scene number. Scene 1 is single-tap, 2 double-tap, etc. -
Depending on the button and your preferences you may need to fine-tune the multi-tap emulation. In Switcher settings the relevant tweaks are:
- Number of scenes: thatās the maximum multi-tap sequence. If you only want up to double-tap pick 2, for triple-tap 3, etc. It will make the longest sequence trigger earlier without waiting for more taps.
- Multi-tap waiting time: this is how long the driver will wait for the next tap to consider it part of the sequence. You may need to increase it if your button has native double-tap or inbuilt debouncing and set it to around 1000 milliseconds.
The experience may vary: some buttons implement debouncing and will just ignore multiple consecutive taps if performed fast. Find a tapping pace that works with your button, maybe increase the waiting time too.
Edit: The virtual button in dashboard introduced later also supports multi-tap, just pick Multi-tap: N-tap for Scene N in the Dashboard button action settings. The window in that case is fixed.
3 Likes
New update (2024-04-08T19:55:17.403290766). Might as well be called 2.0!
How would you do this automation? āIn around 3 or 4 hours turn on the lights of an arbitrary roomā.
Auto-cycle just got superpowers with a new mode! Long spanning time frames of up to 24 hours per step, random delays and automatic backup of 1-minute or longer delays to restore it if possible after a hub or driver restart.
Things you can do:
- Run a specific scene after a random time. Example: āturn off this light in around 3 or 4 hoursā
- Run a random scene after a random time. Example āturn on this light in around 3 or 4 hours with red, green or blue colourā
- Run a sequence of scenes with random intervals. Example āturn on the living room lights, wait some time between 30 minutes and an hour, turn it off and turn on the bedroom, wait again, turn on this, waitā¦ā
- Run a random sequence of scenes with random intervals. You got the point.
Should fit most presence simulation routines or other lighting scenarios like parties, cool pomodoro timers, I donāt know, just donāt use it for critical or personal-safety stuff. Had to add the disclaimer 
Introduction to the new Long Spanning auto-cycle
- Switching delay is in minutes and you can specify an Additional random offset. If you want something to run in the interval between 20 minutes and 1 hour, the switching delay would be 20 minutes and the random offset 40 minutes.
- Starting scene also delayed makes Auto-cycle actions delay the first switch. Normally the first switch happens immediately and then applies the delay for the next switch. Useful for those ādo this after X timeā.
- Switch only once makes auto-cycle stop after the first scene switch. Useful if you have more than one scene and want to run one random scene after some time but not cycle through the others.
Quick tutorial:
-
To run one specific scene after a random time:
- Create a Switcher. In settings, select Number of scenes 1
- In Long Spanning section, set a Switching delay in minutes (that will be the minimum) and the Additional random offset. For something between 3 and 4 hours it would be a delay of 3 * 60 = 180 minutes and a random offset of 60 minutes.
- Enable Starting scene also delayed.
- Done. You can run the Auto-cycle [ > ] action from a routine, button, etc. and the scene 1 will trigger after a random time. Map active scene 1 to your action like turning on a light.
-
To run one random scene after a random time:
- Same steps, but: Number of scenes is the number of your scenes (letās say 3 for a light to randomly turn on green, red or blue). Enable Switch only once so it only triggers one scene and the Auto-cycle action is the one with [ ? ] since you want it random.
-
To run a sequence of scenes with random intervals:
- Similar. Set Number of scenes and map the actions. Pick Linear in Cycle mode so it finishes at the last scene, make sure Switch only once is disabled since you want to cycle through all scenes. In Auto-cycle settings pick Starting scene Initial if you want to always start in scene 1. For the action use Auto-cycle [ > ]. Starting scene also delayed to your taste, if you want scene 1 to start after the delay, enable it.
Always have a standard schedule as a failsafe: A sudden power loss and restart of the hub would make the auto-cycle not able to restore the timers, just like any other driver. Account for it by adding standard schedules past the random times to have the peace of mind that if something has to be in a specific state by certain time, it will be.
2 Likes
Build a Pomodoro timer with smart lights
The Pomodoro technique is a method to balance focus time and breaks to keep concentration high. There are intervals of focus of around 25 minutes followed by a 5 minute break and all repeated 4 times. Then you get a longer break and restart the timer.
Letās build one with just two routines. I will use the colour of a smart light to indicate if itās focus time (blue) or break time (red). You can add notifications, announcements in smart speakers, etc. Will start the timer with a button but you can start it with anything else, like a voice assistant command triggering a virtual switch.
Here goes a tip. The scene switcher cannot have different delays between steps, unless they are random, and we need steps of 25 minutes for focus time and 5 minutes for short breaks. The workaround is creating āticksā of 5 minutes. Focus time will span 5 ticks, short breaks 1. Thatās 6 ticks, usually repeated 4 times.
Switcher settings:
- Create a new Switcher using instructions in first post
- Number of scenes to cycle: 6
- Starting scene: āInitialā
- Circular behaviour if not stopped: āEnds right before starting sceneā
- Circular max loops: 4
- Inside Long spanning auto-cycle: Switching delay: 5 minutes
The scenes / routines:
- If Active scene matches 1 Then set your light blue.
- If Active scene matches 6 Then set your light red.
To start the Pomodo timer use the action Auto-cycle [ > ] that you can assign to a button or routine. To stop, use the Auto-cycle [ STOP ], you can even create an automation so when the light turns off, the STOP action runs.
(Edit: the virtual button in dashboard introduced later can control the timer too, in Dashboard button action choose Smart Auto-cycle [ > / Stop ].)
You can test that everything works by setting 0 minutes, that will make focus intervals last 5 seconds and break intervals last 1 second so the whole run will take you 24 seconds.
2 Likes
Itās hardcoded to be Next which I think is the most sensible action for the button. Thatās what PR told me to say .
There is no update needed because it is a presentation update, but it can take hours for the button to appear. In my Galaxy tablet it appeared at the moment, in my Oppo phone it can take forever even deleting the app cache.
Thanks, it works great. āNextā is what I was hoping to use it for. It allowed me to eliminate a virtual button.
The button showed up right away. Something seems to changed with the ST App in the last few days and presentation changes show up much quicker.
3 Likes
Anytime, Iād like to make it configurable though, but that requires more changes and extra care to not break things. Starting auto-cycles could be useful too, for instance to start the pomodoro timer of the previous post! Or making the button smarter in Linear cycles so when it goes forward and reaches the end it goes backwards (Next would just get stuck in the end).
2 Likes
Iāve published a new update (2024-04-11T06:48:48) in preparation for a customizable dashboard button. It is going to be a multi-step process and no features are added yet, but please let me know if something breaks in the following hours/days.
The details, just so I donāt forget it . Making the dashboard button configurable requires:
- Updating the capabilities to add a new command value.
- Updating the presentation to invoke the new command instead of the hardcoded āNextā.
- Updating the driver to understand the new command, add settings to pick the behaviour, add logic, etc.
Step 1 is done, should not break anything, but it can take at least 18 hours and Iāve read things about taking even days.
Step 2 cannot be done before 3 or the button will break, but 3 without 2 will not work as expected.
Iām playing it safe here so the pre-update just makes the new command invoke Next internally. In a couple days Iāll update the presentation so the dashboard button invokes the new command. Functionality will not change since internally it will do a Next just like now. After a couple more days, when thatās working for everybody Iāll introduce the customization features and update the driver. If there is any issue with the updated capabilities Iāll just revert back the presentation to invoke Next and forget about the customization.
I have the updated driver and everything still seems to be working as expected.
If see any problems I will let you know.
1 Like
Great, I read here that capability updates take up to 14 hours so tomorrow will update the presentation, hopefully without anyone noticing. Then Iāll be able to test the new feature with the production capability and publish a new update with the settings to customize the button.
Thanks again for the idea of the button, itās actually pretty useful! Now Iāll remove a bunch of āmanually run routinesā and implement them directly as scene actions, using the button to switch them if I need manual control with the phone.
2 Likes
New update: the Virtual Button got smarter (2024-04-12T05:38:31.413843796)
This got out of handā¦ the driver now doubles as a Virtual Button with multi-tap! 
Gimmick aside, the dashboard button is more convenient now, especially in Linear cycles where the standard Next would get stuck at the end:
- Smart Next / Previous is the new default. It is a Next in Circular cycles but, in Linear cycles, will go forwards until reaching the final scene and then toggle backwards until reaching the initial scene.
- Looping Next will loop with the virtual button even if itās in Linear cycle mode.
The virtual button can start/stop automatic actions with Smart Auto-cycle. Two flavours, forwards and random. The button will start the auto-cycle if it is not running or stop it otherwise. Now you can start and stop the Pomodoro timer or the Light blinker from the app!
You can also run specific scenes, Surprise Me will activate a random scene, now you have a virtual dice roller of Number of scenes sides! Default scene will activate the selected scene number in settings and Reactivate re-trigger the current scene or the preset depending on the mode.
To use it as a Virtual Button with multi-tap, Multi-tap: N-tap for Scene N. Instead of cycling, a triple-tap in the virtual button will run the actions of scene 3. The window is fixed at 1200ms.
Finally, you can disable the action, maybe you donāt want to trigger anything if you press it by mistake scrolling through devices.
Notes: A word on caches, sometimes when you change a setting in preferences, like the number of scenes or a mode, SmartThings ignores it. In that case setting it again usually helps. Also, the driver may take few hours to auto-update and there might be cached elements for the next few hours.
I got the update and everything seems to be working as expected.
Now that is a multiple tap button I would suggest changing the icon from a āthingā to a " remote".
Thanks again for sharing.
1 Like
Thanks, glad itās working! I tried to change the icon, itās easy, but now I canāt tell which widgets are the scene controllers and which ones real remotes like the RODRET.
I kind of like the default icon with four elements since, in my mind, it represents a group of four scenes where one is selected and the main purpose is managing groups of scenes 
Other drivers seem to allow changing the icon by switching profiles but that would not be viable here, the profile alone is 200 lines and would have to duplicate it changing one line, making the driver bloated and harder to maintain.
4 Likes
Got it. It is fine the why it is.
Thanks again
4 Likes