I have a loop from 1 to 4 to water my lawn that has 4 zones.
Each time the solenoid is turned on, it switches to water a different zone of the lawn.
So I wanted the solenoid to turn on for 8 mins of watering, Turn off, Wait 30seconds, then turn on again. Repeat This 4 times then stop.
After the wait statement the Index should still be the same and increment by one.
But instead the Index is resetting to one and watering zone 1 more than once.
Logs
Not sure what’s going on there but I tried your code and it only ‘watered’ the zone one time each.
Here’s the log…
11/23/2018, 7:55:27 AM +95ms
+116ms ║After for loop, turn off timer
11/23/2018, 7:55:13 AM +179ms
+129ms ║Turning Off
+146ms ║Zone 4 stopped watering
+155ms ║Waiting for next Zone
11/23/2018, 7:54:44 AM +98ms
+131ms ║Turning On
+149ms ║Zone 4 started watering
11/23/2018, 7:54:30 AM +175ms
+117ms ║Turning Off
+134ms ║Zone 3 stopped watering
+142ms ║Waiting for next Zone
11/23/2018, 7:54:01 AM +130ms
+203ms ║Turning On
+224ms ║Zone 3 started watering
11/23/2018, 7:53:47 AM +212ms
+136ms ║Turning Off
+153ms ║Zone 2 stopped watering
+161ms ║Waiting for next Zone
11/23/2018, 7:53:18 AM +237ms
+138ms ║Turning On
+155ms ║Zone 2 started watering
11/23/2018, 7:53:04 AM +104ms
+114ms ║Turning Off
+133ms ║Zone 1 stopped watering
+141ms ║Waiting for next Zone
11/23/2018, 7:52:35 AM +587ms
+243ms ║Turning On
+263ms ║Zone 1 started watering
I compressed the times a little…
I see an error in the IDE that says the code exceeded 20 seconds.
Wasn’t sure that you will see that if you shorten the times
I changed the watering time to 6 mins and it ran just fine…
11/23/2018, 2:09:46 PM +127ms
+105ms ║After for loop, turn off timer
11/23/2018, 2:09:32 PM +128ms
+106ms ║Turning Off
+124ms ║Zone 4 stopped watering
+133ms ║Waiting for next Zone
11/23/2018, 2:03:33 PM +250ms
+137ms ║Turning On
+154ms ║Zone 4 started watering
11/23/2018, 2:03:19 PM +189ms
+135ms ║Turning Off
+154ms ║Zone 3 stopped watering
+162ms ║Waiting for next Zone
11/23/2018, 1:57:20 PM +198ms
+142ms ║Turning On
+161ms ║Zone 3 started watering
11/23/2018, 1:57:06 PM +195ms
+121ms ║Turning Off
+138ms ║Zone 2 stopped watering
+146ms ║Waiting for next Zone
11/23/2018, 1:51:07 PM +117ms
+305ms ║Turning On
+323ms ║Zone 2 started watering
11/23/2018, 1:50:53 PM +214ms
+130ms ║Turning Off
+147ms ║Zone 1 stopped watering
+155ms ║Waiting for next Zone
11/23/2018, 1:44:54 PM +684ms
+121ms ║Turning On
+139ms ║Zone 1 started wateringI noticed you are only writing to the log.
Is is possible that equipment triggers can restart the piston?
I doubt it because this piston looks like it’s being triggered by another piston and if it did get triggered again, it will continue to cycle through the for-loop and not just double up on zone 1.
Edit: please use the reply button right under the post you’re replying to, not the blue one so that we get notified of your reply.
I ran it again tonight.
You are correct it’s is triggered by either
This run was triggered by a manual run
The loop must be running a couple instances simultaneously when triggered.
The logs files have double entries where it doesn’t even seem possible
Ran it again and showing full logs from IDE
Preformatted textd6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:45 PM: error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 204462615315118 @line -1 (error)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Cancelling statement #8’s schedules…
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Condition group #4 evaluated false (state did not change) (10ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Condition #5 evaluated false (8ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Comparison (boolean) true is (boolean) false = false (2ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: trace ║║ Executed [Irrigation 4-Zone].off (7ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Skipped execution of physical command [Irrigation 4-Zone].off([]) because it would make no change to the device. (4ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║║ Cancelling statement #25’s schedules…
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: trace ║╚ Execution stage started
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: trace ║ Runtime (41566 bytes) successfully initialized in 178ms (v0.3.108.20180906) (395ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: debug ║ RunTime Analysis CS > 170ms > PS > 178ms > PE > 45ms > CE
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:21 PM: info ╚ Received event [Home-Heritage].time = 1543026915731 with a delay of 5438ms
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: trace ║║ Executed virtual command log (2ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: info ║║ “Waiting for next Zone”
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: debug ║║ Cancelling statement #14’s schedules…
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: info ║║ Zone 1 stopped watering
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: debug ║║ Calculating (string) Zone + (string) 1 >> (string) Zone 1
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: trace ║║ Executed [Irrigation 4-Zone].off (15727ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:35:07 PM: debug ║║ Executed physical command [Irrigation 4-Zone].off() (15725ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:34:51 PM: debug ║║ Cancelling statement #12’s schedules…
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:34:51 PM: trace ║╚ Execution stage started
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:34:51 PM: debug ║ RunTime Analysis CS > 100ms > PS > 181ms > PE > 36ms > CE
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:34:51 PM: trace ║ Runtime (41566 bytes) successfully initialized in 181ms (v0.3.108.20180906) (318ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:34:51 PM: info ╚ Received event [Home-Heritage].time = 1543026892170 with a delay of -580ms
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:28:52 PM: info ╔ Event processed successfully (298ms)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:28:52 PM: info ║ Setting up scheduled job for Fri, Nov 23 2018 @ 9:34:52 PM EST (in 359.994s)
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:28:52 PM: info ║ Zone 1 started watering
d6aa85b5-9fa0-48cd-84b9-c26cb1a1b953 9:28:51 PM: info ╚ Received event [Home-Heritage].execute = :5aeb2e835039d5a4951d0dfa12ee7a96: with a delay of 60msPreformatted text
Ok I did some troubleshooting and narrowed down the problem.
If I replace the Irrigation Valve device inthe FOR loop with a dummy virtual switch it runs with no errors. (Zone 1 to Zone 4 with no restarting or repeating zones)
Put the physical device back and the errors return.
The timeout errors return once I use the Physical device.
error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 233846530563846 @line -1 (error)
The physical device is a Fortrezz MIMO 2+
I am using one relay inside to control the 24VAC sprinkler solenoid.
It seems to take too long to turn and off and the WebCore piston throws errors.
Good that you found the culprit, now how to get around that timeout issue. I do not have any experience with your device though. Have you found any reported issues on it in the ST forum?
Not found any such issues.
Any way to make WebCore send the ON command and not wait or care what happens it if gets received or not ??
Here is my temporary solution:
Use Smart Lighting local automation to have the MIMO relay mirror the virtual switch state.
Use the WebCore script to control the virtual switch.
You can try to turn off command optimization under settings. It will send the command even if the device is already on or off.
