1) Give a description of the problem
My main area heats up at a rate of about 6 degrees an hour. I can’t figure out how to get the heater to kick in X minutes before 4pm based on the temperature at that time.
2) What is the expected behavior?
I browbeat my kid into coming up with a code for me. I think she’s got it right: If Temperature [of thermostat] <21 [degrees], then set HeatingSetPoint to 21 10(21- Temperature) minutes before 4pm.
3) What is happening/not happening?
I’m too dumb to figure out if I’m dealing with an argument, expression or variable in Webcore in trying to run the formula.
I find this stuff tough to understand. I vow to spend some more time reading about the basics of Webcore (or better yet, tracaking down a video). I’ve tried, but it’s tough for me to absorb, although I realize I don’t even understand Webcore 101.
Two pistons has got to be correct, though, because the first piston needs to figure out what the temperature difference is earlier enough before 4pm (in my case) to do something about it. I’m thinking it won’t take more than 2 hours to heat up, because I set the “off” temperature at 10 Celsius. So I guess the first piston needs to execute at, say, 2pm to figure out what 10 x (21 - Temp) is? That would give me how many minutes before 4pm the second piston needs to execute. In other words, if the Temp is 11 degrees, then 21 - 11 = 10, so I need the second piston to fire 100 minutes before 4pm. Do I do that with a variable or an expression?
The next piston would, as you say, then simply have to execute [Variable?] minutes before 4pm to set the Heatingsetpoint to 21 if Temp < 21. But I can’t figure out how to do that. How would I input that “code” into Webcore?
This is actually one of the occasions where I would use two triggers in the same piston. (with both of them being time based)
Personally, I would use both. I would “Set variable to X”, and define X using an expression.
If you take my advice and make both triggers in the same piston, I would do it something like this:
define
decimal temp (not set)
integer offset (not set)
end define
Every day at 2pm
Set variable {temp} = YourDevice's temperature
Set variable {offset} = (21 - temp) * 10
END EVERY
Every day at {offset} minutes before 4pm
IF {temp} is < 21
Then do cool stuff
END IF
END EVERY
Quick Note:
If your device only sees whole temperatures, then the variable {temp} can be an integer.
Also, the third line (Set variable offset) is the only expression here: (21 - temp) * 10
Pro Tip:
If there is ever a 2PM where the temp is greater than 21 (let’s say 23 degrees), then that day the second trigger would fire after 4pm. (in this example, at 4:20) Of course, with the IF block in place, the “cool stuff” would not execute, since {temp} is greater than 21, but it is handy to be aware if you want different actions to take place in those cases.
If it’s not an “Expression” in the “At this time…” box, what is it? If I choose Value, I don’t get the offset box (but can put in 4:00pm), and if I choose Variable, they are all pre-determined? I tried to use a time expression, but I’m obviously missing something obvious?
For testing purposes, I changed the target time (when I get home) to 230pm, and to check for the offset at 2:29pm. I also had to monkey with the temps so I assumed I wanted it at 25 degrees by 2:30pm.
The log seems to confirm it’s working, although it’s setting the heaters to kick in at 2:04pm tomorrow, presumably because there’s no time machine built into Webcore!
Unless you see something I don’t, thanks!!!
Logs
3/2/2019, 2:28:59 PM +110ms
+1ms ╔Received event [Home].time = 1551565740000 with a delay of -891ms
+126ms ║RunTime Analysis CS > 23ms > PS > 76ms > PE > 27ms > CE
+128ms ║Runtime (38470 bytes) successfully initialized in 76ms (v0.3.10a.20190223) (126ms)
+130ms ║╔Execution stage started
+147ms ║║Cancelling statement #2’s schedules…
+161ms ║║Executed virtual command setVariable (3ms)
+169ms ║║Calculating (decimal) 22.3 - (decimal) 25.0 >> (decimal) -2.6999999999999993
+175ms ║║Calculating (decimal) -2.6999999999999993 * (decimal) 10.0 >> (decimal) -26.999999999999993
+182ms ║║Executed virtual command setVariable (3ms)
+186ms ║╚Execution stage complete. (57ms)
+189ms ║Setting up scheduled job for Sun, Mar 3 2019 @ 2:04:00 PM PST (in 84900.702s), with 1 more job pending
+201ms ╚Event processed successfully (201ms)
Well, there is one more tweak if you want reliability.
The time at line 23 must be before the very earliest possible time, or the second trigger (set heating point) will never trigger.
In other words, with your current wording, it will not know until 2:29 what {Lead_Time} is, so it is impossible for it to trigger the second block at 2:30 - {Lead_Time} since that time would have already passed. This error will repeat each and every day.
So either make a wider gap between the two times… OR
Make a new math formula on line 26 that adds an offset (positive number) to take place after 2:30.
Basically:
If {Lead_Time} is a negative number, it will trigger before {Target_Time}
If {Lead_Time} is a positive number, it will trigger after {Target_Time}
…and {Lead_Time} must be set before the second block is supposed to trigger.
To match my intellect, I went with the KISS method and put a 2 1/2 hour gap in between figuring out the Lead_Time before the Target_Time. Here’s the final code…Thanks again WCmore!
Hmmm, are you seeing something I’m not? It looks like the calculation is somehow wrong in line 28? The heaters came on at 3:34pm, or 26 minutes before 4pm (the TargetTime), but they should have come on at 2:23pm, being 97 minutes (the calculation determined in Lead_Time) before the TargetTime.
Logs
3/4/2019, 3:33:59 PM +366ms
+0ms ╔Received event [Home].time = 1551742440000 with a delay of -635ms
+256ms ║RunTime Analysis CS > 38ms > PS > 192ms > PE > 26ms > CE
+259ms ║Runtime (38500 bytes) successfully initialized in 192ms (v0.3.10a.20190223) (257ms)
+260ms ║╔Execution stage started
+308ms ║║Comparison (decimal) 11.1 is_less_than (integer) 18 = true (3ms)
+311ms ║║Cancelling condition #8’s schedules…
+312ms ║║Condition #8 evaluated true (18ms)
+314ms ║║Cancelling condition #6’s schedules…
+315ms ║║Condition group #6 evaluated true (state changed) (21ms)
+317ms ║║Cancelling statement #6’s schedules…
+709ms ║║Executed physical command [Heater - Kitchen Nook And Front Door].setHeatingSetpoint([21.0]) (386ms)
+711ms ║║Executed [Heater - Kitchen Nook And Front Door].setHeatingSetpoint (388ms)
+718ms ║╚Execution stage complete. (458ms)
+722ms ║Setting up scheduled job for Tue, Mar 5 2019 @ 1:30:00 PM PST (in 78959.914s), with 1 more job pending
+732ms ╚Event processed successfully (733ms)
3/4/2019, 1:29:59 PM +50ms
+1ms ╔Received event [Home].time = 1551735000000 with a delay of -950ms
+99ms ║RunTime Analysis CS > 17ms > PS > 49ms > PE > 32ms > CE
+103ms ║Runtime (38496 bytes) successfully initialized in 49ms (v0.3.10a.20190223) (100ms)
+105ms ║╔Execution stage started
+131ms ║║Cancelling statement #2’s schedules…
+144ms ║║Executed virtual command setVariable (4ms)
+154ms ║║Calculating (decimal) 11.3 - (decimal) 21.0 >> (decimal) -9.7
+160ms ║║Calculating (decimal) -9.7 * (decimal) 10.0 >> (decimal) -97.0 +167ms ║║Executed virtual command setVariable (4ms)
+172ms ║╚Execution stage complete. (67ms)
+174ms ║Setting up scheduled job for Mon, Mar 4 2019 @ 3:34:00 PM PST (in 7440.777s), with 1 more job pending
+183ms ╚Event processed successfully (182ms)
The code in piston “pue9” looks real good, but for some reason, the scheduled wakeup was incorrect.
I would try adding a 1 second WAIT after line 26. This small delay is just to make sure the new variable has enough time to be written before the wakeup is scheduled.
(I suspect that yesterday the variable was -26, and the new variable was in the process of being written when this schedule was set)
Here is your identical piston with the WAIT added, as well as two log to console commands that will help with any future troubleshooting.
Ahhh…there’s no way I would have figured that one out! From the log below, I’m betting you’re right. Thanks (again x 2!). Your code is uploaded to my Webcore and will check again tomorrow.
3/2/2019, 2:28:59 PM +110ms
+1ms ╔Received event [Home].time = 1551565740000 with a delay of -891ms
+126ms ║RunTime Analysis CS > 23ms > PS > 76ms > PE > 27ms > CE
+128ms ║Runtime (38470 bytes) successfully initialized in 76ms (v0.3.10a.20190223) (126ms)
+130ms ║╔Execution stage started
+147ms ║║Cancelling statement #2’s schedules…
+161ms ║║Executed virtual command setVariable (3ms)
+169ms ║║Calculating (decimal) 22.3 - (decimal) 25.0 >> (decimal) -2.6999999999999993
+175ms ║║Calculating (decimal) -2.6999999999999993 * (decimal) 10.0 >> (decimal) -26.999999999999993
+182ms ║║**Executed virtual command setVariable (**3ms)
+186ms ║╚Execution stage complete. (57ms)
+189ms ║Setting up scheduled job for Sun, Mar 3 2019 @ 2:04:00 PM PST (in 84900.702s), with 1 more job pending
+201ms ╚Event processed successfully (201ms)
I used the “zypf” piston above, and changed a few numbers for faster testing… IE: During testing, I switched to seconds for Target_Time - Lead_Time (Line 30)
Wow, this one was a doozy. (I spent way too much time on this)
It seems that once a scheduled job is pending, webCoRE does not want to change it if the offset changes.
I finally got it to work with a few changes.
Changed “Every day” to “Time happens daily at”
Added a “Cancel all pending tasks”
Also important to note, that when I first tried this, it still failed. But when I recreated the same piston from scratch it worked. (There may have been some corruption in the earlier piston)
My freetime is up for the day, but hopefully you can use this structure to make your (new) piston work!
It is currently set at {offset} seconds to make testing much quicker, but once you are happy with it, it should also work once it is changed back to minutes.
I promise I wasn’t trying to drag you down the rabbit hole!! I’ll test it out tonight and report back–although I might give it a couple of days to give you a bit of a break!
