Concept for uninterrupted automatic scaring

mishi commented

2025-01-25 13:34:40 +01:00

(Migrated from git.mattzz.de)

The scary installations in the garden operate continuously and in an orchestrated fashion without the need for manual interaction

Scary actions are performed in a synchronized choreography so that the visitors can enjoy all installations in a short time and focus on individual installations.
During the choreography, scary hosts perform their scary actions at a fixed time offset.
If a scary host is scheduled to but not able to participate, the following scary hosts execute their actions earlier (DISCUSS BECAUSE IT COULD CONTRADICT THE FOLLOWING CRITERION).
In case of unreliable network communication, scary hosts continue to participate according to their configured schedule under the assumption that the other hosts do that, too.
Scary hosts can perform their scary actions multiple times during a choreography.
The choreography can be started with an interaction in a single user interface.
The choreography can be configured to be automatically restarted in a configurable intervall after having been started.
In case a scary host needs to be rebooted or is powered down and up again, the hosts can be configured to rejoin the choreography.
Common lighting effects are synchronous.
Only selected scary hosts participate in the scary choreography.

The scary installations in the garden operate continuously and in an orchestrated fashion without the need for manual interaction - Scary actions are performed in a synchronized choreography so that the visitors can enjoy all installations in a short time and focus on individual installations. - During the choreography, scary hosts perform their scary actions at a fixed time offset. - If a scary host is scheduled to but not able to participate, the following scary hosts execute their actions earlier (DISCUSS BECAUSE IT COULD CONTRADICT THE FOLLOWING CRITERION). - In case of unreliable network communication, scary hosts continue to participate according to their configured schedule under the assumption that the other hosts do that, too. - Scary hosts can perform their scary actions multiple times during a choreography. - The choreography can be started with an interaction in a single user interface. - The choreography can be configured to be automatically restarted in a configurable intervall after having been started. - In case a scary host needs to be rebooted or is powered down and up again, the hosts can be configured to rejoin the choreography. - Common lighting effects are synchronous. - Only selected scary hosts participate in the scary choreography.

mishi commented

2025-01-25 13:52:42 +01:00

(Migrated from git.mattzz.de)

This implies:

Scary hosts can be configured to be part of a choreography or not (static)
Scary hosts know the interval of the choreography
Scary hosts know whether they should repeatedly perform the choreography or not
Scary hosts know the times within the choreography when they have to perform which scary action
The time of the scary hosts is synchronized to at least about 100ms accuracy (due to the pulsed idle lights)
Scary hosts can only participate one choreography at the time
Scary hosts are aware whether the choreography is active or not
The choreography settings can be change during operation by a user
Scary hosts remember the latest choreography settings after a reboot including if it is active *** DISCUSS: This is new because until now there is no persistence for the soft settings and this has some risks ***

To think about

There could be several indepdendent choreographies in the future
Maybe only activate the choreography for a certain date/time interval so that the hosts don't automatically start after being rebooted in the basement.

This implies: - Scary hosts can be configured to be part of a choreography or not (static) - Scary hosts know the interval of the choreography - Scary hosts know whether they should repeatedly perform the choreography or not - Scary hosts know the times within the choreography when they have to perform which scary action - The time of the scary hosts is synchronized to at least about 100ms accuracy (due to the pulsed idle lights) - Scary hosts can only participate one choreography at the time - Scary hosts are aware whether the choreography is active or not - The choreography settings can be change during operation by a user - Scary hosts remember the latest choreography settings after a reboot including if it is active *** DISCUSS: This is new because until now there is no persistence for the soft settings and this has some risks *** To think about - There could be several indepdendent choreographies in the future - Maybe only activate the choreography for a certain date/time interval so that the hosts don't automatically start after being rebooted in the basement.

mishi commented

2025-02-01 23:32:56 +01:00

(Migrated from git.mattzz.de)

Let's slice the poor elephant:

A) ms-Synced pulsing lights

Sync the RPi's time with some precise external source
Sync the red pulsating light on ms level
Test using two RPIs that trigger a diode and film with phone in hi speed mode

B) Choreography
4) Have a choreography action trigger other scary actions based on a schedule that is synced with the external clock
- Start a choreography like a scary action (web call?)
- First sync with time then start other scary actions on certain times
- Have the same routine that is downloaded to all hosts and only triggers the local ones
5) Test with two RPIs that work together in a choreography
6) Make the choreography blocking so that only one can be running

C) Continuous Choreo
7) Restart choreography automatically after a choreography_interval DB field if DB flag continuous_choreogaphy_flag says so
8) Add routine to set the choreography_interval
9) Add routine to set and reset continuous_choreography_flag

D) Restart chores after reboot
10) Persist continuous_choreography_flag
11) Initialise after reboot with persisted flag

Y) Later: Allow several choreos
10) Give the choreography a name and DB parameter for running_choreography
11) Possible choreos are in cfg

Z) Poll choreo from server
12) Poll running choreography from server

Let's slice the poor elephant: A) ms-Synced pulsing lights 1) Sync the RPi's time with some precise external source 2) Sync the red pulsating light on ms level 3) Test using two RPIs that trigger a diode and film with phone in hi speed mode B) Choreography 4) Have a choreography action trigger other scary actions based on a schedule that is synced with the external clock - Start a choreography like a scary action (web call?) - First sync with time then start other scary actions on certain times - Have the same routine that is downloaded to all hosts and only triggers the local ones 5) Test with two RPIs that work together in a choreography 6) Make the choreography blocking so that only one can be running C) Continuous Choreo 7) Restart choreography automatically after a choreography_interval DB field if DB flag continuous_choreogaphy_flag says so 8) Add routine to set the choreography_interval 9) Add routine to set and reset continuous_choreography_flag D) Restart chores after reboot 10) Persist continuous_choreography_flag 11) Initialise after reboot with persisted flag Y) Later: Allow several choreos 10) Give the choreography a name and DB parameter for running_choreography 11) Possible choreos are in cfg Z) Poll choreo from server 12) Poll running choreography from server

mishi commented

2025-02-01 23:48:01 +01:00

(Migrated from git.mattzz.de)

Why DB fields? So that they can be changed via web interface.

We need in DB:

choreo_active: String with name "choreo x"
choreo_repeat: True or False
choreo_auto: True or False to
choreo_running: True or False

All are initialised by cfg values (for now),

Later

choreo_interval: Integer number of seconds
Start times of different choreographies

Why DB fields? So that they can be changed via web interface. We need in DB: - choreo_active: String with name "choreo x" - choreo_repeat: True or False - choreo_auto: True or False to - choreo_running: True or False All are initialised by cfg values (for now), Later - choreo_interval: Integer number of seconds - Start times of different choreographies

mishi commented

2025-02-01 23:53:06 +01:00

(Migrated from git.mattzz.de)

Think about it: How to deal with scary actions of a different duration? That should not be possible --> split prisoner actions

This means every scary host needs to know how long the actions of the others take --> cfg table? First hardcoded.

Think about it: How to deal with scary actions of a different duration? That should not be possible --> split prisoner actions This means every scary host needs to know how long the actions of the others take --> cfg table? First hardcoded.

mishi commented

2025-03-10 16:30:47 +01:00

(Migrated from git.mattzz.de)

Now we have

A choreography mode that can be activated and deactivated via REST API
When active, a choreography with a given duration is automatically started every DURATION seconds starting from a full hour.

TODO:

Program a nice choreography
Running the choreography only once --> Is this useful at all? We'd have to start all participating hosts at the same time.
Configure the duration of a choreography (hardcoded at the moment)
Anything automatic after booting

Now we have - A choreography mode that can be activated and deactivated via REST API - When active, a choreography with a given duration is automatically started every DURATION seconds starting from a full hour. TODO: - Program a nice choreography - Running the choreography only once --> Is this useful at all? We'd have to start all participating hosts at the same time. - Configure the duration of a choreography (hardcoded at the moment) - Anything automatic after booting

mishi commented

2025-03-13 09:06:23 +01:00

(Migrated from git.mattzz.de)

B, C and Y are done.
D needs a concept
Z is not important and would be one solution to share a config update

Open question:

How to reliably enable/disable choreography mode?
** A fixed schedule could be configured at what time to start and which intervals to use when.
*** Disadvantage: Any rigid schedule never really works out. It might be too often and annoying or it might not be often enough.
** This point more to configuration by communication
*** Any wireless communication to the server may be impossible --> which would point to a wired ethernet connection to hosts that should be reliably reconfigured.
*** In case of unstable connections a polling mechanism may be better where the wifi-connected hosts poll configuration updates from a reliably reachable server ("master").
*** This would also allow hosts to switch back to choreography mode automatically and with the right interval after reboot
*** The hosts which are not called master could simply call the master and copy his choreography mode and duration.
*** Each host would expose mode and duration in its web UI
*** First step: Add a config demon to poll the master's state in regular intervals. Limit this to the choreography mode which is already exposed in the REST API. Test!

B, C and Y are done. D needs a concept Z is not important and would be one solution to share a config update Open question: * How to reliably enable/disable choreography mode? ** A fixed schedule could be configured at what time to start and which intervals to use when. *** Disadvantage: Any rigid schedule never really works out. It might be too often and annoying or it might not be often enough. ** This point more to configuration by communication *** Any wireless communication to the server may be impossible --> which would point to a wired ethernet connection to hosts that should be reliably reconfigured. *** In case of unstable connections a polling mechanism may be better where the wifi-connected hosts poll configuration updates from a reliably reachable server ("master"). *** This would also allow hosts to switch back to choreography mode automatically and with the right interval after reboot *** The hosts which are not called master could simply call the master and copy his choreography mode and duration. *** Each host would expose mode and duration in its web UI *** First step: Add a config demon to poll the master's state in regular intervals. Limit this to the choreography mode which is already exposed in the REST API. Test!

mishi commented

2025-03-13 11:57:24 +01:00

(Migrated from git.mattzz.de)

We now have a mechanism that polls the choreography mode. However, there is still something left to do:

Hosts have to poll for updates at around the same time so that all hosts start the choreography together.

After restart they can poll immediately
If choreography mode is off they should all check during a non-active choreography so that they would all start together at the next slot. This means that the choreography demon should continuously run and the config poll should be synchronized to the choreography schedule and changes only affect the next choreography.

A change of the duration is not yet implemented but also has to be done in a synchronized way. Especially when choreography mode is "on".

We now have a mechanism that polls the choreography mode. However, there is still something left to do: Hosts have to poll for updates at around the same time so that all hosts start the choreography together. * After restart they can poll immediately * If choreography mode is off they should all check during a non-active choreography so that they would all start together at the next slot. This means that the choreography demon should continuously run and the config poll should be synchronized to the choreography schedule and changes only affect the next choreography. A change of the duration is not yet implemented but also has to be done in a synchronized way. Especially when choreography mode is "on".

mishi commented

2025-03-13 13:44:32 +01:00

(Migrated from git.mattzz.de)

Implemented as planned in last post. All hosts involved in a choreography poll the mode at the beginning of the cycle. There is a potential race condition when the master changes the mode right in that moment. This could be avoided by a future improvement.

Another TODO: While there are different choreographies they all are enabled with the same mode from the master. Would it make sense to have different modes for each choreography. Puh, this is getting more and more complicated.

A change of the duration is not yet implemented but also has to be done in a synchronized way. Especially when choreography mode is "on". For this it would be nice if the master would update the duration at a time he knows that the hosts won't be checking it. They now all check at the beginning of the choreography cycle. Of course, the duration would also have to be configuration specific...

Implemented as planned in last post. All hosts involved in a choreography poll the mode at the beginning of the cycle. There is a potential race condition when the master changes the mode right in that moment. This could be avoided by a future improvement. Another TODO: While there are different choreographies they all are enabled with the same mode from the master. Would it make sense to have different modes for each choreography. Puh, this is getting more and more complicated. A change of the duration is not yet implemented but also has to be done in a synchronized way. Especially when choreography mode is "on". For this it would be nice if the master would update the duration at a time he knows that the hosts won't be checking it. They now all check at the beginning of the choreography cycle. Of course, the duration would also have to be configuration specific...

mishi commented

2025-03-13 15:19:55 +01:00

(Migrated from git.mattzz.de)

Duration is now called "interval" and that's the interval to start a new the choreography regardless of how long it takes. This means more choreographies can run at the same time at different stages of progression.

Still to do:

Test what happens if the master is unreachable - all the time and temporarily
Change the interval of a choreography at run time.
Enable/disable specific choreographies instead of all.

Duration is now called "interval" and that's the interval to start a new the choreography regardless of how long it takes. This means more choreographies can run at the same time at different stages of progression. Still to do: * Test what happens if the master is unreachable - all the time and temporarily * Change the interval of a choreography at run time. * Enable/disable specific choreographies instead of all.

mishi commented

2025-03-13 23:07:13 +01:00

(Migrated from git.mattzz.de)

The other open item to support more choreographies with different choreography_mode states and - in the future - intervals can be overcome easily by programming a master responsible for each choreography. E.g. Dolores would be reponsible for the graveyard. The weremonkey for the stairs routine. This would only require to add a hostname entry for the boss of each choreography. Seems like a good trade off and avoids too much complexity.

mishi commented

2025-03-13 23:13:18 +01:00

(Migrated from git.mattzz.de)

So, TODO:

Add a parameter "choreography_interval" to DB, REST and web interface.
Initialise with value from choreography dictionary at boot
Poll update from master
Add the master hostname to the choreography dictionary

What happens if someone change the interval at non-master? Maybe allow only for the configured master of a choreography.

So, TODO: * Add a parameter "choreography_interval" to DB, REST and web interface. * Initialise with value from choreography dictionary at boot * Poll update from master * Add the master hostname to the choreography dictionary What happens if someone change the interval at non-master? Maybe allow only for the configured master of a choreography.

mishi commented

2025-03-13 23:17:36 +01:00

(Migrated from git.mattzz.de)

If the interval can be other values than N*interval==3600 then we also need the overflow handler for the last shorter interval(s) of the hour...

Rows
Columns

Concept for uninterrupted automatic scaring #178