Generic Piston for motion detectors to turn On light


#1

1) Give a description of the problem
I am new to Webcore. Just a week searching and trying to develop pistons from examples and reading comments in the community.

I develop a Piston that I can copy and use it for my multiple motion detectors. By setting the different variables, I can create a new Piston for each of my device.

However, I wish to create a unique that will run all of my motion sensor.
In order to do it, I think that I might to use Arrays. One to store my Devices, a second one to store my Lights that my Devices turn On and finally a 3rd to store the duration that the light will stay on.

I need some guidance for the following

  • how to subscribe to events for device within an array
  • I foresee a problem if many Sensor get activated when the Piston is waiting
  • Should I run asynchronous, if so how does it work
  • I will definitely have a problem if one my Device turn on multiple lights. This is problem for later.

2) What is the expected behaviour?
A Unique Piston that will trigger to every registered Motion Sensor, that will turn on lights for a set duration. The Piston should be activated immediately anytime a event Motion Sensor is created, not depending on the termination of the previous events.

3) What is happening/not happening?
Nothing, I don’t know where and how to start.

4) Post a Green Snapshot of the pistonimage

https://dashboard.webcore.co/piston/:9cffe3a3fe33e8b131fca871030d6a08:

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)
N/A
REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.


#2

While I understand your goals here, I would highly discourage from this sort of logic with a smart home. Motion sensors (as a single device) are already some of the “chattiest” of all devices… Having ALL of them reporting back to a master piston will be a nightmare that I would not wish upon my worst enemy… (it’s possible I could be persuaded while on the clock, but I would probably regret the grey hair later, LOL)

In my opinion, it is much more streamlined and concise when there are as few motion sensors in a piston as possible… Yes, this means more “work” on the coder, but trust me, your Smart Home will thank you for reducing the burden.


One alternative that I sometimes employ is combining both goals… Something like where multiple motion sensors going active can turn on a single Simulated Switch. But this is with the motion sensors in their own pistons. It let’s you “group” by the shared SimSwitch, but it also keeps the chatter to a minimum, and the code execution time real fast.

For example:

Piston #1

IF Sensor 1's motion changes to active
   Then Turn on SimSwitchGroup
END IF

Piston #2

IF Sensor 2's motion changes to active
   Then Turn on SimSwitchGroup   (same switch as piston1)
END IF

Piston #3

IF SimSwitchGroup changes to on
   Then Do cool stuff
END IF

It helps to structure first on paper, and name them properly so they stay grouped together, but it makes a world of difference. Each motion sensor will still be “chatty”, but at no time will any piston be running more than once… and they all get funneled into the master SimSwitch… (where the real code happens) This also ensures that the real piston does not get spammed… since it only triggers when the SimSwitch first turns on.

Obviously, you also have to include code for turning off of the SimSwitch, but I think it’s worth the extra coding.

This method lets you place “border-line” devices in multiple groups. (by turning on more than one SimSwitch) This double grouping works well for “transition” areas that are actually part of multiple rooms.

This method also lets you tailor each sensor independently… which makes it much more accurate for the room. (acting differently depending on the time of day… each with it’s own “Turn Off” delays etc)


#3

I 100% agree with @WCmore
Other than that you shared a link of the piston on your dashboard… we can’t see that.
Pls share a green snapshot of the piston and upload here as an image…