Below are a couple of piston variants for monitoring and displaying garage door state.
This is interesting because it uses
-
multiple devices and system variable $currentEventDevice to determine which device is changing
- $currentEventDevice is a built-in variable set to the device of the event that launched this piston execution.
-
it uses another system variable $currentEventAttribute to understand if the piston is running due to a device event vs. a test event vs. a tile click event
- $currentEventAttribute is a built-in variable set to the attribute of the waking event for this execution.
- $currentEventValue system variable is the value of the attribute that woke-up this piston execution.
-
it uses array [] variables to track the state of different devices and tiles.
- note array variables are addressed 0-n. (ie the first element is 0).
This shows tile displays in the webCoRE IDE like:
This first example is from the webCoRE community forum (there are many other examples using tiles)
Here is piston #1
Few things to notice:
-
This piston is complicated in that it has:
-
one on events block and one every block
-
as you recall from earlier tips, when the event/timer fires, these block statements run (but not the entire piston)
-
these blocks share a variable tile, but this sharing is un-necessary to the core logic
-
-
-
the piston subscribes to tile events
-
a tile event is created if the user clicks on a tile in the webCoRE IDE.
- In this case the tile is used as a 'button' to toggle the garage door open/close.
-
webCoRE IDE supports up to 16 tiles per piston (numbered 1-16)
-
So how do tiles work in the webCoRE dashboard/IDE:
- in the webCoRE IDE, you need [one time] to create a Piston Category that allows tiles.
- this is done in the IDE main page
- select Settings
- select CATEGORIES
- ensure there is a category created that has selected some form of tiles as the type: (This uses Details/Large Tiles )
- this is done in the IDE main page
- then in the piston, ensure the piston that is using tiles has its category set to a tiles enabled category:
So here are some adjustments to this piston and discussion as to why:
So what has changed:
-
the piston runs much less
-
there is no every 10 minutes block
-
the main piston code handles events from the doors opening and closing (rather than the on events block)
-
-
the piston deals with things may have changed during down time so it uses systemStart events to update status (rather than the polling the on events block was doing)
-
The piston notices test events (caused if in the IDE you it the test button) to initialize state
- this is helpful that if you edit the devices in use, you can get the display to update to current status rather than having to wait for the doors to have their state change.
So in both pistons, what is going on:
- When deploying you need to edit the variables:
-
Doors to list the devices the piston is monitoring - these are the door opener devices
-
DoorNames to have text you want to use in the piston tile displays
-
If you hit the test button, the webCoRE dashboard/IDE display will update to something like:
If a door cycles, the piston display will update. How to cycle:
-
the doors can be cycled by physically pushing the door controls or
-
virtually selecting the HE device and hit open/close
-
or by clicking the piston tiles, which will toggle the device
- note toggle is a webCoRE command, as door devices do not have a toggle() command, but webCoRE understands for several types of devices how to toggle them. (on/off, or open/close, mute/unmute, lock/unlock, siren/off).