I don’t know much about coding, most what I do is copy and paste and trials, the format may be what I got wrong in there, hoping some of the smart people here can point me in the right direction.
Sensor 9 is a gcal search contact sensor, when it finds an event based on search word, it stay closed but shows the next matching event.
And when the event start that sensor shows open.
I can’t even get a direct input (no variables, etc) to produce an alarm on my Echo Show5 or my Original Echo or one of several Echo Dots (gen1, 2 or 3). The doc does mention that, “Not all alexa devices support this feature”. But with testing on many different Echoes, I’m not sure why this simple webCoRE piston does not work.
It’s just a proof of concept/test piston to see if I can get the createAlarm(…) command to work To keep it simple, I just added that command as a string using the parameters from the wiki that I showed above. I also added that same format as an expression too. But, so far, it doesn’t work in either case. But here is is:
However, there are some things about this that make it a bit odd:
Although the date parameter has to be there (I tried leaving it blank but then the alarm was not created), it doesn’t seem to matter much what date it is. It just needs to be there. Note that in my piston, I’ve got it set at January 1st. Works the same no matter what date I use. Anyway, in my testing, if the alarm you’re trying to set is later than the time the piston is executed, it will create the alarm for today - no matter what date you put in the parameter. If the time is earlier than the time the piston is executed, it’ll create the alarm for tomorrow - again without regard to the date parameter you set. So, in my use case, I execute the piston at 02:21 each morning. If we’re home, it’ll create an alarm for 07:30 later that same day. If I ran the same piston after 07:30, the 07:30 alarm would be created for tomorrow. Even though it’s a bit odd, it works for my use case.
It appears that single-event alarms become inactive after they execute (at the alarm time). That’s fine, but they don’t delete themselves from Alexa. This means that there will be an ever-increasing list of inactive alarms in Alexa - that at some point will need to be manually deleted. I’m going to test this for a while and see if it’s worth it rather than just setting a daily repeating alarm that I need to remember to pause when I’m going to be away.
In your case, the date parameter (as we’ve input it) does not have any discernible effect - and it is an issue. I’ll keep playing a bit and let you know if I discover anything else.
Since it appears that all three parameter entries for the createAlarm(…) function must be strings, using the two variables you created, you should try this : string(Hour":“Minute) as an expression in the parameter. If you wanted that to use the current time, it would be: string($24hour”:"$minute). You could also just define one string variable, say alarmTime like I did and then use it as the second parameter of the createAlarm(…) function.
In my case, I now have the date of the alarm created like this: string($year"-"$month"-"$day). Today, that results in “2020-1-19”.
I’ll need another day to confirm this, but… Contrary to what I previously thought, it seems that the new alarms - when created by the piston above, overwrite the older one . This is likely because in normal use the older alarms become inactive before the piston writes a new one - while in testing, I was leaving them active. Therefore, they will probably not require manual deletion. If this is not true, I’ll report back.
I use it to tell wc I’m on holiday so it can operate the lights in holiday mode.
In effect you create a virtual switch/event in the ST app, with a string to search for. When a calendar event is found with the string in, the switch turns on, until the event has passed. You can setup multiple events to fire the switch and also multiple switches for different occasions. e.g I also put my work from home days in, webcore then operates the heating appropriately.
I’ve been running the above Piston for the past week. Until today it worked as expected. Today, it ran as usual - including the log entry saying that it set the alarm. Except it didn’t actually set the alarm on the Echo. Although it sent the command to set the alarm, either the Echo didn’t receive it - or at least it did not set it. Since it is unacceptable for an alarm to not be set, and I am unaware of any method to check and retry on an Echo device as needed when it fails (like I have for ST controllable devices), I have discontinued use if this Piston.
As I am ‘recently’ retired, I don’t have this specific issue any longer. But you’re certainly correct. While I was employed for just over 50 years, I can’t imagine trying to use my smart home as an excuse for lateness.