-
Notifications
You must be signed in to change notification settings - Fork 1
Internal Events
Internal Events are used to propagate state changes of a module to other modules on the same hardware. Every event includes the following 2 pieces of information:
-
eventId-- integer, identifies category of the condition that occured -
sourceId-- String, ID of the module issueing the event Internal events do not get forwarded to the socket server and are therefore only available to modules that share the same ESP32. However, Custom event Hooks can be created to execute commands when events occur.
| ID | event type | source module |
|---|---|---|
| 0 | socket disconnected |
socket |
| 1 | socket connected |
socket |
| 2 | socket authed |
socket |
| 3 | wifi disconnected |
WiFi |
| 4 | wifi connected |
WiFi |
| 5 | busy |
all[1] |
| 6 | ready |
all[1] |
| 7 | time synced |
socket |
| 8 | debug on |
core[2] |
| 9 | debug off |
core[2] |
| 10 | input trigger low |
input |
| 11 | input trigger high |
input |
1.↑ modules can signal busy on timed actions or while moving to indicate they are not ready to receive the next command. Followed by ready once the modul is available again.
2.↑ used by the module manager to sync the debug state accross all modules
In order to automate tasks on certain conditions, every ESP32 can hold up to 16 custom event hooks that each hold a single command. In order for a command to be activated, 2 conditions that constitute the event hook must be met:
-
listeningId: the event hook only reacts if the module issuing the event matches this exactly (wildcard*allows for anysourceIdto satisfy this check) -
eventId: the event type of the occuring event
For example an output could be turned off if a connection is lost or if a temperature sensor registers values outside a certain parameter range with this methode.