I moved all my routines to CoRE.
More flexible, reliable, and debuggable and now I can leave simple “routines” available for my GF to use from the widget. Win win.
3 Likes
You can do this in CoRE too. Use “notification”.
What devices are you using with this routine?
One of the core problems with ST is that some of the community apps are more reliable. One would think that the official apps to through a set of tests that they could be trusted. I’d be embarrassed.
I don’t see it as a problem, but a strength. I prefer to work with systems that allow my participation in improvements. I hope ST copies the hell out of CoRE and the way it works to improve their own SmartApps. That’s the point of Open Source and open API’s.
In addition, the community collectively spends more time using the product than ST does. They spend time in reality. The problem with engineers is that they often design for the perfect world and are unable to take into account the real world to the level of the consumer. I spent years working in quality departments, ask me how I know this, I dare you… 
Have a strong community to complement ST is one thing, depending on it to fix your mistakes is another.
1 Like
[quote=“bridaus, post:25, topic:57367”]
The problem with engineers is that they often design for the perfect world and are unable to take into account the real world to the level of the consumer…[/quote]
Hey, I resemble that remark 
Good morning!!! (ha ha ha, delayed, as it is now well into the PM hours)
It has not failed, it’s just slow…
4 Likes
Yes, but this would be a pre-fabbed message. For example, it will give me a message saying “Everything happened that you wanted!” whereas using a routine, if I ask it to lock the door and it fails, the notification will tell me this. Routines use dynamic notifications vs the static, pre-programed notifications in CoRE.
@JH1 For example, here is a notification I have received from my Good Night routine:
“Good Night. I am already in Night mode as you requested. I confirmed that the locks are already set according to your preferences. I turned off the living room lamp”
Now, if the house wasn’t previously in Good Night (my Good Morning routine failed.), it would have told me it changed the mode to Night, etc. So based on the devices current status, and if it is changed, it will report accurate notifications.
By using CoRE notifications, I can type up the notification to display however it will not be dynamic. It will be a present message that runs every time, whether the doors lock or not. @ady624 can confirm this, should I be missing something.
[EDIT] On a side note, I’m noticing that My Good Morning routine has failed every day, since 9/6/16. That’s as far back as I went in Notifications to determine this, but at least I can confirm this is happening to me as well. Mine’s unnoticeable since all it does is change the mode to ‘Home’ at a certain time.
I see. That makes sense and I forgot about that.
I am wondering if there is a good way to a core piston to execute then followup with routine. Almost like a series of followup routines that execute the items you want to confirm… So you run good morning, which a piston sees and runs a series of actions, then last kicks off a ‘good morning followup’ routine which does the critical items again and THUS you get the notifications you want as well.
And this is actually something I might do for going to Night mode and Away modes… as I want confirmation certain things have happened. I am not jumping on this right away however, because I am not sure I will read through those details and catch what is missed.
I’m not sure what you are trying to demonstrate? Is it the notifications? If so, that still doesn’t achieve what I was referring to as it’s not dynamic.
If you were trying to explain how to use CoRE to change modes, that I understand. My hesitation with this is the level of notifications I receive that verify the state of the things in question.
1 Like
I was trying to demonstrate both things you discussed above.
- you can enter what you want to be told.
- you can test for conditions and be notified that an event has failed.
- you can initiate a correction.
Where in those images are you notified of a failure? I only see static messages which will be sent, whether the mode actually changes or not.
Let me clarify. CoRE executes to change the mode. The execution in CoRE will trigger the message, even if the ST cloud doesn’t respond to the mode change. So CoRE thinks it changed the mode, sends the message, but in reality, the mode never changed. This is my problem, albeit for locks, lighting etc.
The thing with CoRe. It keeps on checking. It will run the action which I demonstrated and after a while it will check again and execute again. You are correct that I should add a case to my logic for a secondary notification. I am will be creating it later tonight.
You can build dynamic messages with CoRE. You can actually fully emulate that message you have from routines, but it will take some CoRE coding. You can read the status of a lock into a variable, you can even branch an IF based on that…
Using lock...
> Save attribute lock into variable "doorLock"
> IF ({doorLock} == 'locked') THEN
> Set variable message = 'The door was already locked'
> ELSE
> Set variable message = "The door was not locked, but I am locking it"
> END IF
> Lock
Then use the message as part of a bigger string, to concatenate whatever else you want. You can also use system variables like $currentEventValue etc. which can obviously make the message dynamic. At the very end, use a location to send the notification:
Using location...
> Send notification message '{message}'
2 Likes
@ady624 Woah. mind blown
Guess I have some playing around to do. Thank you for this!!!
I’m going to assume that the variable building all must be done in the same piston? So one piston would have defined variables, and then the actions, tied to variables and messages?
1 Like
You can share the variable with other pistons too. Each can actually maintain its own - use @ in front of the variable name - then have a piston that merges all messages together to send the final message as a notification. If you name your variable @something (start with @) - then that variable is available to all pistons. Read/Write.
Ok, thank you! I’m going to play around with it on a basic front, with just one action and build upon from there. I have a feeling you may be seeing me with some questions in the peer help for piston’s thread!
Is there a list somewhere of system variables? More-so, is there was a state change variable per device? I could leverage that to only send a message regarding what changed. If the doorlock.StateChange = false, it was already locked. If doorlock.StateChange = true, it wasn’t locked but now it is, etc.