Repeat Loop Counter Not Incrementing

[lflorack]

1) Give a description of the problem
I’m implementing a more robust Thermostat SetPoint piston that retries setting the Heat and Cool SetPoints five times or until the SetPoint temperatures match with what’s expected. It then notifies me if it takes more iterations thatn one OR it notifies me that it failed after 5 tries.

The piston below is a test version of that new piston - intentionally written (see line ##41) to fail and therefore trip the loop counter. The loop counter is either not incrementing or it’s being reset to zero when the piston restarts.

2) What is the expected behavior?
Overall, the loop counter should increment and do appropriate things. More specifically, I didn’t expect that the piston would actually restart - and thereby resetting the loop counter. I thought the loop would run again and again until the conditions are met one way or another - OR I expected the loop counter to increment.

3) What is happening/not happening?
As written for this test, the piston should fail because line# 41 will never be true. The piston should loop 5 times, stop and then notify me that it failed.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)

Thanks in advance.

[Mike1616]

Yeah, you’re setting it to 0 yourself at the top of the piston. It won’t count up properly if you do that. As you correctly determined, it will reset itself back to 0.

It’s important to know that a declared integer will automatically have a value of 0 when you first define it.

So you can skip that step. But, you will have to reset it back to zero when your counter gets up to your desired value. So in your very last IF statement, set it back to zero.

[lflorack]

Yeah, you’re setting it to 0 yourself at the top of the piston. It won’t count up properly if you do that. As you correctly determined, it will reset itself back to 0.

It’s important to know that a declared integer will automatically have a value of 0 when you first define it.

So you can skip that step. But, you will have to reset it back to zero when your counter gets up to your desired value. So in your very last IF statement, set it back to zero.

Thanks for the reply. Your response makes perfect sense. However, I thought that the loop would just run within itself and wouldn’t restart the whole piston over again. I guess that’s not the case. I’ll have to remove the opening zero setting (leave it blank) and reset the variable back to zero somehow when the piston actually finishes looping. Have to look at my piston again to see where to put that logic since (I think) it has several exit points.

[michicago]

A couple additions to what @Mike1616 said:

1. You are correct that loops typically run locally and, even if you reset your variable to 0 at the top of a piston, they will increment.

2. The reason yours doesn’t is because you have WAIT statement(s) in them. What a WAIT statement does is force the piston to set a wake-up command for itself for the wait duration. After the time passed, the piston executes again from the top, verifying conditions. Since your “time occurs daily” no longer evaluates true, is cancels your loop and forgets the rest.

3. You could try clicking your WITH statement, then the gear cog at the bottom, and setting your task cancellation policy to NEVER CANCEL TASKS to get around the issue with #2 above.

I have pistons that set variables to 0 at the top, but count just fine. They just go back to 0 when the piston starts, which is exactly what I want them to do.

[lflorack]

A couple additions to what @Mike1616 said:

You are correct that loops typically run locally and, even if you reset your variable to 0 at the top of a piston, they will increment.

The reason yours doesn’t is because you have WAIT statement(s) in them. What a WAIT statement does is force the piston to set a wake-up command for itself for the wait duration. After the time passed, the piston executes again from the top, verifying conditions. Since your “time occurs daily” no longer evaluates true, is cancels your loop and forgets the rest.

You could try clicking your WITH statement, then the gear cog at the bottom, and setting your task cancellation policy to NEVER CANCEL TASKS to get around the issue with #2 above.

I have pistons that set variables to 0 at the top, but count just fine. They just go back to 0 when the piston starts, which is exactly what I want them to do.

I’ve experimented a little with changing TCP to NEVER CANCEL but it was unsuccessful. I first did it just with the WITH’s and when that didn’t work, I also tried the REPEAT’s too. That didn’t work either. I’ll play with it some more tomorrow to see if I can get it to work with the counter set to ‘0’ as it is now. But failing that, I may work on resetting the counter to ‘0’ at each of the piston’s exit points.

Thanks for looking at it.

[michicago]

Can you post a log with TCP set to never? Curious if we can see why it’s falling out of the loop then.

[lflorack]

Can you post a log with TCP set to never? Curious if we can see why it’s falling out of the loop then.

OK. Here’s the current test version of the piston that’s set to fail at the line with the arrow

And here’s a snapshot of one of the loops. It was either the 2nd loop or the third. The line with the arrow shows that the counter is still going from 0 to 1:

It’s very likely that the counter is being reset to zero at the beginning of each loop run, but I don’t know why the piston is starting over. I thought that the repeat should just make it run within the loop again - until it meets the success conditions or the counter limit. It is not doing that.

Thanks again for looking at this with me.

[lflorack]

For comparison, this is the first pass:

At the 126ms line, is it troublesome that the group referenced is #null?

[michicago]

Is that log snippet from 9:14:21 the FIRST time the piston ran, or was that after a wake-up command after one of the 10 second waits?

Here’s a brief explanation of how WAITS in webCoRE work, and why they don’t always produce the results we’re expecting.

Drops Below not working as expected

Waits combined with triggers can get tricky. The way your piston is written, this is what happens: Your consumption drops below 10W and your switch is on, so your condition evaluates true. Your piston has a wait for 10 seconds, so it sets a wake-up time for itself 10 seconds in the future. After 10 seconds pass, your piston wakes up and executes from the top. Since your consumption has been below 10W for some time, the “drops below” no longer evaluates true and your piston skips completing th…

[lflorack]

Is that log snippet from 9:14:21 the FIRST time the piston ran, or was that after a wake-up command after one of the 10 second waits?

It was a 2nd or third loop - not the first pass. I later posted a first pass snippet of the log.

Here’s a brief explanation of how WAITS in webCoRE work, and why they don’t always produce the results we’re expecting.

OK. I skimmed it and it’s likely the cause of my issues. I’ll take a deeper look at this and see if I can modify my piston accordingly. Thanks for posting this.

[Mike1616]

I can confirm that the Wait is the issue. Here’s an example loop. If you take out the Wait you can set the counter to zero at the top and all is fine. However, with the Wait in there and the counter set to a value it will never complete the loop. it will just stay at 1 forever.

My suggestion would be to do like I’m showing below. Just pick a time a few minutes in the future and reset the variable back to zero.

[michicago]

I always like a good litmus test when something doesn’t make sense. Nice work!

[lflorack]

@Mike1616 @michicago

Thanks to both of you for looking at this with me and deciphering why (combining WAITs and TRIGGERS within the repeat) it wasn’t firing. Once you were able to point out and prove why it wasn’t working, I decided to just handle all the counter incrementing and add resets at each of the piston’s exit points and not set the counter to zero at the top.

BTW, missing the setting of setpoints in my thermostat has only happened twice in about a year and a half so this isn’t going to be fully exercised very often but this updated version will handle it when it does. So, thanks again for all your help. Anyway, I ended up with this (Updated 6 Feb @13:49 with latest version):

[lflorack]

Hi Mike,

I do have an additional question (always!)

I see ‘log debug’ in your test piston. I’ve added that command (specifically the counter number as part of the piston closeout and reset) into my new piston (it’s updated in my previous post) and see what it adds into my logs. Very handy! While I was adding that, I saw that in addition to ‘debug’ there are other choices like ‘warn’, ‘error’, etc. What are they used for and how do they work? If it’s posted somewhere, I can go look there if you can point me to it.

Lee

[Mike1616]

I saw that in addition to ‘debug’ there are other choices like ‘warn’, ‘error’, etc. What are they used for and how do they work?

Yes, piston logging is awesome. I use it quite extensively when creating something new…or just to confirm that something is working. Many times you don’t need the full logs, you just need know some specific piece of information and they work great for that. As for the various options…really they are just different colors. They don’t write to different logs…the messages all go to the same place, they just change color slightly. I use debug as I find that one to be the easiest for me to read. But some are blue in color others are red. Play around and see which one you like.

[lflorack]

Thanks! I did a quick piston to print out what each of the options available for logging look like (in case anyone is wondering):