Help simplifing a long yet repetitious piston - Part 2!


#1

1) Give a description of the problem
I use one piston per room for CH controls. Managed to previously reduce this massively (Help simplifing a long yet repetitious piston) through the use of variables etc to mean that I could add features and functionality to one room then duplicate the piston for other rooms with only a few minor changes (e.g. altering a few device variables in the definition section of each).

However, other pistons are called from within. At the moment, each room needs to be manually edited to point to the correct one for that room. These edits need to be made in multiple places and I’d like to again simplify down if possible.

2) What is the expected behaviour?

at the moment, here is an example of what two similar pistons look like.

image
and
image

3) What is happening/not happening?
n/a really. I’d like the ‘pause’ and ‘resume’ piston lines to be replaced with a generic line, which would result in the correct piston being executed depending on what’s been defined as per the rest, i.e.
image

Hope all that makes sense, the help from you guys a few days ago made an immense difference to my rewrites =)

4) Post a Green Snapshot of the pistonimage
(UPLOAD YOUR IMAGE HERE)

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.


#2

Why pause/resume the pistons at all? Why not define a global boolean that both pistons can look at and determine whether they are in control of the temperature? Or put all the logic of both pistons into one whose control strategy is determined by the Boolean variable? The latter would be determined by how complex your control strategy is. Just some food for thought.


#3

I am not a fan of pausing either.
To me, that is like sweeping the dirt under the rug when company comes over, LOL

… but even if you ignore that advice, under Pause piston, the only option is “Value”, so I don’t think you can use a variable there.

pic


#4

Hi guys, agree the pausing and resuming is a bit messy, as I said earlier this lot was knocked together using minimal knowledge months ago.

To avoid the pause and resume, probably best I’m clearer with what happens.

  1. If I press a “boost” button it starts a timer, which literally does nothing other than wait 30 mins and then switch off the boost button again. Whilsy it’s running I get to see a countdown timer running in webcore.

i.e.
image
and

  1. If I manually cancel the boost (or if it’s cancelled through a bit of logic which doesn’t allow a boost to start/run if the room hits a certain max level) , then the same timer above is paused.

image

Am I better off running a timer another way? I have to admit, I really didn’t like the pause/resumes - took a bit of troubleshooting sometimes but at the time couldn’t think of another way to do it.


#5

It is still hard to get the big picture through these minimal snippets you share. Is the every boost duration piston one that gets paused/unpaused? Does locationboost variable contain the ‘Boost Hallway Low’ device or is it something else? Why use ‘every’ when you could just do ‘wait 30 minutes’ and then turn off? Then it would only run once and not need to be paused.

Tell us what you are trying to accomplish overall and perhaps we can suggest simpler implementations.


#6

Not problem. I was actually doing it this way to keep it simple, but I guess if I post the whole thing properly with a bit of explanation, then it should be fine with the level of knowledge in here. Which trumps mine by a long way

Ill knock a post together in a bit. Hands tied with toddler at the minute


#7

Righto. There are 4 pistons.

  1. The simple “boiler switch” one, which is the part which decides when to switch the boiler on and off.

  1. There’s one of these for each room. Watches for various changes, max temps reached, boosts pressed etc. One of these per room to allow me to make fundamental changes, add functionality, trouble-shoot…make sure one room’s ‘stuff’ works fine, and then duplicate the piston for each room, changing a few defined devices etc.

  1. The ‘schedule’ piston. Again, one per room. For the same reasons above. This is ran peridically (once per minute at the minute for troubleshooting and experimentation).

  1. The boost timer piston, one per room.I use an ‘every’ rather than a wait so that if I press the ‘boost’ again, it will stop the first countdown and restart for another 30 mins from fresh.


#8

And after this, I’ve just realised that apparently, there’s absolutely no need to pause and restart the schedules! Gah! Because the schedules only alter the hourly setpoints with the restriction of “only if boost = off”.


#9

100% agreed…
Pausing and resuming pistons are not my favorites either…
There is almost nothing a global variable and/or a simulated switch can’t do…


#10

Right guys, after a lot of head scratching and simplification and listening to the overwhelming hatred of messy unnecessary paused pistons, I’ve completely eliminated the paused pistons AND combined into 2 pistons. So now my system currently consists of the follow:

  1. A single piston which reacts to various events and flicks the boiler switch on or off (“Boilerswitch controls”)
  2. A single piston for a room (" SCHEDULE FRONTROOM COMBINED")
  1. Boilerswitch controls (import code - 2eee)

  2. SCHEDULE FRONTROOM COMBINED (import code - 9ban)

What I don’t now have working is my 30 min boost. Before I could hit the boost button and 30 mins later it would turn off. If I switched it off 10 mins before the 30 mins was up, then switched it on again, it would be another 30 mins before it switched off.

Here’s the anonymous snippet from the code above of the boost part (which I need to figure out again now). Following the pic, there’s also a non-anonymous version if it’s easier to look at.

Am I missing something obvious I could stick into that section to flick the boost switch back off 30 mins after it switches on?

Ta!


#11

I am thinking something like:

IF {boost} switch changes to on
Then
    IF temp is less than X
    Then
        Do stuff
    ELSE
        Do other things
    END IF

    With {boost} (TCP set to Never)
        Wait 30 minutes
        Turn off
    END WITH
END IF

This method will always turn off {boost} 30 minutes after it comes on.

(The last WITH block is the only new additions)
Be careful with placement here. It must be inside the top IF, but after the internal IF.


#12

Would he need a ‘cancel pending tasks’ to deal with the off/on reset of the 30 minute timer?


#13

If he wants to be able to abort it midstream, he can add one more check in the last block:

IF {boost} switch changes to on
Then
    IF temp is less than X
    Then
        Do stuff
    ELSE
        Do other things
    END IF

    With Location (TCP set to Never)
        Wait 30 minutes
        IF Something is true     <-- New check
            Then Turn off {boost}
        END IF
    END WITH
END IF

#14

Thanks, I wasn’t entirely clear at the position to include the TCPNever instruction, but on initial testing it appears this works, although I haven’t tested under all conditions yet.

or, easier to see the relevant bit:

As for the “abort midstream”, not too sure that’s necessary to add in as when the button switches off, it aborts the boost anyway. I think !

Amazing to think that this question was only asked around a week ago and what am absolute mess everything was (paused pistons, huge individual ones etc) and now we’re down to this. Crazy. Cheers !