@James_Watts Have you tried running all of those sunset blocks asynchronously since it started misbehaving?
[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)
Just to report that on v 0.2.0db the green snapshot doesn’t anonymize email adresses. I think it should do so. Thanks again for your excellent work!
That code is being triggered by a Routine. It should execute fine.
Andrew, I can try that. I’ll have to wait til tonight to see of course. But I thought async only applied to DO statements… All these IF blocks run at the same time (ie: not in sequence).
Oh this is a cool idea I’m thinking of something like like this for where a speaker ask me did you remember your umbrella on rainy days when I open the door to leave in the morning. But speaking of good morning routines I’ve seen videos of people having a speaker play a weather forcast from some service. If I don’t have ask alexa or a sonos is there a way I could still get that to play on my speaker
There is some work being done on doing this with a Chromecast, but I don’t know how quick it is. It takes some doing to get going, looks like.
Alternatively, you can use Aeotec’s Doorbell as a speaker to play sounds, which is easy to set up and get going. If you don’t need to select/create your own sounds, there are some other options that have built-in sounds to choose from.
@James_Watts I agree, but I wonder if the issue isn’t the multiple fade commands conflicting. I have identified on my Hue system with the latest firmware that the issue is not necessarily the triggers (ST, Siri, etc.), but Hue’s execution of the dim/fade/transition commands when too many are issued simultaneously. Also, signal strength between the lights and the bridge is a factor.
I was wondering that myself. It seems overkill to make separate pistons out of all of these. I did change the IFs to async, and got significantly better times out of the trace. Also rearranged the blocks to be time sequential, even though that shouldn’t matter now that they’re async.
I’d love to keep it simple here, but all these bulbs/faders have different dimming curves.
edit: Consolidated it a bit.
I think you will see improved execution times. If it’s still being finicky, I addressed a similar problem by adding Waits to the commands issued to individual lights. Not ideal, but it’s mostly transparent since they all have different fade curves.
This simple piston is driving me crazy. I have much more complex ones that work fine and I wrote them half asleep. I “solved” my frustration with the newlines in the SMS notifications by having a separate message issued for each device. That’s less irritating to me than having the devices all wrapping around in the message.
The issue is the console logging isn’t working. It seems to be related to the fact that the devices don’t change their status anywhere near the frequency I’m running the piston for test, but it doesn’t matter whether I trigger the piston with a button or if I let it auto-cycle every minute or every five minutes or once a day. The log command only seems to run when I have changed the contents of the variable. And that is not how that code should work. Additionally, clearing the variable with Set variable VARIABLE = “” should clear the contents of the variable, but it does not. Anyone know why and if there’s a better way to reinitialize a variable when the piston runs, because the piston does not clear the variable even if I leave out the line that tells it to.
I don’t see a routine in @Jwwhite post #3466. I’m kinda noob tho. Where would it be?
PS: This is what happened last night right as the sunrise fade stalled out:
7/22/2017, 5:34:17 AM +342ms
+1ms ╔Received event [We’re Home].time = 1500716027867 with a delay of 29473ms
+4930ms ║RunTime Analysis CS > 35ms > PS > 4735ms > PE > 161ms > CE
+5029ms ║Piston waited at a semaphore for 4590ms
+5032ms ║Runtime (45126 bytes) successfully initialized in 4735ms (v0.2.0db.20170717) (5029ms)
+5034ms ║╔Execution stage started
+5035ms ║╚Execution stage complete. (2ms)
+5087ms ║Setting up scheduled job for Sat, Jul 22 2017 @ 5:33:47 AM EDT (in 1s), with 75 more jobs pending
+5105ms ╚Event processed successfully (5106ms)
A couple seconds later it just restarted the piston, leaving two bulbs still halfway on. I’m not sure if it’s diagnosable… “Waited at a semaphore”…
Hmm, ok. I’m a bit confused. I’m testing it out but not sure I get it.
So if I get home, and the wife is not home. Would I get an alert?
I used argument ([Wife Presence Sensor : Presence]) greater than 60000.
My next question, is presence based on milliseconds?
So I’d want this to work if Car became not present and wife also recently became not present, but I’m still present. Cause I’m not present as well then I don’t need to remember to lock the door, haha.
I guess I’m also confused how to do that. When I checked wifepresnese:presence, the value was “not present”, it was not a number
I used @bangali’s code above to set the color on Tiles according to a range (thanks, btw). I have it working great on the Tiles and now I’m trying to do the same in the Piston State but that’s not working. The atticTemp variable color is not evaluating to orange. Any ideas?
Move logging right after end if of for each, something like this…
Good. Grief. Thanks. That’s what I get for trying to troubleshoot on 4 hours of sleep after being awake almost 24. I’m getting too old for that. I appreciate the help.
I took out the sms in the test as I had a lot of devices under 70 lol, got spammed.
Ouch. Sorry. Now that it messages AND logs like it should, I’m lowering the threshold considerably. But I knew 70 would trigger two or three devices. I should have added a note in my request to let folks know they might want to look at that.
Try enclosing the variable in integer().