Both Parent and Child Version R.0.0.5 have been released:
Parent App - added ability to cancel active retriggers from the app touch (the first in a series of enhancements that enable users to manually cancel retriggers). To see what is the LAST active retrigger, I added a new section on the bottom of Parent’s Main Page (to see what retrigger is active and can be canceled) Child App - minor bug fixes. Added a new variable &last, that can be used with ‘Custom Text’. @Navat604, this may be interesting to you, as you can use it to know the time the door opened, even though you get the message only if the door remains open for x minutes.
The custom text would be:
&device has been &action since &last. This translates as 'the door has been open since 2:40 PM …
Have you installed both apps? There is a parent app and a child app that need to be installed. Looking in your ide, under SmartApps tab, you should see these two apps…
Have you installed both apps? There is a parent app and a child app that need to be installed. Looking in your ide, under SmartApps tab, you should see these two apps…
As users may know, when setting a recurring event in SmartThings, the FIRST instance is fired randomly, immediately after it has been scheduled.
RemindR events never start randomly when you press “Done”. This is a SmartThings’ “feature,” to automatically fire a recurring event (with a future starting date), immediately after it has been scheduled.
We treat timing of when the first event is fired, as very critical, therefore we ensure that first notification is delivered ONLY at the scheduled time and NOT randomly after it has been scheduled!
Pushed a small update to the chilld app - link is on the first post of this thread (Release version: R.0.0.6b),which fixes some issues with multiple notifications being played on remote speakers when triggers selected are either routines or modes. Thanks @Daniel_Edge for your help debugging!
I am unable to replicate this. What was your exact trigger? One thing I noticed, is that required starting time is slow to register and/or refresh. If the time input is not recorded, the cron job would fail to save (not saying that is the case - just a personal observation).
The only thing I can add from the higher logging levels are the following logs: 11:19:36 AM: error physicalgraph.scheduling.CronExpressionException: Invalid cron expression found '0 00 06 1/null * MON-FRI *' @ line 2135 11:19:36 AM: debug con var is Daily 11:19:36 AM: debug Updated with settings: [xDaysWeekDay:true, frequency:Daily, alexa:false, actionType:Custom Text with Weather, xDaysStarting:2017-06-03T06:00:00.000-0700, tSchedule:Recurring], current app version: R.0.0.6b
