Thanks Michael, I will try this out!
This worked for the first text that I sent but not for the subsequent texts. When I check the IFTTT recipe log it is giving me a Maker Action Error. I set it up exactly as shown and like I said it did work the first time. Any ideas why it wouldnât work after that?
Mine works consistently - what error are you getting? Check the URL, even try and open it manually in a browserâŚ
It works when I put it in a browser but it uses the same text that I first sent to test it. And it says it over and over for about 3 times. Now I just sent another text with something different in it and it did work but again it keeps repeating.
And in the IFTTT log it says Maker Action Error and then Action Error Skipped and then it fired.
My guess is that the first IF is True so it sends the notification and then the OR IF is true after 6 minutes so it then sends a notification as well. Maybe it takes over a minute to do the first part and so it makes the OR IF true also.
Could be because the lux is right around 2800 lumens and goes up and down slightly? Enable the âonly execute on piston state changeâ restriction, see if it helps
The Bloomsky lux only updates every 5 minutes, so itâs unlikely that it would fluctuate like that. Especially since both notifications come within a minute of each other. Itâs like the state change on the garage door contact sensor somehow cause the second notification. Iâve enabled the piston state change restriction for the actions. Thanks for the tip!
You can always enable the logs and see whatâs happening⌠got any logs?
I was wondering if someone could look at my piston and help me make it more efficient. What I want to do is:
At night:
Turn down down thermostat, when there is motion by the bed, when the thermostat is in heating mode.
In the morning (afternoon at my house):
Turn the Thermostat up, when there is motion by the bed, when the thermostat is in heating mode.
Right now I have it look for the temperature I donât want it to be to ensure it doesnât send commands all day.
What I would really want is to have those only send the command once per day. One in at night and one in the morning.
The quickest way I can think of doing this at the moment is setting a boolean variable, ie morningTempSet = true right after your Push task and add a Wait 12 hours (or however long you want) to set morningTempSet = false.
Add to your condition
⌠Variable {morningTempSet} is equals to false
Repeat for the the night temp and maybe name the variable eveningTempSet
Interesting.
I am trying to wrap my head around the Latching - âOnly Execute on piston state changeâ
I am using another piston which use that and it only turns on the device once a day. I am trying that with this one, with the different that I have the same switch set on the But if, and it doesnât execute.
Newbie on core stuff, so forgive me if this has been answered elsewhereâŚ
I want to know whether the SMS notifications are single-events, or persist while the conditions remain true. If they persist, at what frequency would the SMSs be sent while the condition is evaluated as true?
The piston I want to create is fairly simple:
IF (tempSensor1 > 70 AND tempSensor2 > 70), then send SMS notification to me
BTW, Iâm using this rather than a SHM custom monitor since occasionally each sensor reports bogus readings (100âs of degrees) and the workaround I have it to use two sensors and check that both are too high. Up to now, that âcheckingâ has been manually done, but I realized this should be easy to automate using a core piston. But I am now worried about getting âfloodedâ with SMS notifications should the condition ever be met. An alternate condition (e.g. both temp readings becoming > 70) might solve but is less straightforwards to setup.
It will send the SMS notification only once while the evaluation is true. It will only send it again if the condition isnât met anymore (e.g., one of the temps drops to 70 or below) AND it then goes back to being met (i.e., both above 70)
I have a question regarding queuing, scheduling and how tasks are handled in CoRE and ST. Iâve searched for days and canât find an answer so forgive me if this has been addressed elsewhere. As I understand it CoRE maintains its own scheduling and execution queues. But I assume ST must as well since device commands can come from multiple apps. I will propose a fake scenario that may make answering my question easier:
An ST Routine is configured to trigger at 11pm and turns Device off. A CoRE piston runs at 10:30pm and through its logic it cancels tasks for Device. Does this impact the 11pm Routine scheduled task? If not, is the reason that the 11pm routine isnât actually âscheduledâ until 11pm? Or does the Routine put the task on the queue after 11pm to sit until the next occurance of 11pm? Or if not, is the reason because the cancel only effects tasks queued internally to CoRE?
This is mostly a curiosity question to better understand how schedules and queues operate, knowing this will help avoid bugs when coding more complex pistons. Hope I made sense along the way!
When I schedule a poll to a device (a Lock) that âskipsâ the poll to save battery, does the poll continue repeatedly until it gets a response? I believe I am seeing this behavior in the logs, I wanted to confirm thatâs how it should be working. And if so is there a configuration in ST to limit the repeats? This poll seems to be generated by a condition IF (Device = unlocked) within a Follow-Up piston, that is called by a Basic piston using Trigger happens every hour.
Having issues with the piston for motion lighting.
Basically:
If
- motion detected from any
Then - Set level to 14
- Wait 3 minutes
- Turn off (Cancel on state change)
This is not turning on at all.
Another is
If
- presence changes to present.
Then - Turn
- Wait 10 minutes
- Turn off (Cancel on state change)
This just flashes on then off
For the first one, either:
a) select the âDisable command optimizationsâ in the Piston main page - this will force the piston to execute setLevel(14) even if level is already 14
b) add a Turn on right after the setLevel(14).
For the second one, are you sure you selected 3 minutes and not seconds? Any other app/piston controlling the same light? Check the ST app for the history of that light, any other app/piston name in there? Logs?
For information.
This is what I have which you could use for your first piston.
Hi All,
I setup a basic piston to monitor 3 motion sensors. I noticed that you canât set if ALL motion sensors are not active for 10 mins⌠you have to do them individually.
So my rule is as follows:
Motion Sensor A stays away from active for 10 minutes
AND
Motion Sensor B stays away from active for 10 minutes
AND
Motion Sensor C stays away from active for 10 minutes
AND Front door is locked
THEN
Update Switch to Off.
These conditions have been met a few times but the piston is not firing. Iâd really appreciate any idea why?
Thank you