@ady624 thank you. yes, i see those but may be i am misunderstanding … it shows the trigger or condition subscribes to an event not the event per say. sometimes, being able to see the event subscription and possibly even webcore’s event queue would be helpful. may be i am just being a geek … but i don’t see another easy way of knowing what all the possible events and data are that get generated…
Well I had noticed those before, but didn’t realize that was the gutter or what the meaning of the symbol is. Is that in the wiki somewhere?
On another note. Question about backup codes. What is the difference between the “click here to reveal” code and the code shown with the red camera? I noticed on some of my pistons they are the same - and on others they are different. The real question is, which one should we keep in a cookie jar in case we accidentally delete WebCoRE and have to recover them all.
And, one more. I currently have two instances of WebCoRE on my iPhone. I’d like to delete one of them, but want to make sure deleting one does not delete all. The warning says it will delete WebCoRE - not necessarily that particular instance. I’m sure it’s safe, but I’d hate to recover everything for a dumb mistake
Guys - what do you find is a good approach to logging messages from pistons for things that are not critical but rather just to keep an eye on things. For instance I want my piston to log each time it turns on and off the dehumidifier. For a long time now I’ve been sending these as SMS to my iPhone and then putting Do Not Disturb on the number that ST sends SMS messages from.
This is convenient because the messages are right there any quick to access from my phone. But its annoying because several times a day I have a “text message bubble” on my phone indicating a SMS has arrived and I can’t tell if its a real text I missed from someone or a ST message without opening iMessage…
I just tried the Push notifications instead. This is equally annoying because they beep and pop up. I can see why this is useful for very important messages, but for “info” type messages its bothersome.
The Messages section in SmartThings Notifications is a good place. It’s quiet, meaning it doesn’t get in my way. But on the downside, its a bit of a pain to access… You have to open the ST app, then navigate to the Notifications section, which takes more clicks then I’d like.
Is there a better / more convenient place to have webCoRE write messages, and if so, where? What do you guys do for tracking that things are working as they should via messaging?
Also is there a way to write messages from webCoRE into the Messages section of the ST Notifications, without sending a SMS or Push notification? If so, how? I see the Send SMS and Send Push actions have the option to also write the messages into the Messages, but what if you wanted to write to the Messages without SMS or Push?
@ady624 thank you for clarifying. how about an event stream … to differentiate from a queue … events shows up at top of the stack as they come in? i know there is at least a -1 version of the event that is saved somewhere … may be saving the last 100 or so events in the event stream and exposing that? (for testing purpose, it would be awesome if we could even generate/regenerate these events, don’t know if that’s a stretch.)
I just started using CORE. I am trying to learn it but I am not good with all of this coding type things and so I am finding some aspects to be confusing or difficult to use. I did create my first piston, however, and it is working well with one exception.
The piston is supposed to unlock a door when my location becomes present. This part is working well. However, at the end of the piston i asked it to “send notification” that the door is unlocked, and this is not happening. What do I need it to say at the end of the code to get it to send me a notification every time this happens?
Your trigger, rises above, depends on knowing the before and after values. Your piston has to know that it’s currently below 44%, then it has to receive a temperature event, then compare the previous value and current value against your target. So let’s assume you’re sitting at 44%, then your sensor registers a 45% event. The piston would receive that event, then say I’m currently below 44%, and the new value is 45%. With the new value, I’m now above the 44% trigger, so the “change” evaluation is true, and now I’m going to execute the actions. Now let’s say another event comes through, humidity is 46%. The piston gets executed again since it’s subscribed to your humidity sensor, it says I was previously above the 44% target, and I’m now still above the 44% target. The “change” evaluation is false, so I’m not going to execute any actions.
Now let’s look at the “is greater than or equal to” condition. Same series of events takes place. Your piston receives a 44% humidity event, says I’m not greater than or equal to 45%, so I’m not going to execute actions. Next, a 45% event comes through. The piston looks and says 45% is greater than or equal to my target of 45%, so I’m going to execute the actions and turn on the dehumidifier. Now a 46% event comes through. The piston evaluates and says 46% is greater than or equal to 45%, so I’m going to execute the actions and turn on the dehumidifier. Now a 47% event comes through. The piston evaluates and says 47% is greater than or equal to 45%, so I’m going to execute the actions and turn on the dehumidifier. Now a 48% event comes through…you get the idea. The piston will send the “on” command to your humidifier every time it receives a new humidity level from the sensor, as long as that level is >= 45%. This way there’s lower overhead during the evaluation stage, but there’s more network traffic with multiple commands being sent to the device, and if you were to manually switch the dehumidifier off, it will come back on the next time your humidity sensor sends an update.
So each of these two scenarios is different. The net result to you may be the same depending on your use case, and based on what you are saying, you may actually want it to send multiple on commands. Other people may not. Either way, it’s important to know the difference so you can decide which way works better for you.
Thanks Chris. So in this case using IS GT OR EQUAL TO generates more network traffic, but is “safer” in that in the event the dehumidifier is manually turned off (or somehow missed the command to turn on the first time it was sent, as an example) when it should be on, the “condition” will cause it to re-evaluate and turn back on.
OK so here’s another scenario. I have a water sensor (which includes a temp sensor) under the kick plate on the floor under my dishwasher. But as a side effect I noticed that when the dishwasher runs the temperature rises from the mid 70s to about 82 degrees. Then when it finishes, the temperature falls back to the mid 70s.
I’d like to use that pattern to track when the dishwasher has been run and has finished. The rule for this would be that the temperature would be 78 degrees and below, and then rise to above 80 degrees, and then the dishwasher cycle would be deemed to be completed once the temp fell back below 78.
So let me think about this… I wouldn’t want a “condition” that says if temp is <=78 because that doesn’t capture the most important part - which is that the temperature was above 80 and now is below 78… So perhaps this is easier than I think, and I can just say: if temp drops below 80? Would that do the trick? As I understand it, that would one trigger ONCE, when it falls below 80, even as it keeps falling. And would not trigger again, until it go up to at least 80 at some future point and then fell back below it again. Do I have this right? Or perhaps there’s another way that’s better?
It is all about data size. An event log can easily reach upwords of a few MB, where do you store them? Having them in js RAM would eventually make it slow and it would not persist between refreshes. Having them stored on a server (say webcore.co) may incur extra costs (google charges for network ingress/egress and storage). Any ideas?