Do I need to set "subscription method" for this piston to work properly?

#1

1) Give a description of the problem
I borrowed and tweaked this location mode piston from “House Scheduler” on Advanced Pistons Example page. When comparing my piston to the example I see that OA is setting the “subscription method” on each of the “prescence ifs”. What is the purpose of this and should I be using that in my modified version?

2) What is the expected behavior?
Works as written, but I’m not sure if it’s running optimally

3) What is happening/not happening?
Occasional “piston waited at a semaphore for xxx ms”

4) Post a Green Snapshot of the pistonimage

daily_mode_routine
daily_mode_routine.png1178×1553 190 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
(PASTE YOUR LOGS HERE BETWEEN THE MARKS)

#2

The reason I changed the subscription methods on that piston is because I didn’t want the piston to fire on changes from our presence. I only want the time to trigger the piston and have the presence as conditions of the time.

#3

So, if I understand correctly, the way I have it set up, the “any” presence detection fires every time of the devices enters “location”, as opposed to only the first time “any” of them do? It sounds like I would benefit from this setting also, with the exception of the “all presence away”?

#4

You have a lot going on. Which line numbers are you referring too?

#5

24 and 35 are a couple of the “any presence” examples, 69 is the “all presence” example

#6

Ok so anywhere that you have a subscription (lightning bolt in the gutter) then this piston will run based on events for those subscriptions.

So if you are subscribing to a presence sensors presence. Then an event of present/not present will cause the piston to be evaluated. Even if you are only looking for one side like ‘present’ a ‘not present’ event will check your entire piston.

Are things running how you would like them too?

#7

Every thing seems to be working, just trying to code it as efficiently as possible. The only indication of an “issue” is the “piston waited at a semaphore for xxx ms” that keeps appearing in log throughout the day.

With the exception of that “logging entry” all seems to be good. I do believe I am able to “wrap my head around” the function of the “subscription method” now.

#8

The semaphore waits are a feature and not a bug. Basically 2 events tried to come in at the same time. So the piston ran through the first one before running the second.

#9

Great, then that solves my questions, thanks!

#10

modechange
modechange.png1178×1609 204 KB

latest revision, still a work in progress. all sections seem to working well, except the lines 40 to 55 “transition from awake to day”. I thought it may because it was was solely condition based, but section 58 to 71 is also condition based and appears to work as expected. I experimented with adding a movement based trigger but should that be necessary?

Thanks!

#11

Does this piston only set the location mode?

#12

Location mode, and piston state, with some notificaitons

#13

You should be checking the time mainly and then your presence/motion should just be conditions instead of triggers.

#14

so I really shouldn’t need the motion triggers? I didn’t think so based on the example in wiki, but the “day” portion of the routine isn’t triggering without the motion trigger.

#15

If you are basing it off the one on the wiki then you are going to want to base everything off of the time. All the presence statements are conditions.

#16

Excellent, thank you. Two Final Questions for this topic:

  1. Using the time based condition and limiting presence to a condition, should the mode change from “away*” to “home - *” when a presence sensor arrives?

  2. Being as I live in Alaska and sunrise and sunset vary DRAMATICALLY throughout the year, I was hoping to use a setting like “time is between 6:00am and 90 minutes past sunrise” in my “home-dawn” section, however, during the summer months sunrise would be well before 6:00am so I am assuming that would cause undesired results? Would it be better to use a different condition?

#17

Ok

  1. my house scheduler piston handles the location mode and SHM triggered by time. In that there are conditions for presence. Basically when the time changes to one of my ranges it then checks if anyone is home. Then sets things accordingly.

Separately I have a piston “magic home” that handles doors, lights, mode and SHM. This is triggered off presence and has condition ranges for time to determine what mode it should be in.

  1. it will be some interesting logic because of your wild sunrise/sunset times. It would be hard for me to know where to begin since I do not experience just drastic changes.
#18

I’m considering setting up two different home-dawn sections with only run restrictions based on time of year? So that during the summer months it will use solely time to define Dawn and in winter use time/sunrise?

#19

That’s definitely an option. You should be able to cram that into a single piston. Just have the months as a restriction