I tried to search if this has been asked before but I’m not sure. Also I’m not sure if this should belong to Feature requests but anyway.
Is there a way to build clock tile and run SharpTools rule or turn device on based on chosen time? And I’m looking similar user friendly way to choose time like it’s done for example with Android Phones?
I mean easy and dynamic clock where time is adjusted by user and then deciced what should happen at that time.
I would be using it with my car heater to turn it on for example before going to work. Timer that I use now is build with webcore piston and virtual switches. (static times). First I click clock icon which opens dashboard.
Well yeah probably it could be fine solution. I did not even think that this is doable at the moment. It would be better if it there would be a way to scroll the time and save but this solution could be useful. Anyt tips how to build that kind of variable and rule. I mean I haven’t done anything with sharptools rules yet.
Sorry, I’ve looked into it a bit and can’t find a way.
I hoped you could use the variabel, to change a trigger’s time or something, but that’s not possible. Looked into other workarounds but can’t readily find something.
I’ve gone about this two different ways – one that works great (but doesn’t offer maximum flexibility) and one that gives max flexibility (but relies on another rule to run).
The one that works great:
have the user set the time on a dashboard (make certain the formatting is consistent in the IF statement below)
set triggers that happen at preset times (not maximum flexibility)
I set these up for 15 minute intervals - however, if the user (or my kids) sets the alarm clock not on a 15 minute pre-defined interval, it won’t work.
The other option (not recommended) requires a rule to be run every minute which checks to see if the current time is equal to a user inputted variable:
Yep there is a way to achieve this by using webcore too. I’m guessing there could be way to send time variable from tile “device” to piston and then set timer. I was just thinking if there could be nicer way to do it and with that android style
The request still isn’t super clear to me, so I’m unlikely to convert this thread into a feature request. Having vague requests as the first post in a feature request yield less-than-ideal results as people tend to vote based on what they have in their head rather than a formally scoped / written request.
That being said, if someone wants to clarify the scope and create a feature request, that’s certainly fine.
From what I understand, it’s a request for a time-picker type UI in tiles… but I’m not sure what the rest of the expectations are around how to use it. It seems like it would require rules for it to work since it requires being able to schedule something. So my gut tells me it would make the most sense as a new ‘Time’ type of variable… then you could add that variable to your dashboard - which of course would have a new ‘Date/Time’ Variable Tile Layout (much like the current number, text, and true/false types) which would probably have some settings around what’s displayed*. Then you could use that variable changing as a Trigger in your rules to schedule the device running.
*The features of the Date/Time variable tile probably needs some scoping too. I suspect it would be a Date/Time variable type and then you could control which parts of the variable are displayed/set within the tile settings. For example, you could pick to show just the Date, just the Time, or the Date + Time. But I would need to think through the implications of that and if another approach might be better (eg. being able to subtype the variable type).
Hi! I think you got that right. My use case would be an automation for electric shades. I would like the user to set the time when shades go up or down. That would require a UI to set the time, a variable to store it and a rule to execute at the given time. I can think of other use cases but all similar.
Hi @FNI_heater - welcome to the community. As mentioned further up in the thread, there’s not a dedicated UI control for selecting a date/time from a dashboard, but there are different approaches you could take depending on your needs. For example, some people have used variables as inputs to their rules while others have created dedicated dashboards to display a ‘list’ of preset times they could select. If you really wanted a clock-like UI, you could use a Custom Tile to accomplish that but you would need the requisite developer skills for that approach. (And you’re always welcome to create a feature request as noted further up in the thread)
As for the second request, you might consider posting your own thread for that with a relevant title so other community members can see it and chime in. You could create a rule that you run to turn on the outlet and then turn it off after a delay… or if you always wanted the outlet to turn off after a set time, you could setup a rule to react to the switch itself turning and then set the timer based on that.
We used to have an app (?)/site that we could go to under herokuapp that we could manually enter a date and time to turn a switch on. Is there a way to do that under smarttools? I might be able to get the old code but I am also trying to learn this for myself as well.
Or, could you point me towards how to learn how to create a manual date and time entry to start a process? I have successfully created a tile/rule that will turn the outlet on for a timeframe and turn it off.
If you still have the app hosted, you could embed it into your dashboard using a URL Custom Tile. Alternatively, if you have the requisite developer skills, you might be able to use the HTML Custom Tile to have it all run natively within SharpTools.
Can you share what you’ve tried so far? There’s a few different approaches you could take for this. @Jason_K_Jennings shared an approach that worked for them further up in the thread which allows a fixed set of times.
Another approach would be to store the desired time in a variable, then use that variable changing as the trigger to start the rule, and use an expression to calculate how long you want to delay before running the action.
This approach would involve writing an expression to parse the input date, then calculating the number of seconds between now and your target time to determine how long to delay for.
One downside to the ‘delay’ approach is there’s not a native concept of ‘cancellation’, so if you wanted a cancellation feature that would require some more involved logic for snapshotting your ‘timers’ and being able to flag them for cancellation.
And here’s the raw expression in case you wanted to copy-paste and tweak:
#// add the current date to our timestamp to ensure it is parsed as 'today'
today = formatDate(now(), "YYYY-MM-DD ")
fulltime = concat(today, $targetTime)
#// parse the target time as a timestamp (using the version with today's date concatenated in)
ts = date(fulltime, "YYYY-MM-DD hh:mm A")
#// if the time is BEFORE now, add a day to it since we probably want that time tomorrow
ts = (ts < now()) ? addDays(ts, 1) : ts
#// calculate how many seconds until our targetTime (it's in millis, so convert to seconds)
(ts - now()) / 1000
In the example rule, the rule is triggered any time the $targetTime variable changes. In my example, I’m setting the variable in the format 7:30 AM.
The first step in the rule flow is a Delay action using an expression as the source for how long the delay will be. The expression is well commented, but here’s a summary:
Parse the variable as a date using the format mentioned above hh:mm A → 7:30 PM
Adjust the date component if needed: if the time was before now, add one day to it as we mean tomorrow, otherwise use the raw time
Since we are only providing the time, the system assumes the date as today. As such, we may have to adjust the date to tomorrow to perform the next calculation
Calculate how many seconds are between now and our target timestamp (in seconds)
The dates are in milliseconds by default, so divide by 1000 to get seconds
This is just a starting point and you could adapt the rule to your needs as you see fit. For example, you might want some conditional checks to make sure it’s a valid input time format (otherwise the delay will default to 0).
As mentioned in the original post, this version also just schedules an execution every time the variable is changed, so you might end up with multiple scheduled executions in parallel if you changed the variable multiple times. It would get a bit more involved, but in theory you could keep track of each scheduled execution within a variable which would allow you to ‘cancel’ an execution by adding a condition after the delay which would determine if that particular execution should still run. Or you could adapt the logic as you see fit not to allow parallel executions or whatever your particular needs are.
Hi Josh. I am attempting to use this for a project but am having issues. I am trying to enter a time manually in a variable, convert that time to an epoch timestamp in millis and use that timestamp variable in another calculation.
When I enter a targetTime that within the same day, I am getting a timestamp that registers to the next day, not today.
current date 1/23/2024, current time is 7:00 PM
targetTime variable 10:00 PM
#// parse the targetTime variable as a timestamp
ts = date($targetTime, "hh:mm A") // returns epoch timestamp of 1/24/2024 10:00 PM
I tried adding this part (which I don’t actually need to do) but get the same result as above.
#// if the time is BEFORE now, add a day to it since we probably want that time tomorrow
ts = (ts < now()) ? addDays(ts, 1)
It works perfectly if the time is the following day. What am I missing?
Ah, that’s right. I recall running into this in the past. If the rule runs later in the day where it’s potentially already tomorrow in UTC, you can’t parse just the time. One trick is to concatenate in the current date with your time string, so when you parse the time you can be sure it’s the current time today:
So back to our example, that might look like:
#// add the current date to our timestamp to ensure it is parsed as 'today'
today = formatDate(now(), "YYYY-MM-DD ")
fulltime = concat(today, $targetTime)
#// parse the fulltime including today's date concatenated in
ts = date(fulltime, "YYYY-MM-DD hh:mm A")
#// if the time is BEFORE now, add a day to it since we probably want that time tomorrow
ts = (ts < now()) ? addDays(ts, 1) : ts
#// calculate how many seconds until our targetTime (it's in millis, so convert to seconds)
(ts - now()) / 1000
In case you’re curious about alternative approaches, here’s one:
Alternative approach
Set Date Parts to Today
You have to set the date, month, and year otherwise you could be on the edge of a month or year and tomorrow is actually the next month or year
ts = date($targetTime, "hh:mm A")
#// set the date, month, and year to today's
ts = setDatePart(ts, 'date', getDatePart(now(), 'date'))
ts = setDatePart(ts, 'month', getDatePart(now(), 'month'))
ts = setDatePart(ts, 'year', getDatePart(now(), 'year'))
What do the rule logs say with the debug filter enabled?
And where is AlarmSetTimeClock being set? Based on the other variables that are getting set, it looks like you have some other dependency chain here? I see that a different variable AlarmSetTimeHour is being set to x at the end.
If you want to share the Rule ID, I can take a closer look. Hard to say without additional details / debugging info.
