ZIPP-M
| Warning | ZIPP-M is currently in the design and experimental-development stage. Hardware, firmware, communications protocols, sensor interfaces, configuration procedures, and specifications described on this page may change as development and testing continue. |
ZIPP-M Motion Controller
ZIPP-M (pronounced "zip 'em") is the motion-sensing and interactive-control branch of the ZIPP project family.
ZIPP-M is intended to provide inexpensive distributed motion detection for Christmas, Halloween, and other interactive displays.
The basic concept is to place small motion-sensing nodes wherever detection is useful and communicate motion events through the ZIPP system rather than requiring each sensor to be directly wired to the prop or device it controls.
The initial development concept uses inexpensive HC-SR501 PIR motion sensors with ESP8266 or ESP32 controllers.
Project Status: Design / experimental development.
Why ZIPP-M?
Many Halloween and Christmas props include their own motion sensors.
This works well when the sensor and the controlled prop are located together, but it also ties the location of the sensor to the location of the prop.
ZIPP-M separates those two functions.
A motion sensor can be placed where it is most useful for detecting a person, while the device responding to that motion can be located somewhere else.
For example:
Person enters driveway
|
ZIPP-M Sensor
|
ZIPP Network
|
ZIPP Master
|
+----+----+----+
| | |
Lights Sound Prop
| Movement
ZIPP-R
etc.
A single motion event could therefore trigger one device, several devices, or an entire sequence of events.
Design Goals
Initial ZIPP-M design goals include:
- Very low-cost motion-sensing nodes
- Distributed sensor placement
- Wireless communications
- Separation of sensors from controlled devices
- Multiple independently addressable detection zones
- Integration with the ZIPP master architecture
- Ability for one sensor to trigger multiple actions
- Ability for multiple sensors to participate in one effect
- Configurable timing and lockout periods
- Automatic device commissioning
- Logical device addressing
- Future automatic wireless-channel selection and roaming
The final hardware and communications architecture has not yet been established.
Initial Hardware Concept
The initial ZIPP-M experiment is based on the HC-SR501 PIR motion sensor.
The HC-SR501 is an inexpensive passive-infrared motion detector that provides a simple digital output when motion is detected.
A basic ZIPP-M node could therefore require very little hardware:
HC-SR501
|
Digital Input
|
ESP8266 / ESP32
|
ESP-NOW
|
ZIPP Master
Because the sensor output is already digital, relatively little processing is required at the remote node.
This makes motion sensing a good candidate for the same inexpensive distributed architecture being developed for ZIPP-R.
Distributed Motion Detection
The important distinction in ZIPP-M is that a sensor does not necessarily control anything directly.
Instead, the sensor reports an event.
For example:
ZIPP-M #1 = Driveway entrance ZIPP-M #2 = Front walkway ZIPP-M #3 = Porch ZIPP-M #4 = Side yard
The master can determine what should happen when motion is reported in each zone.
This separates:
Detection
from:
Action
That separation allows the behavior of the display to be changed in software without physically rewiring sensors to different props.
Example Halloween Application
A person approaching a Halloween display could produce a sequence such as:
Motion detected at driveway
|
+--> Turn on remote Halloween props
|
+--> Enable additional motion sensors
|
+--> Start background audio
|
+--> Prepare animated props
As the person continues:
Walkway sensor triggered
|
+--> Trigger lighting effect
|
+--> Activate sound effect
|
+--> Operate ZIPP-R relay
|
+--> Trigger animated prop
A later sensor could trigger another effect as the visitor moves through the display.
This allows motion sensors to become inputs to the overall display rather than isolated switches attached to individual props.
Power Management
ZIPP-M may also be useful for power management.
Some motion-activated props and sound devices do not need to remain powered continuously.
A ZIPP-M sensor positioned farther from the prop could detect an approaching visitor before the visitor reaches the prop.
The ZIPP system could then use a ZIPP-R controller or other switching device to power the prop in advance.
For example:
Visitor detected
|
ZIPP-M
|
ZIPP Master
|
ZIPP-R
|
Power ON prop
|
Prop becomes ready
|
Visitor reaches prop
After a suitable period without activity, the system could turn the prop off again.
This could be particularly useful for inexpensive Halloween devices that were originally designed to operate continuously or use only a very short-range built-in sensor.
Motion Zones
Rather than treating every sensor as an unrelated device, ZIPP-M could allow sensors to represent physical zones.
For example:
Zone 1 - Street / driveway entrance Zone 2 - Lower driveway Zone 3 - Upper driveway Zone 4 - Walkway Zone 5 - Porch
The master could then use the sequence and timing of sensor activations to make better decisions about what is occurring in the display area.
For example, activation progressing from:
Zone 1 -> Zone 2 -> Zone 3
could indicate someone approaching the display.
The reverse sequence could indicate someone leaving.
Directional or multi-zone motion interpretation has not yet been implemented or tested.
Multiple Actions from One Sensor
Because ZIPP-M reports motion through the network, one sensor is not limited to controlling one output.
A single event could potentially:
- Turn on one or more ZIPP-R outputs
- Trigger a lighting effect
- Start a sound effect
- Activate an animated prop
- Enable another sensor
- Start a timer
- Notify the show-control system
The actual response can be determined by configuration rather than by how the sensor is physically wired.
Multiple Sensors for One Action
The reverse is also possible.
Several ZIPP-M sensors could control the same action.
For example, motion detected at either side of a display could trigger the same prop.
Multiple sensors could also be combined logically.
Possible future rules could include:
Sensor A OR Sensor B
Sensor A AND Sensor B
Sensor A followed by Sensor B
Sensor A, but only if Sensor B has not recently triggered
These behaviors would primarily be handled by the master rather than requiring complex firmware in every sensor.
Keeping the Remote Node Simple
Like ZIPP-R, ZIPP-M is intended to place most system intelligence in the ZIPP master.
The remote sensor should ideally perform only the tasks necessary to:
- Monitor its sensor
- Detect a state change
- Identify itself
- Report the event
- Receive configuration information
- Monitor communications with the master
More complicated decisions can be made centrally.
This keeps the remote hardware inexpensive and allows system behavior to be changed without reflashing every sensor.
ESP-NOW Communications
Motion events require very little communications bandwidth.
A sensor may remain idle for long periods and transmit only when motion occurs or when periodic status information is required.
ESP-NOW is therefore being considered for communications between ZIPP-M sensors and the ZIPP master.
Conceptually:
ZIPP-M Sensor
|
ESP-NOW
|
ESP32 ZIPP Master
|
Display Control
The exact ZIPP-M packet format has not yet been defined.
Logical Addressing
ZIPP-M is expected to use the same general logical-addressing concept being developed for ZIPP-R.
For example:
ZIPP-M #1 ZIPP-M #2 ZIPP-M #3
The user should not need to manually maintain MAC-address lists.
During commissioning, the master could identify a new device using its factory MAC address and assign a persistent logical ZIPP-M number.
The controller could then be given a descriptive name through a future configuration interface.
For example:
ZIPP-M #1 = Driveway ZIPP-M #2 = Walkway ZIPP-M #3 = Porch
Automatic commissioning has not yet been implemented.
Timing and Retriggering
PIR sensors can remain active for a period after detecting movement and may repeatedly detect the same person.
ZIPP-M therefore needs to distinguish between a raw sensor signal and a useful display event.
Possible configurable parameters may include:
- Trigger delay
- Retrigger interval
- Minimum active time
- Lockout period
- Event timeout
- Sensor enable/disable state
Some filtering may occur at the sensor node, while more complicated event processing can occur at the master.
The final division of these functions has not yet been determined.
Sensor Enable and Disable
Because ZIPP-M sensors are networked, the master could potentially enable or disable individual sensors as part of an interactive sequence.
For example:
Driveway sensor detects visitor
|
Enable walkway sensor
|
Walkway sensor detects visitor
|
Enable porch sensor
This could prevent unrelated motion from triggering effects before a visitor reaches the intended part of the display.
It could also allow the same physical sensors to behave differently during different portions of a show.
Remote sensor enable/disable control has not yet been implemented.
Relationship to DDP
Unlike pixels or dimmer channels, motion is primarily an input to the display rather than an output.
This makes ZIPP-M somewhat different from the other ZIPP projects.
The master may receive DDP output data from sequencing software while simultaneously receiving motion events from ZIPP-M sensors.
Conceptually:
ZIPP-M Sensors
|
ESP-NOW
|
xLights ----DDP----> ZIPP Master
|
Outputs
How motion events interact with sequencing software, a show player, or locally generated effects will be investigated during future development.
Stand-Alone Operation
Some ZIPP-M applications may not require a sequencing computer at all.
A ZIPP master could potentially respond to motion events using locally configured rules.
For example:
Motion detected
|
Turn ZIPP-R #4 ON
|
Wait 30 seconds
|
Turn ZIPP-R #4 OFF
This could make the ZIPP architecture useful for stand-alone Halloween props, security-style lighting, interactive displays, and other applications outside a conventional sequenced Christmas show.
Stand-alone automation rules have not yet been implemented.
Combined ZIPP-M / ZIPP-R Devices
Some applications may benefit from combining sensing and switching in the same physical controller.
For example, a controller could contain:
ESP8266 | +--> PIR Input | +--> Relay Output
Such a device could function as both a ZIPP-M sensor and a ZIPP-R output.
However, keeping sensing and switching logically separate allows the same motion event to control devices located elsewhere.
Combined hardware is therefore a possible future option rather than a requirement of the ZIPP-M architecture.
Heartbeat and Device Status
The master may periodically communicate with ZIPP-M sensors to determine whether they remain operational.
This could allow the system to detect:
- Missing sensors
- Communication failures
- Sensor restarts
- Low or interrupted power
- Channel changes
- Configuration problems
Because a motion sensor may legitimately remain silent for a long time, periodic heartbeat or status messages may be particularly useful for distinguishing an inactive sensor from a failed sensor.
Heartbeat and status reporting have not yet been implemented.
Wireless Channel Selection and Roaming
ZIPP-M is expected to eventually share the automatic channel-selection and roaming architecture being developed for other low-bandwidth ZIPP devices.
A sensor could:
- Start on its last known operating channel
- Listen for the ZIPP master
- Search permitted channels if the master is not found
- Detect loss of master communications
- Rediscover the master automatically
- Follow coordinated channel changes
- Store the new channel for future startup
Development and testing of this capability is expected to begin with ZIPP-R before being incorporated into other ZIPP devices.
Automatic channel selection and roaming have not yet been implemented.
Other Sensors
Although the HC-SR501 PIR is the initial development sensor, the ZIPP-M architecture does not necessarily depend on PIR technology.
Future sensor nodes could potentially use:
- Microwave motion sensors
- Beam-break sensors
- Pressure or floor sensors
- Magnetic switches
- Push buttons
- Proximity sensors
- Other digital or analog detection devices
The important ZIPP-M concept is the networked event, rather than the particular technology used to detect it.
Other sensor types should be considered possible future development rather than currently supported hardware.
Firmware
No production ZIPP-M firmware currently exists.
Future firmware is expected to include functions such as:
- Sensor monitoring
- Motion-event detection
- ESP-NOW communications
- Logical device addressing
- Automatic commissioning
- Event filtering
- Retrigger control
- Remote enable/disable
- Heartbeat and status reporting
- Automatic channel discovery and roaming
- Diagnostics
Some communications functions may be derived from ZIPP-R firmware after that architecture has been more thoroughly developed and tested.
Future Development
Major areas of future ZIPP-M development include:
- HC-SR501 prototype testing
- ESP8266 sensor firmware
- Motion-event packet definition
- Logical addressing
- Automatic commissioning
- Multiple sensor zones
- Trigger and retrigger filtering
- Remote sensor enable/disable
- Master event processing
- ZIPP-R integration
- Lighting and audio triggering
- Stand-alone automation rules
- Heartbeat and device monitoring
- Wireless channel roaming
- Additional sensor types
- Outdoor enclosure development
- Large sensor-count testing
Project Author
ZIPP-M is a DIY Christmas member project developed by Ernest Horning as part of the ZIPP project family.
The project is being documented during development so that design concepts, experiments, test results, and design decisions can be preserved as the system evolves.