Mirror of espurna firmware for wireless switches and more
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

3324 lines
85 KiB

2 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
webui: remove jquery dependencies and clean-up websocket API Refactor WebUI: - remove jquery dependency from the base custom.js and use vanilla JS - remove jquery + jquery-datatables dependency from the RFM69 module - replace jquery-datatables handlers with pure-css table + some basic cell filtering (may be incomplete, but tbh it is not worth additional 50Kb to the .bin size) - introduce a common way to notify about the app errors, show small text notification at the top of the page instead of relying on user to find out about errors by using the Web Developer Tools - replace <span name=...> with <span data-settings-key=...> - replace <div> templates with <template>, disallowing modification without an explicit DOM clone - run `eslint` on html/custom.js and `html-validate` on html/index.html, and fix issues detected by both tools Streamline settings group handling in custom.js & index.html - drop module-specific button-add-... in favour of button-add-settings-group - only enforce data-settings-max requirement when the property actually exists - re-create label for=... and input id=... when settings group is modified, so checkboxes refer to the correct element - introduce additional data-... properties to generalize settings group additions - introduce Enumerable object to track some common list elements for <select>, allow to re-create <option> list when messages come in different order Minor fixes that also came with this: - fix relay code incorrectly parsing the payload, causing no relay names to be displayed in the SWITCHES panel - fix scheduler code accidentally combining keys b/c of the way C parses string literals on separate lines, without any commas in-between - thermostat should not reference tmpUnit directly in the webui, replace with module-specific thermostatUnit that is handled on the device itself - fix index.html initial setup invalid adminPass ids - fix index.html layout when removing specific schedules
2 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
api: rework plain and JSON implementations (#2405) - match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler - allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`) Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type. - restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type - adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it. - breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally. - allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON. - add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer - remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`. - add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output) - `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback - `/api/rpc` custom handler replaced with an `apiRegister` callback WIP further down: - no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers. - migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :) - actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays - fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
providers: relays, lights and buttons refactoring (#2414) - gpio module now tracks the known providers (right now, hardware and mcp expander) - refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions - refactored button module to use gpio provider instead of referencing types itself - removed dual & stm code from buttons, migrate both to relay module - added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did) - relays runtime configuration keys - relay command now shows configured relays and current & target statuses - refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead - remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT - allow to bind rf codes to real relays - drop tuya-specific lights provider, remove tuya code from relays and lights modules - integrate tuya via relay listeners and providers, use lights custom provider - implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle) - lights custom provider (global, not per-pin) and state listeners - remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT - lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT - refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing - transition time + step parameter for the lightUpdate - report mask parameter for the lightUpdate - minor fixes across the board resolve #2222
3 years ago
  1. /*
  2. RELAY MODULE
  3. Copyright (C) 2016-2019 by Xose Pérez <xose dot perez at gmail dot com>
  4. Copyright (C) 2019-2021 by Maxim Prokhorov <prokhorov dot max at outlook dot com>
  5. */
  6. #include "espurna.h"
  7. #if RELAY_SUPPORT
  8. #include "api.h"
  9. #include "mqtt.h"
  10. #include "relay.h"
  11. #include "tuya.h"
  12. #include "rpc.h"
  13. #include "rtcmem.h"
  14. #include "light.h"
  15. #include "settings.h"
  16. #include "storage_eeprom.h"
  17. #include "terminal.h"
  18. #include "utils.h"
  19. #include "ws.h"
  20. #include <ArduinoJson.h>
  21. #include <bitset>
  22. #include <cstring>
  23. #include <functional>
  24. #include <vector>
  25. // -----------------------------------------------------------------------------
  26. enum class RelayBoot {
  27. Off,
  28. On,
  29. Same,
  30. Toggle,
  31. LockedOff,
  32. LockedOn
  33. };
  34. enum class RelayLock {
  35. None,
  36. Off,
  37. On,
  38. };
  39. enum class RelayType {
  40. Normal,
  41. Inverse,
  42. Latched,
  43. LatchedInverse
  44. };
  45. enum class RelayMqttTopicMode {
  46. Normal,
  47. Inverse
  48. };
  49. enum class RelayProvider {
  50. None,
  51. Dummy,
  52. Gpio,
  53. Dual,
  54. Stm,
  55. LightState,
  56. Fan,
  57. Lightfox,
  58. Tuya,
  59. };
  60. enum class RelaySync {
  61. None,
  62. ZeroOrOne,
  63. JustOne,
  64. All,
  65. First
  66. };
  67. namespace espurna {
  68. namespace relay {
  69. namespace flood {
  70. using Duration = espurna::duration::Milliseconds;
  71. using Seconds = std::chrono::duration<float>;
  72. namespace build {
  73. namespace {
  74. constexpr Duration window() {
  75. static_assert(Seconds{RELAY_FLOOD_WINDOW}.count() >= 0.0f, "");
  76. return std::chrono::duration_cast<Duration>(Seconds { RELAY_FLOOD_WINDOW });
  77. }
  78. constexpr unsigned long changes() {
  79. return RELAY_FLOOD_CHANGES;
  80. }
  81. } // namespace
  82. } // namespace build
  83. namespace settings {
  84. namespace keys {
  85. namespace {
  86. PROGMEM_STRING(Time, "relayFloodTime");
  87. PROGMEM_STRING(Changes, "relayFloodChanges");
  88. } // namespace
  89. } // namespace keys
  90. namespace {
  91. Duration window() {
  92. return getSetting(keys::Time, build::window());
  93. }
  94. unsigned long changes() {
  95. return getSetting(keys::Changes, build::changes());
  96. }
  97. } // namespace
  98. } // namespace settings
  99. } // namespace flood
  100. namespace build {
  101. namespace {
  102. constexpr espurna::duration::Milliseconds saveDelay() {
  103. return espurna::duration::Milliseconds(RELAY_SAVE_DELAY);
  104. }
  105. constexpr size_t dummyCount() {
  106. return DUMMY_RELAY_COUNT;
  107. }
  108. constexpr RelaySync syncMode() {
  109. return RELAY_SYNC;
  110. }
  111. constexpr espurna::duration::Milliseconds latchingPulse() {
  112. return espurna::duration::Milliseconds(RELAY_LATCHING_PULSE);
  113. }
  114. constexpr espurna::duration::Milliseconds interlockDelay() {
  115. return espurna::duration::Milliseconds(RELAY_DELAY_INTERLOCK);
  116. }
  117. constexpr espurna::duration::Milliseconds delayOn(size_t index) {
  118. return espurna::duration::Milliseconds(
  119. (index == 0) ? RELAY1_DELAY_ON :
  120. (index == 1) ? RELAY2_DELAY_ON :
  121. (index == 2) ? RELAY3_DELAY_ON :
  122. (index == 3) ? RELAY4_DELAY_ON :
  123. (index == 4) ? RELAY5_DELAY_ON :
  124. (index == 5) ? RELAY6_DELAY_ON :
  125. (index == 6) ? RELAY7_DELAY_ON :
  126. (index == 7) ? RELAY8_DELAY_ON : 0ul
  127. );
  128. }
  129. constexpr espurna::duration::Milliseconds delayOff(size_t index) {
  130. return espurna::duration::Milliseconds(
  131. (index == 0) ? RELAY1_DELAY_OFF :
  132. (index == 1) ? RELAY2_DELAY_OFF :
  133. (index == 2) ? RELAY3_DELAY_OFF :
  134. (index == 3) ? RELAY4_DELAY_OFF :
  135. (index == 4) ? RELAY5_DELAY_OFF :
  136. (index == 5) ? RELAY6_DELAY_OFF :
  137. (index == 6) ? RELAY7_DELAY_OFF :
  138. (index == 7) ? RELAY8_DELAY_OFF : 0ul
  139. );
  140. }
  141. constexpr unsigned char pin(size_t index) {
  142. return (
  143. (index == 0) ? RELAY1_PIN :
  144. (index == 1) ? RELAY2_PIN :
  145. (index == 2) ? RELAY3_PIN :
  146. (index == 3) ? RELAY4_PIN :
  147. (index == 4) ? RELAY5_PIN :
  148. (index == 5) ? RELAY6_PIN :
  149. (index == 6) ? RELAY7_PIN :
  150. (index == 7) ? RELAY8_PIN : GPIO_NONE
  151. );
  152. }
  153. constexpr RelayType type(size_t index) {
  154. return (
  155. (index == 0) ? RELAY1_TYPE :
  156. (index == 1) ? RELAY2_TYPE :
  157. (index == 2) ? RELAY3_TYPE :
  158. (index == 3) ? RELAY4_TYPE :
  159. (index == 4) ? RELAY5_TYPE :
  160. (index == 5) ? RELAY6_TYPE :
  161. (index == 6) ? RELAY7_TYPE :
  162. (index == 7) ? RELAY8_TYPE : RELAY_TYPE_NORMAL
  163. );
  164. }
  165. constexpr GpioType pinType(size_t index) {
  166. return (
  167. (index == 0) ? RELAY1_PIN_TYPE :
  168. (index == 1) ? RELAY2_PIN_TYPE :
  169. (index == 2) ? RELAY3_PIN_TYPE :
  170. (index == 3) ? RELAY4_PIN_TYPE :
  171. (index == 4) ? RELAY5_PIN_TYPE :
  172. (index == 5) ? RELAY6_PIN_TYPE :
  173. (index == 6) ? RELAY7_PIN_TYPE :
  174. (index == 7) ? RELAY8_PIN_TYPE : GPIO_TYPE_NONE
  175. );
  176. }
  177. constexpr unsigned char resetPin(size_t index) {
  178. return (
  179. (index == 0) ? RELAY1_RESET_PIN :
  180. (index == 1) ? RELAY2_RESET_PIN :
  181. (index == 2) ? RELAY3_RESET_PIN :
  182. (index == 3) ? RELAY4_RESET_PIN :
  183. (index == 4) ? RELAY5_RESET_PIN :
  184. (index == 5) ? RELAY6_RESET_PIN :
  185. (index == 6) ? RELAY7_RESET_PIN :
  186. (index == 7) ? RELAY8_RESET_PIN : GPIO_NONE
  187. );
  188. }
  189. constexpr RelayBoot bootMode(size_t index) {
  190. return (
  191. (index == 0) ? RELAY1_BOOT_MODE :
  192. (index == 1) ? RELAY2_BOOT_MODE :
  193. (index == 2) ? RELAY3_BOOT_MODE :
  194. (index == 3) ? RELAY4_BOOT_MODE :
  195. (index == 4) ? RELAY5_BOOT_MODE :
  196. (index == 5) ? RELAY6_BOOT_MODE :
  197. (index == 6) ? RELAY7_BOOT_MODE :
  198. (index == 7) ? RELAY8_BOOT_MODE : RELAY_BOOT_OFF
  199. );
  200. }
  201. constexpr RelayProvider provider(size_t index) {
  202. return (
  203. (index == 0) ? (RELAY1_PROVIDER) :
  204. (index == 1) ? (RELAY2_PROVIDER) :
  205. (index == 2) ? (RELAY3_PROVIDER) :
  206. (index == 3) ? (RELAY4_PROVIDER) :
  207. (index == 4) ? (RELAY5_PROVIDER) :
  208. (index == 5) ? (RELAY6_PROVIDER) :
  209. (index == 6) ? (RELAY7_PROVIDER) :
  210. (index == 7) ? (RELAY8_PROVIDER) : RELAY_PROVIDER_NONE
  211. );
  212. }
  213. constexpr RelayMqttTopicMode mqttTopicMode(size_t index) {
  214. return (
  215. (index == 0) ? (RELAY1_MQTT_TOPIC_MODE) :
  216. (index == 1) ? (RELAY2_MQTT_TOPIC_MODE) :
  217. (index == 2) ? (RELAY3_MQTT_TOPIC_MODE) :
  218. (index == 3) ? (RELAY4_MQTT_TOPIC_MODE) :
  219. (index == 4) ? (RELAY5_MQTT_TOPIC_MODE) :
  220. (index == 5) ? (RELAY6_MQTT_TOPIC_MODE) :
  221. (index == 6) ? (RELAY7_MQTT_TOPIC_MODE) :
  222. (index == 7) ? (RELAY8_MQTT_TOPIC_MODE) : RELAY_MQTT_TOPIC_MODE
  223. );
  224. }
  225. PROGMEM_STRING(PayloadOn, RELAY_MQTT_ON);
  226. PROGMEM_STRING(PayloadOff, RELAY_MQTT_OFF);
  227. PROGMEM_STRING(PayloadToggle, RELAY_MQTT_TOGGLE);
  228. #define RELAY_SETTING_STRING_RESULT(FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH)\
  229. (index == 0) ? STRING_VIEW_SETTING(FIRST) :\
  230. (index == 1) ? STRING_VIEW_SETTING(SECOND) :\
  231. (index == 2) ? STRING_VIEW_SETTING(THIRD) :\
  232. (index == 3) ? STRING_VIEW_SETTING(FOURTH) :\
  233. (index == 4) ? STRING_VIEW_SETTING(FIFTH) :\
  234. (index == 5) ? STRING_VIEW_SETTING(SIXTH) :\
  235. (index == 6) ? STRING_VIEW_SETTING(SEVENTH) :\
  236. (index == 7) ? STRING_VIEW_SETTING(EIGHTH) : StringView()
  237. StringView mqttTopicSub(size_t index) {
  238. return RELAY_SETTING_STRING_RESULT(
  239. RELAY1_MQTT_TOPIC_SUB,
  240. RELAY2_MQTT_TOPIC_SUB,
  241. RELAY3_MQTT_TOPIC_SUB,
  242. RELAY4_MQTT_TOPIC_SUB,
  243. RELAY5_MQTT_TOPIC_SUB,
  244. RELAY6_MQTT_TOPIC_SUB,
  245. RELAY7_MQTT_TOPIC_SUB,
  246. RELAY8_MQTT_TOPIC_SUB
  247. );
  248. }
  249. StringView mqttTopicPub(size_t index) {
  250. return RELAY_SETTING_STRING_RESULT(
  251. RELAY1_MQTT_TOPIC_PUB,
  252. RELAY2_MQTT_TOPIC_PUB,
  253. RELAY3_MQTT_TOPIC_PUB,
  254. RELAY4_MQTT_TOPIC_PUB,
  255. RELAY5_MQTT_TOPIC_PUB,
  256. RELAY6_MQTT_TOPIC_PUB,
  257. RELAY7_MQTT_TOPIC_PUB,
  258. RELAY8_MQTT_TOPIC_PUB
  259. );
  260. }
  261. #undef RELAY_SETTING_STRING_RESULT
  262. constexpr PayloadStatus mqttDisconnectionStatus(size_t index) {
  263. return (
  264. (index == 0) ? (RELAY1_MQTT_DISCONNECT_STATUS) :
  265. (index == 1) ? (RELAY2_MQTT_DISCONNECT_STATUS) :
  266. (index == 2) ? (RELAY3_MQTT_DISCONNECT_STATUS) :
  267. (index == 3) ? (RELAY4_MQTT_DISCONNECT_STATUS) :
  268. (index == 4) ? (RELAY5_MQTT_DISCONNECT_STATUS) :
  269. (index == 5) ? (RELAY6_MQTT_DISCONNECT_STATUS) :
  270. (index == 6) ? (RELAY7_MQTT_DISCONNECT_STATUS) :
  271. (index == 7) ? (RELAY8_MQTT_DISCONNECT_STATUS) : RELAY_MQTT_DISCONNECT_NONE
  272. );
  273. }
  274. } // namespace
  275. } // namespace build
  276. namespace pulse {
  277. using Duration = espurna::duration::Milliseconds;
  278. using Seconds = std::chrono::duration<float>;
  279. enum class Mode {
  280. None,
  281. Off,
  282. On
  283. };
  284. } // namespace pulse
  285. } // namespace relay
  286. } // namespace espurna
  287. namespace espurna {
  288. namespace relay {
  289. namespace pulse {
  290. namespace build {
  291. namespace {
  292. constexpr Seconds time(size_t index) {
  293. return Seconds(
  294. (index == 0) ? RELAY1_PULSE_TIME :
  295. (index == 1) ? RELAY2_PULSE_TIME :
  296. (index == 2) ? RELAY3_PULSE_TIME :
  297. (index == 3) ? RELAY4_PULSE_TIME :
  298. (index == 4) ? RELAY5_PULSE_TIME :
  299. (index == 5) ? RELAY6_PULSE_TIME :
  300. (index == 6) ? RELAY7_PULSE_TIME :
  301. (index == 7) ? RELAY8_PULSE_TIME : RELAY_PULSE_TIME
  302. );
  303. }
  304. static_assert(time(0).count() >= 0.0f, "");
  305. static_assert(time(1).count() >= 0.0f, "");
  306. static_assert(time(2).count() >= 0.0f, "");
  307. static_assert(time(3).count() >= 0.0f, "");
  308. static_assert(time(4).count() >= 0.0f, "");
  309. static_assert(time(5).count() >= 0.0f, "");
  310. static_assert(time(6).count() >= 0.0f, "");
  311. static_assert(time(7).count() >= 0.0f, "");
  312. constexpr Mode mode(size_t index) {
  313. return (
  314. (index == 0) ? RELAY1_PULSE_MODE :
  315. (index == 1) ? RELAY2_PULSE_MODE :
  316. (index == 2) ? RELAY3_PULSE_MODE :
  317. (index == 3) ? RELAY4_PULSE_MODE :
  318. (index == 4) ? RELAY5_PULSE_MODE :
  319. (index == 5) ? RELAY6_PULSE_MODE :
  320. (index == 6) ? RELAY7_PULSE_MODE :
  321. (index == 7) ? RELAY8_PULSE_MODE : RELAY_PULSE_NONE
  322. );
  323. }
  324. } // namespace
  325. } // namespace build
  326. namespace settings {
  327. namespace keys {
  328. namespace {
  329. PROGMEM_STRING(Time, "relayTime");
  330. PROGMEM_STRING(Mode, "relayPulse");
  331. } // namespace
  332. } // namespace keys
  333. namespace {
  334. using ParseResult = espurna::settings::internal::duration_convert::Result;
  335. Duration native_duration(ParseResult result) {
  336. using namespace espurna::settings::internal;
  337. if (result.ok) {
  338. return duration_convert::to_chrono_duration<Duration>(result.value);
  339. }
  340. return Duration::min();
  341. }
  342. ParseResult parse_time(StringView view) {
  343. using namespace espurna::settings::internal;
  344. return duration_convert::parse(view, Seconds::period{});
  345. }
  346. Duration native_duration(StringView view) {
  347. return native_duration(parse_time(view));
  348. }
  349. Duration time(size_t index) {
  350. const auto time = espurna::settings::get(
  351. espurna::settings::Key{keys::Time, index}.value());
  352. if (!time) {
  353. return std::chrono::duration_cast<Duration>(build::time(index));
  354. }
  355. return native_duration(time.view());
  356. }
  357. Mode mode(size_t index) {
  358. return getSetting({keys::Mode, index}, build::mode(index));
  359. }
  360. } // namespace
  361. } // namespace settings
  362. namespace {
  363. struct Timer {
  364. using Duration = timer::SystemTimer::Duration;
  365. Timer() = delete;
  366. Timer(const Timer&) = delete;
  367. Timer(Timer&&) = delete;
  368. Timer(Duration duration, size_t id, bool status) :
  369. _duration(duration),
  370. _id(id),
  371. _status(status)
  372. {}
  373. ~Timer() {
  374. _timer.stop();
  375. }
  376. Timer& operator=(const Timer&) = delete;
  377. Timer& operator=(Timer&&) = delete;
  378. explicit operator bool() const {
  379. return static_cast<bool>(_timer);
  380. }
  381. bool operator==(const Timer& other) const {
  382. return (_duration == other._duration)
  383. && (_id == other._id)
  384. && (_status == other._status);
  385. }
  386. Timer& update(Duration duration, bool status) {
  387. stop();
  388. _duration = duration;
  389. _status = status;
  390. return *this;
  391. }
  392. size_t id() const {
  393. return _id;
  394. }
  395. Duration duration() const {
  396. return _duration;
  397. }
  398. bool status() const {
  399. return _status;
  400. }
  401. void stop() {
  402. _timer.stop();
  403. }
  404. void start() {
  405. const auto id = _id;
  406. const auto status = _status;
  407. _timer.once(
  408. (_duration.count() > 0)
  409. ? _duration
  410. : timer::SystemTimer::DurationMin,
  411. [id, status]() {
  412. relayStatus(id, status);
  413. });
  414. }
  415. private:
  416. Duration _duration;
  417. size_t _id;
  418. bool _status;
  419. timer::SystemTimer _timer;
  420. };
  421. namespace internal {
  422. std::forward_list<Timer> timers;
  423. } // namespace internal
  424. auto find(size_t id) -> decltype(internal::timers.begin()) {
  425. return std::find_if(
  426. internal::timers.begin(),
  427. internal::timers.end(),
  428. [&](const Timer& timer) {
  429. return id == timer.id();
  430. });
  431. }
  432. void trigger(Duration duration, size_t id, bool target) {
  433. if (duration.count() == 0) {
  434. bool found { false };
  435. internal::timers.remove_if(
  436. [&](const Timer& timer) {
  437. if (id == timer.id()) {
  438. found = true;
  439. return true;
  440. }
  441. return false;
  442. });
  443. if (found) {
  444. DEBUG_MSG_P(PSTR("[RELAY] #%zu pulse stopped\n"), id);
  445. }
  446. return;
  447. }
  448. bool rescheduled [[gnu::unused]] { false };
  449. auto it = find(id);
  450. if (it != internal::timers.end()) {
  451. (*it).update(duration, target);
  452. rescheduled = true;
  453. } else {
  454. internal::timers.emplace_front(duration, id, target);
  455. it = internal::timers.begin();
  456. }
  457. (*it).start();
  458. DEBUG_MSG_P(PSTR("[RELAY] #%zu pulse %s %sscheduled in %lu (ms)\n"),
  459. id, target ? "ON" : "OFF",
  460. rescheduled ? "re" : "",
  461. duration.count());
  462. }
  463. // Update the pulse counter when the relay is already in the opposite state (#454)
  464. void poll(size_t id, bool target) {
  465. auto it = find(id);
  466. if ((it != internal::timers.end()) && ((*it).status() != target)) {
  467. (*it).start();
  468. }
  469. }
  470. void expire() {
  471. internal::timers.remove_if([](const Timer& timer) {
  472. return !static_cast<bool>(timer)
  473. || (relayStatus(timer.id()) == timer.status());
  474. });
  475. }
  476. [[gnu::unused]]
  477. Seconds findDuration(size_t id) {
  478. Seconds out{};
  479. auto it = find(id);
  480. if (it != internal::timers.end()) {
  481. out = std::chrono::duration_cast<Seconds>((*it).duration());
  482. }
  483. return out;
  484. }
  485. bool isNormalStatus(Mode pulse, bool status) {
  486. switch (pulse) {
  487. case Mode::None:
  488. break;
  489. case Mode::On:
  490. return status;
  491. case Mode::Off:
  492. return !status;
  493. }
  494. return false;
  495. }
  496. bool isActive(Mode pulse) {
  497. return pulse != Mode::None;
  498. }
  499. } // namespace
  500. } // namespace pulse
  501. namespace settings {
  502. namespace options {
  503. namespace {
  504. using espurna::settings::options::Enumeration;
  505. PROGMEM_STRING(TristateNone, "none");
  506. PROGMEM_STRING(TristateOff, "off");
  507. PROGMEM_STRING(TristateOn, "on");
  508. template <typename T>
  509. struct RelayTristateHelper {
  510. static constexpr std::array<Enumeration<T>, 3> Options PROGMEM {
  511. {{T::None, TristateNone},
  512. {T::Off, TristateOff},
  513. {T::On, TristateOn}}
  514. };
  515. static T convert(const String& value) {
  516. return espurna::settings::internal::convert(Options, value, T::None);
  517. }
  518. static String serialize(T value) {
  519. return espurna::settings::internal::serialize(Options, value);
  520. }
  521. };
  522. template <typename T>
  523. constexpr std::array<Enumeration<T>, 3> RelayTristateHelper<T>::Options;
  524. PROGMEM_STRING(PayloadStatusOff, "off");
  525. PROGMEM_STRING(PayloadStatusOn, "on");
  526. PROGMEM_STRING(PayloadStatusToggle, "toggle");
  527. PROGMEM_STRING(PayloadStatusUnknown, "unknown");
  528. static constexpr std::array<Enumeration<PayloadStatus>, 4> PayloadStatusOptions PROGMEM {
  529. {{PayloadStatus::Off, PayloadStatusOff},
  530. {PayloadStatus::On, PayloadStatusOn},
  531. {PayloadStatus::Toggle, PayloadStatusToggle},
  532. {PayloadStatus::Unknown, PayloadStatusUnknown}}
  533. };
  534. PROGMEM_STRING(Normal, "normal");
  535. PROGMEM_STRING(Inverse, "inverse");
  536. static constexpr std::array<Enumeration<RelayMqttTopicMode>, 2> RelayMqttTopicModeOptions PROGMEM {
  537. {{RelayMqttTopicMode::Normal, Normal},
  538. {RelayMqttTopicMode::Inverse, Inverse}}
  539. };
  540. PROGMEM_STRING(RelayBootOff, "off");
  541. PROGMEM_STRING(RelayBootOn, "on");
  542. PROGMEM_STRING(RelayBootSame, "same");
  543. PROGMEM_STRING(RelayBootToggle, "toggle");
  544. PROGMEM_STRING(RelayBootLockedOff, "locked-off");
  545. PROGMEM_STRING(RelayBootLockedOn, "locked-on");
  546. static constexpr std::array<Enumeration<RelayBoot>, 6> RelayBootOptions PROGMEM {
  547. {{RelayBoot::Off, RelayBootOff},
  548. {RelayBoot::On, RelayBootOn},
  549. {RelayBoot::Same, RelayBootSame},
  550. {RelayBoot::Toggle, RelayBootToggle},
  551. {RelayBoot::LockedOff, RelayBootLockedOff},
  552. {RelayBoot::LockedOn, RelayBootLockedOn}}
  553. };
  554. PROGMEM_STRING(RelayProviderNone, "none");
  555. PROGMEM_STRING(RelayProviderDummy, "dummy");
  556. PROGMEM_STRING(RelayProviderGpio, "gpio");
  557. PROGMEM_STRING(RelayProviderDual, "dual");
  558. PROGMEM_STRING(RelayProviderStm, "stm");
  559. PROGMEM_STRING(RelayProviderLightState, "light-state");
  560. PROGMEM_STRING(RelayProviderFan, "fan");
  561. PROGMEM_STRING(RelayProviderLightfox, "lightfox");
  562. PROGMEM_STRING(RelayProviderTuya, "tuya");
  563. static constexpr std::array<Enumeration<RelayProvider>, 9> RelayProviderOptions PROGMEM {
  564. {{RelayProvider::None, RelayProviderNone},
  565. {RelayProvider::Dummy, RelayProviderDummy},
  566. {RelayProvider::Gpio, RelayProviderGpio},
  567. {RelayProvider::Dual, RelayProviderDual},
  568. {RelayProvider::Stm, RelayProviderStm},
  569. {RelayProvider::LightState, RelayProviderLightState},
  570. {RelayProvider::Fan, RelayProviderFan},
  571. {RelayProvider::Lightfox, RelayProviderLightfox},
  572. {RelayProvider::Tuya, RelayProviderTuya}}
  573. };
  574. PROGMEM_STRING(RelayTypeNormal, "normal");
  575. PROGMEM_STRING(RelayTypeInverse, "inverse");
  576. PROGMEM_STRING(RelayTypeLatched, "latched");
  577. PROGMEM_STRING(RelayTypeLatchedInverse, "latched-inverse");
  578. static constexpr std::array<Enumeration<RelayType>, 4> RelayTypeOptions PROGMEM {
  579. {{RelayType::Normal, RelayTypeNormal},
  580. {RelayType::Inverse, RelayTypeInverse},
  581. {RelayType::Latched, RelayTypeLatched},
  582. {RelayType::LatchedInverse, RelayTypeLatchedInverse}}
  583. };
  584. PROGMEM_STRING(None, "none");
  585. PROGMEM_STRING(ZeroOrOne, "zero-or-one");
  586. PROGMEM_STRING(JustOne, "just-one");
  587. PROGMEM_STRING(All, "all");
  588. PROGMEM_STRING(First, "first");
  589. static constexpr std::array<Enumeration<RelaySync>, 5> RelaySyncOptions PROGMEM {
  590. {{RelaySync::None, None},
  591. {RelaySync::ZeroOrOne, ZeroOrOne},
  592. {RelaySync::JustOne, JustOne},
  593. {RelaySync::All, All},
  594. {RelaySync::First, First}}
  595. };
  596. } // namespace
  597. } // namespace options
  598. } // namespace settings
  599. } // namespace relay
  600. } // namespace espurna
  601. using RelayMask = std::bitset<RelaysMax>;
  602. struct RelayMaskHelper {
  603. using IntegralType = uint32_t;
  604. static_assert(RelaysMax <= (sizeof(IntegralType) * 8), "");
  605. RelayMaskHelper() = default;
  606. RelayMaskHelper(const RelayMaskHelper&) = default;
  607. RelayMaskHelper(RelayMaskHelper&&) = default;
  608. explicit RelayMaskHelper(RelayMask mask) noexcept :
  609. _mask(mask)
  610. {}
  611. explicit RelayMaskHelper(IntegralType mask) noexcept :
  612. _mask(mask)
  613. {}
  614. IntegralType toUnsigned() const {
  615. return _mask.to_ulong();
  616. }
  617. String toString() const {
  618. return formatUnsigned(toUnsigned(), 2);
  619. }
  620. const RelayMask& mask() const {
  621. return _mask;
  622. }
  623. void reset() {
  624. _mask.reset();
  625. }
  626. void set(size_t id, bool status) {
  627. _mask.set(id, status);
  628. }
  629. bool operator[](size_t id) const {
  630. return _mask[id];
  631. }
  632. private:
  633. RelayMask _mask {};
  634. };
  635. namespace espurna {
  636. namespace settings {
  637. namespace internal {
  638. namespace {
  639. using relay::settings::options::RelayTristateHelper;
  640. using relay::settings::options::PayloadStatusOptions;
  641. using relay::settings::options::RelayMqttTopicModeOptions;
  642. using relay::settings::options::RelayBootOptions;
  643. using relay::settings::options::RelayProviderOptions;
  644. using relay::settings::options::RelayTypeOptions;
  645. using relay::settings::options::RelaySyncOptions;
  646. } // namespace
  647. template <>
  648. PayloadStatus convert(const String& value) {
  649. return convert(PayloadStatusOptions, value, PayloadStatus::Unknown);
  650. }
  651. String serialize(PayloadStatus value) {
  652. return serialize(PayloadStatusOptions, value);
  653. }
  654. template <>
  655. RelayMqttTopicMode convert(const String& value) {
  656. return convert(RelayMqttTopicModeOptions, value, RelayMqttTopicMode::Normal);
  657. }
  658. String serialize(RelayMqttTopicMode value) {
  659. return serialize(RelayMqttTopicModeOptions, value);
  660. }
  661. template <>
  662. espurna::relay::pulse::Mode convert(const String& value) {
  663. return RelayTristateHelper<espurna::relay::pulse::Mode>::convert(value);
  664. }
  665. String serialize(espurna::relay::pulse::Mode value) {
  666. return RelayTristateHelper<espurna::relay::pulse::Mode>::serialize(value);
  667. }
  668. template <>
  669. RelayBoot convert(const String& value) {
  670. return convert(RelayBootOptions, value, RelayBoot::Off);
  671. }
  672. String serialize(RelayBoot value) {
  673. return serialize(RelayBootOptions, value);
  674. }
  675. template <>
  676. RelayLock convert(const String& value) {
  677. return RelayTristateHelper<RelayLock>::convert(value);
  678. }
  679. template <>
  680. RelayProvider convert(const String& value) {
  681. return convert(RelayProviderOptions, value, RelayProvider::None);
  682. }
  683. String serialize(RelayProvider value) {
  684. return serialize(RelayProviderOptions, value);
  685. }
  686. template <>
  687. RelayType convert(const String& value) {
  688. return convert(RelayTypeOptions, value, RelayType::Normal);
  689. }
  690. String serialize(RelayType value) {
  691. return serialize(RelayTypeOptions, value);
  692. }
  693. template<>
  694. RelayMaskHelper convert(const String& value) {
  695. return RelayMaskHelper { convert<RelayMaskHelper::IntegralType>(value) };
  696. }
  697. String serialize(RelayMaskHelper mask) {
  698. return mask.toString();
  699. }
  700. template <>
  701. RelaySync convert(const String& value) {
  702. return convert(RelaySyncOptions, value, RelaySync::None);
  703. }
  704. String serialize(RelaySync value) {
  705. return serialize(RelaySyncOptions, value);
  706. }
  707. } // namespace internal
  708. } // namespace settings
  709. namespace relay {
  710. namespace settings {
  711. namespace keys {
  712. namespace {
  713. PROGMEM_STRING(Name, "relayName");
  714. PROGMEM_STRING(Provider, "relayProv");
  715. PROGMEM_STRING(Type, "relayType");
  716. PROGMEM_STRING(GpioType, "relayGpioType");
  717. PROGMEM_STRING(Gpio, "relayGpio");
  718. PROGMEM_STRING(ResetGpio, "relayResetGpio");
  719. PROGMEM_STRING(Boot, "relayBoot");
  720. PROGMEM_STRING(DelayOn, "relayDelayOn");
  721. PROGMEM_STRING(DelayOff, "relayDelayOff");
  722. #if MQTT_SUPPORT
  723. PROGMEM_STRING(TopicPub, "relayTopicPub");
  724. PROGMEM_STRING(TopicSub, "relayTopicSub");
  725. PROGMEM_STRING(TopicMode, "relayTopicMode");
  726. PROGMEM_STRING(MqttDisconnection, "relayMqttDisc");
  727. #endif
  728. PROGMEM_STRING(Dummy, "relayDummy");
  729. PROGMEM_STRING(BootMask, "relayBootMask");
  730. PROGMEM_STRING(Interlock, "relayIlkDelay");
  731. PROGMEM_STRING(Sync, "relaySync");
  732. PROGMEM_STRING(PayloadOn, "relayPayloadOn");
  733. PROGMEM_STRING(PayloadOff, "relayPayloadOff");
  734. PROGMEM_STRING(PayloadToggle, "relayPayloadToggle");
  735. } // namespace
  736. } // namespace keys
  737. namespace {
  738. size_t dummyCount() {
  739. return getSetting(keys::Dummy, build::dummyCount());
  740. }
  741. [[gnu::unused]]
  742. String name(size_t index) {
  743. return getSetting({keys::Name, index});
  744. }
  745. RelayProvider provider(size_t index) {
  746. return getSetting({keys::Provider, index}, build::provider(index));
  747. }
  748. RelayType type(size_t index) {
  749. return getSetting({keys::Type, index}, build::type(index));
  750. }
  751. GpioType pinType(size_t index) {
  752. return getSetting({keys::GpioType, index}, build::pinType(index));
  753. }
  754. unsigned char pin(size_t index) {
  755. return getSetting({keys::Gpio, index}, build::pin(index));
  756. }
  757. unsigned char resetPin(size_t index) {
  758. return getSetting({keys::ResetGpio, index}, build::resetPin(index));
  759. }
  760. RelayBoot bootMode(size_t index) {
  761. return getSetting({keys::Boot, index}, build::bootMode(index));
  762. }
  763. RelayMaskHelper bootMask() {
  764. static const RelayMaskHelper defaultMask;
  765. return getSetting(keys::BootMask, defaultMask);
  766. }
  767. void bootMask(const String& mask) {
  768. setSetting(keys::BootMask, mask);
  769. }
  770. void bootMask(const RelayMaskHelper& mask) {
  771. bootMask(mask.toString());
  772. }
  773. espurna::duration::Milliseconds delayOn(size_t index) {
  774. return getSetting({keys::DelayOn, index}, build::delayOn(index));
  775. }
  776. espurna::duration::Milliseconds delayOff(size_t index) {
  777. return getSetting({keys::DelayOff, index}, build::delayOff(index));
  778. }
  779. espurna::duration::Milliseconds interlockDelay() {
  780. return getSetting(keys::Interlock, build::interlockDelay());
  781. }
  782. RelaySync syncMode() {
  783. return getSetting(keys::Sync, build::syncMode());
  784. }
  785. [[gnu::unused]]
  786. String payloadOn() {
  787. return getSetting(keys::PayloadOn, StringView(build::PayloadOn));
  788. }
  789. [[gnu::unused]]
  790. String payloadOff() {
  791. return getSetting(keys::PayloadOff, StringView(build::PayloadOff));
  792. }
  793. [[gnu::unused]]
  794. String payloadToggle() {
  795. return getSetting(keys::PayloadToggle, StringView(build::PayloadToggle));
  796. }
  797. #if MQTT_SUPPORT
  798. String mqttTopicSub(size_t index) {
  799. return getSetting({keys::TopicSub, index}, build::mqttTopicSub(index));
  800. }
  801. String mqttTopicPub(size_t index) {
  802. return getSetting({keys::TopicPub, index}, build::mqttTopicPub(index));
  803. }
  804. RelayMqttTopicMode mqttTopicMode(size_t index) {
  805. return getSetting({keys::TopicMode, index}, build::mqttTopicMode(index));
  806. }
  807. PayloadStatus mqttDisconnectionStatus(size_t index) {
  808. return getSetting({keys::MqttDisconnection, index}, build::mqttDisconnectionStatus(index));
  809. }
  810. #endif
  811. } // namespace
  812. namespace query {
  813. namespace {
  814. #define EXACT_VALUE(NAME, FUNC)\
  815. String NAME () {\
  816. return espurna::settings::internal::serialize(FUNC());\
  817. }
  818. #define ID_VALUE(NAME, FUNC)\
  819. String NAME (size_t id) {\
  820. return espurna::settings::internal::serialize(FUNC(id));\
  821. }
  822. namespace internal {
  823. EXACT_VALUE(dummyCount, settings::dummyCount)
  824. EXACT_VALUE(bootMask, settings::bootMask)
  825. EXACT_VALUE(interlockDelay, settings::interlockDelay)
  826. EXACT_VALUE(syncMode, settings::syncMode)
  827. ID_VALUE(provider, settings::provider)
  828. ID_VALUE(type, settings::type)
  829. ID_VALUE(pinType, settings::pinType)
  830. ID_VALUE(pin, settings::pin)
  831. ID_VALUE(resetPin, settings::resetPin)
  832. ID_VALUE(bootMode, settings::bootMode)
  833. ID_VALUE(delayOn, settings::delayOn)
  834. ID_VALUE(delayOff, settings::delayOff)
  835. ID_VALUE(pulseMode, pulse::settings::mode)
  836. String pulseTime(size_t index) {
  837. const auto result = pulse::settings::time(index);
  838. const auto as_seconds =
  839. std::chrono::duration_cast<pulse::Seconds>(result);
  840. return espurna::settings::internal::serialize(as_seconds.count());
  841. }
  842. #if MQTT_SUPPORT
  843. ID_VALUE(mqttDisconnectionStatus, settings::mqttDisconnectionStatus)
  844. ID_VALUE(mqttTopicMode, settings::mqttTopicMode)
  845. #endif
  846. #undef ID_VALUE
  847. #undef EXACT_VALUE
  848. } // namespace internal
  849. static constexpr espurna::settings::query::Setting Settings[] PROGMEM {
  850. {keys::Dummy, internal::dummyCount},
  851. {keys::BootMask, internal::bootMask},
  852. {keys::Interlock, internal::interlockDelay},
  853. {keys::Sync, internal::syncMode}
  854. };
  855. static constexpr espurna::settings::query::IndexedSetting IndexedSettings[] PROGMEM {
  856. {keys::Name, settings::name},
  857. {keys::Provider, internal::provider},
  858. {keys::Type, internal::type},
  859. {keys::GpioType, internal::pinType},
  860. {keys::Gpio, internal::pin},
  861. {keys::ResetGpio, internal::resetPin},
  862. {keys::Boot, internal::bootMode},
  863. {keys::DelayOn, internal::delayOn},
  864. {keys::DelayOff, internal::delayOff},
  865. {pulse::settings::keys::Time, internal::pulseTime},
  866. {pulse::settings::keys::Mode, internal::pulseMode},
  867. #if MQTT_SUPPORT
  868. {keys::TopicPub, settings::mqttTopicPub},
  869. {keys::TopicSub, settings::mqttTopicSub},
  870. {keys::TopicMode, internal::mqttTopicMode},
  871. {keys::MqttDisconnection, internal::mqttDisconnectionStatus},
  872. #endif
  873. };
  874. } // namespace
  875. } // namespace query
  876. } // namespace settings
  877. } // namespace relay
  878. } // namespace espurna
  879. // -----------------------------------------------------------------------------
  880. // RELAY CONTROL
  881. // -----------------------------------------------------------------------------
  882. // No-op provider, available for purely virtual relays that are controlled only via API
  883. struct DummyProvider : public RelayProviderBase {
  884. espurna::StringView id() const override {
  885. return espurna::relay::settings::options::RelayProviderDummy;
  886. }
  887. void change(bool) override {
  888. }
  889. static RelayProviderBase* sharedInstance() {
  890. static DummyProvider provider;
  891. return &provider;
  892. }
  893. };
  894. class Relay {
  895. public:
  896. using TimeSource = espurna::time::CoreClock;
  897. using Delay = espurna::duration::Milliseconds;
  898. using TimePoint = TimeSource::time_point;
  899. using PulseMode = espurna::relay::pulse::Mode;
  900. using PulseTime = espurna::relay::pulse::Duration;
  901. Relay() = default;
  902. explicit Relay(RelayProviderBasePtr&& ptr) :
  903. provider(ptr.release())
  904. {}
  905. explicit Relay(RelayProviderBase* ptr) :
  906. provider(ptr)
  907. {}
  908. // ON / OFF actions implementation
  909. // Defaults to 'DummyProvider', since we don't want to check provider existence every time
  910. RelayProviderBase* provider { DummyProvider::sharedInstance() };
  911. // *Before* changing status, waits for the specified time (ms)
  912. Delay delay_on { 0ul };
  913. Delay delay_off { 0ul };
  914. // *After* changing status, checks whether we should remain in it
  915. // If not, starts a timer for the specified time (ms)
  916. PulseMode pulse { PulseMode::None };
  917. PulseTime pulse_time { 0ul };
  918. // Flood window start time
  919. TimePoint fw_start{};
  920. // Number of changes within the current flood window
  921. unsigned char fw_count { 0u };
  922. // Time when relay was scheduled to change
  923. TimePoint change_start{};
  924. // Delay until the next change
  925. Delay change_delay { 0ul };
  926. // Already applied status (passed to provider) and a pending one
  927. bool current_status { false };
  928. bool target_status { false };
  929. // Holds the value of target status that persists and cannot be changed from
  930. RelayLock lock { RelayLock::None };
  931. // MQTT report on relay and / or group topic
  932. bool report { false };
  933. bool group_report { false };
  934. };
  935. namespace {
  936. struct RelaySaveTimer {
  937. using Timer = espurna::timer::SystemTimer;
  938. using Duration = Timer::Duration;
  939. RelaySaveTimer() = default;
  940. RelaySaveTimer(const RelaySaveTimer&) = delete;
  941. RelaySaveTimer& operator=(const RelaySaveTimer&) = delete;
  942. RelaySaveTimer(RelaySaveTimer&&) = delete;
  943. RelaySaveTimer& operator=(RelaySaveTimer&&) = delete;
  944. ~RelaySaveTimer() {
  945. _timer.stop();
  946. }
  947. void schedule(Duration duration) {
  948. _timer.once(
  949. duration,
  950. [&]() {
  951. _ready = true;
  952. });
  953. }
  954. void stop() {
  955. _timer.stop();
  956. _persist = false;
  957. }
  958. template <typename T>
  959. void process(T&& callback) {
  960. if (_ready) {
  961. callback(_persist);
  962. _persist = false;
  963. _ready = false;
  964. }
  965. }
  966. void persist() {
  967. if (!_persist) {
  968. _persist = true;
  969. }
  970. }
  971. private:
  972. bool _persist { false };
  973. bool _ready { false };
  974. Timer _timer;
  975. };
  976. struct RelayDelayedTimer {
  977. using Timer = espurna::timer::SystemTimer;
  978. using Duration = Timer::Duration;
  979. using Callback = espurna::Callback;
  980. RelayDelayedTimer() = default;
  981. RelayDelayedTimer(const RelayDelayedTimer&) = delete;
  982. RelayDelayedTimer& operator=(const RelayDelayedTimer&) = delete;
  983. RelayDelayedTimer(RelayDelayedTimer&&) = delete;
  984. RelayDelayedTimer& operator=(RelayDelayedTimer&&) = delete;
  985. ~RelayDelayedTimer() {
  986. stop();
  987. }
  988. bool scheduled() const {
  989. return static_cast<bool>(_timer);
  990. }
  991. bool prepared() const {
  992. return !_callback.isEmpty();
  993. }
  994. void prepare(Callback callback) {
  995. _callback = std::move(callback);
  996. }
  997. void schedule(Duration duration) {
  998. if (_callback.isEmpty()) {
  999. return;
  1000. }
  1001. if (duration.count()) {
  1002. _timer.once(
  1003. duration,
  1004. [&]() {
  1005. _ready = true;
  1006. });
  1007. } else {
  1008. _ready = true;
  1009. }
  1010. }
  1011. void stop() {
  1012. _timer.stop();
  1013. _ready = false;
  1014. }
  1015. void process() {
  1016. if (_ready) {
  1017. _callback();
  1018. _ready = false;
  1019. }
  1020. }
  1021. private:
  1022. bool _ready { false };
  1023. Callback _callback;
  1024. Timer _timer;
  1025. };
  1026. using Relays = std::vector<Relay>;
  1027. Relays _relays;
  1028. size_t _relayDummy { 0ul };
  1029. espurna::duration::Milliseconds _relay_flood_window { espurna::relay::flood::build::window() };
  1030. unsigned long _relay_flood_changes { espurna::relay::flood::build::changes() };
  1031. espurna::duration::Milliseconds _relay_delay_interlock;
  1032. RelaySync _relay_sync_mode { RelaySync::None };
  1033. bool _relay_sync_reent { false };
  1034. struct RelaySyncUnlock {
  1035. void push_back(RelayLock lock) {
  1036. _locks.push_back(lock);
  1037. }
  1038. void clear() {
  1039. _locks.clear();
  1040. }
  1041. explicit operator bool() const {
  1042. return _locks.size() > 0;
  1043. }
  1044. template <typename T>
  1045. void operator()(T&& relays) const {
  1046. for (size_t id = 0; id < _locks.size(); ++id) {
  1047. relays[id].lock = _locks[id];
  1048. }
  1049. }
  1050. private:
  1051. std::vector<RelayLock> _locks;
  1052. };
  1053. RelayDelayedTimer _relay_unlock_timer;
  1054. RelaySaveTimer _relay_save_timer;
  1055. std::forward_list<RelayStatusCallback> _relay_status_notify;
  1056. std::forward_list<RelayStatusCallback> _relay_status_change;
  1057. #if WEB_SUPPORT
  1058. bool _relay_report_ws { false };
  1059. void _relayScheduleWsReport() {
  1060. _relay_report_ws = true;
  1061. }
  1062. #endif // WEB_SUPPORT
  1063. #if MQTT_SUPPORT || API_SUPPORT
  1064. String _relay_payload_on;
  1065. String _relay_payload_off;
  1066. String _relay_payload_toggle;
  1067. #endif // MQTT_SUPPORT || API_SUPPORT
  1068. } // namespace
  1069. // -----------------------------------------------------------------------------
  1070. // RELAY PROVIDERS
  1071. // -----------------------------------------------------------------------------
  1072. // 'anchor' default virtual implementations to the relay.cpp.o
  1073. RelayProviderBase::~RelayProviderBase() = default;
  1074. bool RelayProviderBase::setup() {
  1075. return true;
  1076. }
  1077. void RelayProviderBase::boot(bool) {
  1078. }
  1079. void RelayProviderBase::notify(bool) {
  1080. }
  1081. // Direct status notifications
  1082. void relayOnStatusNotify(RelayStatusCallback callback) {
  1083. _relay_status_notify.push_front(callback);
  1084. }
  1085. void relayOnStatusChange(RelayStatusCallback callback) {
  1086. _relay_status_change.push_front(callback);
  1087. }
  1088. namespace {
  1089. // Real GPIO provider, using BasePin interface to implement writers
  1090. struct GpioProvider : public RelayProviderBase {
  1091. GpioProvider(RelayType type, std::unique_ptr<BasePin>&& pin, std::unique_ptr<BasePin>&& reset_pin) :
  1092. _type(type),
  1093. _pin(std::move(pin)),
  1094. _reset_pin(std::move(reset_pin))
  1095. {}
  1096. espurna::StringView id() const override {
  1097. return espurna::relay::settings::options::RelayProviderGpio;
  1098. }
  1099. bool setup() override {
  1100. if (!_pin) {
  1101. return false;
  1102. }
  1103. _pin->pinMode(OUTPUT);
  1104. if (_reset_pin) {
  1105. _reset_pin->pinMode(OUTPUT);
  1106. }
  1107. return true;
  1108. }
  1109. void change(bool status) override {
  1110. switch (_type) {
  1111. case RelayType::Normal:
  1112. _pin->digitalWrite(status);
  1113. break;
  1114. case RelayType::Inverse:
  1115. _pin->digitalWrite(!status);
  1116. break;
  1117. case RelayType::Latched:
  1118. case RelayType::LatchedInverse: {
  1119. bool pulse = (_type == RelayType::Latched) ? HIGH : LOW;
  1120. _pin->digitalWrite(!pulse);
  1121. if (_reset_pin) {
  1122. _reset_pin->digitalWrite(!pulse);
  1123. }
  1124. if (status || (!_reset_pin)) {
  1125. _pin->digitalWrite(pulse);
  1126. } else {
  1127. _reset_pin->digitalWrite(pulse);
  1128. }
  1129. // notice that this stalls loop() execution, since
  1130. // we need to ensure only relay task is active
  1131. espurna::time::blockingDelay(espurna::relay::build::latchingPulse());
  1132. _pin->digitalWrite(!pulse);
  1133. if (_reset_pin) {
  1134. _reset_pin->digitalWrite(!pulse);
  1135. }
  1136. }
  1137. }
  1138. }
  1139. private:
  1140. RelayType _type { RelayType::Normal };
  1141. std::unique_ptr<BasePin> _pin;
  1142. std::unique_ptr<BasePin> _reset_pin;
  1143. };
  1144. #if RELAY_PROVIDER_DUAL_SUPPORT
  1145. // Special provider for Sonoff Dual, using serial protocol
  1146. class DualProvider : public RelayProviderBase {
  1147. public:
  1148. DualProvider() = delete;
  1149. explicit DualProvider(size_t id) : _id(id) {
  1150. _instances.push_back(this);
  1151. }
  1152. ~DualProvider() {
  1153. _instances.erase(
  1154. std::remove(_instances.begin(), _instances.end(), this),
  1155. _instances.end());
  1156. }
  1157. espurna::StringView id() const override {
  1158. return espurna::relay::settings::options::RelayProviderDual;
  1159. }
  1160. bool setup() override {
  1161. static bool once = ([]() {
  1162. const auto port = uartPort(RELAY_PROVIDER_DUAL_PORT - 1);
  1163. if (port) {
  1164. DualProvider::_port = port->stream;
  1165. espurnaRegisterLoop(loop);
  1166. return true;
  1167. }
  1168. return false;
  1169. })();
  1170. return once;
  1171. }
  1172. void change(bool) override {
  1173. espurnaRegisterOnceUnique(flush);
  1174. }
  1175. size_t relayId() const {
  1176. return _id;
  1177. }
  1178. static std::vector<DualProvider*>& instances() {
  1179. return _instances;
  1180. }
  1181. // Porting the old masking code from buttons
  1182. // (no guarantee that this actually works, based on hearsay and some 3rd-party code)
  1183. // | first | second | mask |
  1184. // | OFF | OFF | 0x0 |
  1185. // | ON | OFF | 0x1 |
  1186. // | OFF | ON | 0x2 |
  1187. // | ON | ON | 0x3 |
  1188. // i.e. set status bit mask[INSTANCE] for each relay
  1189. // unless everything is ON, then *only* send mask[SIZE] bit and erase the rest
  1190. static void flush() {
  1191. bool sync { true };
  1192. RelayMaskHelper mask;
  1193. for (size_t index = 0; index < _instances.size(); ++index) {
  1194. bool status { relayStatus(_instances[index]->relayId()) };
  1195. sync = sync && status;
  1196. mask.set(index, status);
  1197. }
  1198. if (sync) {
  1199. mask.reset();
  1200. mask.set(_instances.size(), true);
  1201. }
  1202. DEBUG_MSG_P(PSTR("[RELAY] Sending DUAL mask: %s\n"), mask.toString().c_str());
  1203. uint8_t buffer[4] { 0xa0, 0x04, static_cast<unsigned char>(mask.toUnsigned()), 0xa1 };
  1204. _port->write(buffer, sizeof(buffer));
  1205. _port->flush();
  1206. }
  1207. static void loop() {
  1208. if (_port->available() < 4) {
  1209. return;
  1210. }
  1211. unsigned char bytes[4] = {0};
  1212. _port->readBytes(bytes, 4);
  1213. if ((bytes[0] != 0xA0) && (bytes[1] != 0x04) && (bytes[3] != 0xA1)) {
  1214. return;
  1215. }
  1216. // RELAYs and BUTTONs are synchonized in the SIL F330
  1217. // Make sure we handle SYNC action first
  1218. RelayMaskHelper mask(bytes[2]);
  1219. if (mask[_instances.size()]) {
  1220. for (auto& instance : _instances) {
  1221. relayStatus(instance->relayId(), true);
  1222. }
  1223. return;
  1224. }
  1225. // Then, manage relays individually
  1226. for (size_t index = 0; index < _instances.size(); ++index) {
  1227. relayStatus(_instances[index]->relayId(), mask[index]);
  1228. }
  1229. }
  1230. private:
  1231. size_t _id;
  1232. static std::vector<DualProvider*> _instances;
  1233. static Stream* _port;
  1234. };
  1235. std::vector<DualProvider*> DualProvider::_instances;
  1236. Stream* DualProvider::_port = nullptr;
  1237. #endif // RELAY_PROVIDER_DUAL_SUPPORT
  1238. #if RELAY_PROVIDER_STM_SUPPORT
  1239. // Special provider for ESP01-relays with STM co-MCU driving the relays
  1240. class StmProvider : public RelayProviderBase {
  1241. public:
  1242. StmProvider() = delete;
  1243. explicit StmProvider(size_t id) :
  1244. _id(id)
  1245. {}
  1246. espurna::StringView id() const override {
  1247. return espurna::relay::settings::options::RelayProviderStm;
  1248. }
  1249. bool setup() override {
  1250. static bool once = ([]() {
  1251. const auto port = uartPort(RELAY_PROVIDER_STM_PORT - 1);
  1252. if (port) {
  1253. StmProvider::_port = port->stream;
  1254. espurnaRegisterLoop(loop);
  1255. return true;
  1256. }
  1257. return false;
  1258. })();
  1259. return once;
  1260. }
  1261. void boot(bool) override {
  1262. // XXX: does this actually help with anything? remains as part of the
  1263. // original implementation, quoting "because of broken stm relay firmware"
  1264. _relays[_id].change_delay = espurna::duration::Seconds(3) + espurna::duration::Seconds(1) * _id;
  1265. }
  1266. void change(bool status) override {
  1267. if (_port) {
  1268. _port->flush();
  1269. _port->write(0xA0);
  1270. _port->write(_id + 1);
  1271. _port->write(status);
  1272. _port->write(0xA1 + status + _id);
  1273. // TODO: is this really solved via interlock delay, so we don't have to switch contexts here?
  1274. //delay(100);
  1275. _port->flush();
  1276. }
  1277. }
  1278. private:
  1279. size_t _id;
  1280. static Stream* _port;
  1281. };
  1282. Stream* StmProvider::_port = nullptr;
  1283. #endif // RELAY_PROVIDER_STM_SUPPORT
  1284. // -----------------------------------------------------------------------------
  1285. // UTILITY
  1286. // -----------------------------------------------------------------------------
  1287. bool _relayTryParseId(espurna::StringView value, size_t& id) {
  1288. return tryParseId(value, relayCount(), id);
  1289. }
  1290. [[gnu::unused]]
  1291. bool _relayTryParseIdFromPath(espurna::StringView value, size_t& id) {
  1292. return tryParseIdPath(value, relayCount(), id);
  1293. }
  1294. void _relayHandleStatus(size_t id, PayloadStatus status) {
  1295. switch (status) {
  1296. case PayloadStatus::Off:
  1297. relayStatus(id, false);
  1298. break;
  1299. case PayloadStatus::On:
  1300. relayStatus(id, true);
  1301. break;
  1302. case PayloadStatus::Toggle:
  1303. relayToggle(id);
  1304. break;
  1305. case PayloadStatus::Unknown:
  1306. break;
  1307. }
  1308. }
  1309. [[gnu::unused]]
  1310. bool _relayHandlePayload(size_t id, espurna::StringView payload) {
  1311. const auto status = relayParsePayload(payload);
  1312. if (status != PayloadStatus::Unknown) {
  1313. _relayHandleStatus(id, status);
  1314. return true;
  1315. }
  1316. return false;
  1317. }
  1318. // Initialize pulse timers after ON or OFF event
  1319. // TODO: integrate with scheduled ON or OFF?
  1320. bool _relayPulseActive(size_t id, bool status) {
  1321. using namespace espurna::relay::pulse;
  1322. if (isActive(_relays[id].pulse)) {
  1323. return isNormalStatus(_relays[id].pulse, status);
  1324. }
  1325. return false;
  1326. }
  1327. void _relayProcessActivePulse(const Relay& relay, size_t id, bool status) {
  1328. using namespace espurna::relay::pulse;
  1329. if (isActive(relay.pulse) && !isNormalStatus(relay.pulse, status)) {
  1330. trigger(relay.pulse_time, id, !status);
  1331. }
  1332. }
  1333. // start pulse for the current status as 'target'
  1334. [[gnu::unused]]
  1335. bool _relayHandlePulsePayload(size_t id, espurna::StringView payload) {
  1336. const auto status = relayStatus(id);
  1337. if (_relayPulseActive(id, status)) {
  1338. return false;
  1339. }
  1340. using namespace espurna::relay::pulse::settings;
  1341. const auto pulse = parse_time(payload);
  1342. if (pulse.ok) {
  1343. espurna::relay::pulse::trigger(native_duration(pulse), id, status);
  1344. relayToggle(id, true, false);
  1345. return true;
  1346. }
  1347. return false;
  1348. }
  1349. // Make sure expired pulse timers are removed, so any API calls don't try to re-use those
  1350. void _relayProcessPulse() {
  1351. espurna::relay::pulse::expire();
  1352. }
  1353. [[gnu::unused]]
  1354. PayloadStatus _relayInvertStatus(PayloadStatus status) {
  1355. switch (status) {
  1356. case PayloadStatus::On:
  1357. return PayloadStatus::Off;
  1358. case PayloadStatus::Off:
  1359. return PayloadStatus::On;
  1360. case PayloadStatus::Toggle:
  1361. case PayloadStatus::Unknown:
  1362. break;
  1363. }
  1364. return PayloadStatus::Unknown;
  1365. }
  1366. [[gnu::unused]]
  1367. PayloadStatus _relayPayloadStatus(size_t id) {
  1368. if (id < _relays.size()) {
  1369. return _relays[id].current_status
  1370. ? PayloadStatus::On
  1371. : PayloadStatus::Off;
  1372. }
  1373. return PayloadStatus::Unknown;
  1374. }
  1375. template <typename T>
  1376. T _relayTristateFromPayload(const String& value) {
  1377. return espurna::settings::internal::RelayTristateHelper<T>::convert(value);
  1378. }
  1379. template <typename T>
  1380. String _relayTristateToPayload(T value) {
  1381. return espurna::settings::internal::RelayTristateHelper<T>::serialize(value);
  1382. }
  1383. [[gnu::unused]]
  1384. bool _relayHandleLockPayload(size_t id, espurna::StringView payload) {
  1385. if (id < _relays.size()) {
  1386. const auto status = relayStatusTarget(id);
  1387. if (relayStatus(id) != status) {
  1388. return false;
  1389. }
  1390. const auto lock = _relayTristateFromPayload<RelayLock>(payload.toString());
  1391. _relays[id].lock = lock;
  1392. switch (lock) {
  1393. case RelayLock::None:
  1394. relayStatus(id, status);
  1395. break;
  1396. case RelayLock::Off:
  1397. case RelayLock::On:
  1398. relayStatus(id, (RelayLock::On == lock));
  1399. break;
  1400. }
  1401. return true;
  1402. }
  1403. return false;
  1404. }
  1405. void _relaySyncLockAll() {
  1406. RelaySyncUnlock locks;
  1407. for (auto& relay : _relays) {
  1408. const auto lock = relay.lock;
  1409. locks.push_back(lock);
  1410. if (lock == RelayLock::None) {
  1411. relay.lock = relay.target_status
  1412. ? RelayLock::On
  1413. : RelayLock::Off;
  1414. }
  1415. }
  1416. _relay_unlock_timer.prepare(
  1417. [locks]() {
  1418. locks(_relays);
  1419. #if WEB_SUPPORT
  1420. _relayScheduleWsReport();
  1421. #endif
  1422. });
  1423. }
  1424. bool _relayStatusCheckLock(Relay& relay, bool status) {
  1425. if (relay.lock != RelayLock::None) {
  1426. bool lock = relay.lock == RelayLock::On;
  1427. if ((lock != status) || (lock != relay.target_status)) {
  1428. relay.target_status = lock;
  1429. relay.change_delay = Relay::Delay::zero();
  1430. return false;
  1431. }
  1432. }
  1433. return true;
  1434. }
  1435. // https://github.com/xoseperez/espurna/issues/1510#issuecomment-461894516
  1436. // completely reset timing on the other relay to sync with this one
  1437. // to ensure that they change state sequentially
  1438. void _relaySyncRelaysDelay(size_t first, size_t second) {
  1439. _relays[second].fw_start = _relays[first].change_start;
  1440. _relays[second].fw_count = 1;
  1441. _relays[second].change_delay = std::max({
  1442. _relay_delay_interlock,
  1443. _relays[first].change_delay,
  1444. _relays[second].change_delay
  1445. });
  1446. }
  1447. void _relayPrepareUnlock() {
  1448. if (_relay_unlock_timer.prepared() && !_relay_unlock_timer.scheduled()) {
  1449. bool interlock { false };
  1450. for (const auto& relay : _relays) {
  1451. if (relay.current_status != relay.target_status) {
  1452. return;
  1453. }
  1454. if (relay.current_status) {
  1455. interlock = true;
  1456. }
  1457. }
  1458. _relay_unlock_timer.schedule(
  1459. interlock
  1460. ? _relay_delay_interlock
  1461. : espurna::duration::Milliseconds{0});
  1462. }
  1463. }
  1464. void _relayProcessUnlock() {
  1465. _relay_unlock_timer.process();
  1466. }
  1467. } // namespace
  1468. // -----------------------------------------------------------------------------
  1469. // RELAY
  1470. // -----------------------------------------------------------------------------
  1471. namespace {
  1472. inline RelayMaskHelper _relayMaskRtcmem() {
  1473. return RelayMaskHelper(Rtcmem->relay);
  1474. }
  1475. inline void _relayMaskRtcmem(uint32_t mask) {
  1476. Rtcmem->relay = mask;
  1477. }
  1478. inline void _relayMaskRtcmem(const RelayMaskHelper& mask) {
  1479. _relayMaskRtcmem(mask.toUnsigned());
  1480. }
  1481. } // namespace
  1482. void relayPulse(size_t id, espurna::duration::Milliseconds duration, bool normal) {
  1483. if (id < _relays.size()) {
  1484. relayStatus(id, normal);
  1485. espurna::relay::pulse::trigger(duration, id, !relayStatus(id));
  1486. }
  1487. }
  1488. void relayPulse(size_t id, espurna::duration::Milliseconds duration) {
  1489. relayPulse(id, duration, !relayStatus(id));
  1490. }
  1491. void relayPulse(size_t id) {
  1492. if (id < _relays.size()) {
  1493. espurna::relay::pulse::trigger(_relays[id].pulse_time, id, _relays[id].current_status);
  1494. }
  1495. }
  1496. // -----------------------------------------------------------------------------
  1497. namespace {
  1498. void _relaySync(size_t target) {
  1499. // No sync if none or only one relay
  1500. const auto relays = _relays.size();
  1501. if (relays < 2) {
  1502. return;
  1503. }
  1504. // Only call once when coming from the relayStatus(id, status)
  1505. auto lock = espurna::ReentryLock{ _relay_sync_reent };
  1506. if (!lock) {
  1507. return;
  1508. }
  1509. bool status = _relays[target].target_status;
  1510. switch (_relay_sync_mode) {
  1511. case RelaySync::None:
  1512. break;
  1513. // aka all relays should have the same status
  1514. case RelaySync::All:
  1515. for (size_t id = 0; id < relays; ++id) {
  1516. if (id != target) {
  1517. relayStatus(id, status);
  1518. }
  1519. }
  1520. break;
  1521. // all relays should copy the first relay status
  1522. case RelaySync::First:
  1523. if (target == 0) {
  1524. for (size_t id = 1; id < relays; ++id) {
  1525. relayStatus(id, status);
  1526. }
  1527. }
  1528. break;
  1529. // If any of the 'One' modes and setting ON we should set OFF all the others
  1530. case RelaySync::ZeroOrOne:
  1531. case RelaySync::JustOne:
  1532. if (status) {
  1533. for (size_t id = 0; id < relays; ++id) {
  1534. if (id != target) {
  1535. relayStatus(id, false);
  1536. if (relayStatus(id)) {
  1537. _relaySyncRelaysDelay(id, target);
  1538. }
  1539. }
  1540. }
  1541. // If we only need a single one and setting OFF we should set ON the other one
  1542. } else if (_relay_sync_mode == RelaySync::JustOne) {
  1543. const auto id = (target + 1) % relays;
  1544. _relaySyncRelaysDelay(target, id);
  1545. relayStatus(id, true);
  1546. }
  1547. _relaySyncLockAll();
  1548. break;
  1549. }
  1550. }
  1551. bool _relayStatus(size_t id, bool status, bool report, bool group_report) {
  1552. auto& relay = _relays[id];
  1553. if (!_relayStatusCheckLock(relay, status)) {
  1554. DEBUG_MSG_P(PSTR("[RELAY] #%u is locked to %s\n"),
  1555. id, relay.current_status ? PSTR("ON") : PSTR("OFF"));
  1556. relay.report = true;
  1557. relay.group_report = true;
  1558. return false;
  1559. }
  1560. bool changed { false };
  1561. if (relay.current_status == status) {
  1562. if (relay.target_status != status) {
  1563. DEBUG_MSG_P(PSTR("[RELAY] #%u scheduled change cancelled\n"), id);
  1564. relay.target_status = status;
  1565. relay.report = false;
  1566. relay.group_report = false;
  1567. relay.change_delay = Relay::Delay::zero();
  1568. changed = true;
  1569. }
  1570. relay.provider->notify(status);
  1571. for (auto& notify : _relay_status_notify) {
  1572. notify(id, status);
  1573. }
  1574. espurna::relay::pulse::poll(id, status);
  1575. } else {
  1576. auto current_time = Relay::TimeSource::now();
  1577. auto change_delay = status
  1578. ? relay.delay_on
  1579. : relay.delay_off;
  1580. relay.fw_count++;
  1581. relay.change_start = current_time;
  1582. relay.change_delay = std::max(relay.change_delay, change_delay);
  1583. // If current_time is off-limits the floodWindow...
  1584. const auto fw_diff = current_time - relay.fw_start;
  1585. if (fw_diff > _relay_flood_window) {
  1586. // We reset the floodWindow
  1587. relay.fw_start = current_time;
  1588. relay.fw_count = 1;
  1589. // If current_time is in the floodWindow and there have been too many requests...
  1590. } else if (relay.fw_count >= _relay_flood_changes) {
  1591. // We schedule the changes to the end of the floodWindow
  1592. // unless it's already delayed beyond that point
  1593. relay.change_delay = std::max(change_delay, _relay_flood_window - fw_diff);
  1594. // Another option is to always move it forward, starting from current time
  1595. // relay.fw_start = current_time;
  1596. }
  1597. relay.target_status = status;
  1598. relay.report = report;
  1599. relay.group_report = group_report;
  1600. _relaySync(id);
  1601. changed = true;
  1602. if (relay.change_delay.count()) {
  1603. DEBUG_MSG_P(PSTR("[RELAY] #%u scheduled %s in %u (ms)\n"),
  1604. id, status ? PSTR("ON") : PSTR("OFF"), relay.change_delay.count());
  1605. }
  1606. }
  1607. return changed;
  1608. }
  1609. } // namespace
  1610. bool relayStatus(size_t id, bool status, bool report, bool group_report) {
  1611. if (id < _relays.size()) {
  1612. return _relayStatus(id, status, report, group_report);
  1613. }
  1614. return false;
  1615. }
  1616. bool relayStatus(size_t id, bool status) {
  1617. #if MQTT_SUPPORT
  1618. return relayStatus(id, status, mqttForward(), true);
  1619. #else
  1620. return relayStatus(id, status, false, true);
  1621. #endif
  1622. }
  1623. bool relayStatus(size_t id) {
  1624. if (id < _relays.size()) {
  1625. return _relays[id].current_status;
  1626. }
  1627. return false;
  1628. }
  1629. bool relayStatusTarget(size_t id) {
  1630. if (id >= _relays.size()) return false;
  1631. return _relays[id].target_status;
  1632. }
  1633. namespace {
  1634. RelayMaskHelper _relayMaskCurrent() {
  1635. RelayMaskHelper mask;
  1636. for (size_t id = 0; id < _relays.size(); ++id) {
  1637. mask.set(id, _relays[id].current_status);
  1638. }
  1639. return mask;
  1640. }
  1641. void _relaySave(bool persist) {
  1642. const auto mask = _relayMaskCurrent();
  1643. if (_relays.size() > 1) {
  1644. DEBUG_MSG_P(PSTR("[RELAY] Relay mask: %s\n"), mask.toString().c_str());
  1645. }
  1646. // Persist only to rtcmem, unless requested to save to settings
  1647. _relayMaskRtcmem(mask);
  1648. // The 'persist' flag controls whether we are commiting this change or not.
  1649. // It is useful to set it to 'false' if the relay change triggering the
  1650. // save involves a relay whose boot mode is independent from current mode,
  1651. // thus storing the last relay value is not absolutely necessary.
  1652. // Nevertheless, we store the value in the EEPROM buffer so it will be written
  1653. // on the next commit.
  1654. if (persist) {
  1655. espurna::relay::settings::bootMask(mask);
  1656. eepromCommit(); // TODO: should this respect settings auto-save?
  1657. }
  1658. }
  1659. void _relaySave() {
  1660. _relay_save_timer.process([](bool persist) {
  1661. _relaySave(persist);
  1662. });
  1663. }
  1664. void _relayScheduleSave(size_t id) {
  1665. switch (espurna::relay::settings::bootMode(id)) {
  1666. case RelayBoot::Same:
  1667. case RelayBoot::Toggle:
  1668. _relay_save_timer.persist();
  1669. break;
  1670. case RelayBoot::Off:
  1671. case RelayBoot::On:
  1672. case RelayBoot::LockedOff:
  1673. case RelayBoot::LockedOn:
  1674. break;
  1675. }
  1676. _relay_save_timer.schedule(espurna::relay::build::saveDelay());
  1677. }
  1678. } // namespace
  1679. void relaySave(bool persist) {
  1680. _relaySave(persist);
  1681. }
  1682. void relaySave() {
  1683. _relaySave(false);
  1684. }
  1685. void relayToggle(size_t id, bool report, bool group_report) {
  1686. if (id < _relays.size()) {
  1687. relayStatus(id, !relayStatus(id), report, group_report);
  1688. }
  1689. }
  1690. void relayToggle(size_t id) {
  1691. #if MQTT_SUPPORT
  1692. relayToggle(id, mqttForward(), true);
  1693. #else
  1694. relayToggle(id, false, true);
  1695. #endif
  1696. }
  1697. size_t relayCount() {
  1698. return _relays.size();
  1699. }
  1700. PayloadStatus relayParsePayload(espurna::StringView payload) {
  1701. #if MQTT_SUPPORT || API_SUPPORT
  1702. return rpcParsePayload(
  1703. payload,
  1704. [](espurna::StringView payload) {
  1705. if (payload.equals(_relay_payload_off)) {
  1706. return PayloadStatus::Off;
  1707. } else if (payload.equals(_relay_payload_on)) {
  1708. return PayloadStatus::On;
  1709. } else if (payload.equals(_relay_payload_toggle)) {
  1710. return PayloadStatus::Toggle;
  1711. }
  1712. return PayloadStatus::Unknown;
  1713. });
  1714. #else
  1715. return rpcParsePayload(payload);
  1716. #endif
  1717. }
  1718. namespace {
  1719. void _relaySettingsMigrate(int version) {
  1720. if (version < 5) {
  1721. using namespace espurna::relay::settings;
  1722. // just a rename
  1723. moveSetting("relayDelayInterlock", keys::Interlock);
  1724. // groups use a new set of keys
  1725. #if MQTT_SUPPORT
  1726. for (size_t index = 0; index < RelaysMax; ++index) {
  1727. auto group = getSetting({"mqttGroup", index});
  1728. if (!group.length()) {
  1729. break;
  1730. }
  1731. auto syncKey = espurna::settings::Key(F("mqttGroupSync"), index);
  1732. auto sync = getSetting(syncKey);
  1733. setSetting({keys::TopicSub, index}, group);
  1734. if (sync.length()) {
  1735. if (sync != "2") { // aka RECEIVE_ONLY
  1736. setSetting(keys::TopicMode, sync);
  1737. setSetting(keys::TopicPub, group);
  1738. }
  1739. }
  1740. }
  1741. #endif
  1742. delSettingPrefix({
  1743. STRING_VIEW("mqttGroup"), // migrated to relayTopic
  1744. STRING_VIEW("mqttGroupSync"), // migrated to relayTopic
  1745. STRING_VIEW("relayOnDisc"), // replaced with relayMqttDisc
  1746. STRING_VIEW("relayGPIO"), // avoid depending on migrate module
  1747. STRING_VIEW("relayGpio"), // avoid depending on migrate module
  1748. STRING_VIEW("relayProvider"), // different type
  1749. STRING_VIEW("relayType"), // different type
  1750. });
  1751. delSetting("relays"); // does not do anything
  1752. }
  1753. }
  1754. void _relayBoot(size_t index, const RelayMaskHelper& mask) {
  1755. auto status = false;
  1756. auto lock = RelayLock::None;
  1757. switch (espurna::relay::settings::bootMode(index)) {
  1758. case RelayBoot::Same:
  1759. status = mask[index];
  1760. break;
  1761. case RelayBoot::Toggle:
  1762. status = !mask[index];
  1763. break;
  1764. case RelayBoot::On:
  1765. status = true;
  1766. break;
  1767. case RelayBoot::LockedOn:
  1768. status = true;
  1769. lock = RelayLock::On;
  1770. break;
  1771. case RelayBoot::Off:
  1772. status = false;
  1773. break;
  1774. case RelayBoot::LockedOff:
  1775. status = false;
  1776. lock = RelayLock::Off;
  1777. break;
  1778. }
  1779. auto& relay = _relays[index];
  1780. relay.current_status = !status;
  1781. relay.target_status = status;
  1782. relay.lock = lock;
  1783. relay.change_start = Relay::TimeSource::now();
  1784. relay.change_delay = status
  1785. ? relay.delay_on
  1786. : relay.delay_off;
  1787. relay.provider->boot(status);
  1788. }
  1789. void _relayBootAll() {
  1790. auto mask = rtcmemStatus()
  1791. ? _relayMaskRtcmem()
  1792. : espurna::relay::settings::bootMask();
  1793. bool log { false };
  1794. static RelayMask done;
  1795. const auto relays = _relays.size();
  1796. for (size_t id = 0; id < relays; ++id) {
  1797. if (!done[id]) {
  1798. done.set(id, true);
  1799. _relayBoot(id, mask);
  1800. log = true;
  1801. }
  1802. }
  1803. if (log) {
  1804. DEBUG_MSG_P(PSTR("[RELAY] Number of relays: %u, boot mask: %s\n"),
  1805. relays, mask.toString().c_str());
  1806. }
  1807. }
  1808. void _relayConfigure() {
  1809. for (size_t id = 0; id < _relays.size(); ++id) {
  1810. auto& relay = _relays[id];
  1811. relay.pulse = espurna::relay::pulse::settings::mode(id);
  1812. relay.pulse_time = (relay.pulse != espurna::relay::pulse::Mode::None)
  1813. ? espurna::relay::pulse::settings::time(id)
  1814. : espurna::relay::pulse::Duration::min();
  1815. relay.delay_on = espurna::relay::settings::delayOn(id);
  1816. relay.delay_off = espurna::relay::settings::delayOff(id);
  1817. }
  1818. _relay_flood_window = espurna::relay::flood::settings::window();
  1819. _relay_flood_changes = espurna::relay::flood::settings::changes();
  1820. _relay_delay_interlock = espurna::relay::settings::interlockDelay();
  1821. _relay_sync_mode = espurna::relay::settings::syncMode();
  1822. #if MQTT_SUPPORT || API_SUPPORT
  1823. _relay_payload_on = espurna::relay::settings::payloadOn();
  1824. _relay_payload_off = espurna::relay::settings::payloadOff();
  1825. _relay_payload_toggle = espurna::relay::settings::payloadToggle();
  1826. #endif // MQTT_SUPPORT
  1827. }
  1828. } // namespace
  1829. //------------------------------------------------------------------------------
  1830. // WEBSOCKETS
  1831. //------------------------------------------------------------------------------
  1832. #if WEB_SUPPORT
  1833. namespace {
  1834. bool _relayWebSocketOnKeyCheck(espurna::StringView key, const JsonVariant&) {
  1835. return espurna::settings::query::samePrefix(key, STRING_VIEW("relay"));
  1836. }
  1837. void _relayWebSocketUpdate(JsonObject& root) {
  1838. espurna::web::ws::EnumerablePayload payload{root, STRING_VIEW("relayState")};
  1839. payload(STRING_VIEW("states"), _relays.size(), {
  1840. {STRING_VIEW("status"), [](JsonArray& out, size_t index) {
  1841. out.add(_relays[index].target_status ? 1 : 0);
  1842. }},
  1843. {STRING_VIEW("lock"), [](JsonArray& out, size_t index) {
  1844. out.add(static_cast<uint8_t>(_relays[index].lock));
  1845. }},
  1846. });
  1847. }
  1848. void _relayWebSocketSendRelays(JsonObject& root) {
  1849. if (!_relays.size()) {
  1850. return;
  1851. }
  1852. espurna::web::ws::EnumerableConfig config{root, STRING_VIEW("relayConfig")};
  1853. auto& container = config.root();
  1854. container[F("size")] = _relays.size();
  1855. container[F("start")] = 0;
  1856. config(STRING_VIEW("relays"), _relays.size(),
  1857. espurna::relay::settings::query::IndexedSettings);
  1858. }
  1859. void _relayWebSocketOnVisible(JsonObject& root) {
  1860. const auto relays = _relays.size();
  1861. if (!relays) {
  1862. return;
  1863. }
  1864. if (relays > 1) {
  1865. wsPayloadModule(root, PSTR("multirelay"));
  1866. root[FPSTR(espurna::relay::settings::keys::Sync)] =
  1867. espurna::settings::internal::serialize(espurna::relay::settings::syncMode());
  1868. root[FPSTR(espurna::relay::settings::keys::Interlock)] =
  1869. espurna::relay::settings::interlockDelay().count();
  1870. }
  1871. wsPayloadModule(root, PSTR("relay"));
  1872. }
  1873. void _relayWebSocketOnConnected(JsonObject& root) {
  1874. _relayWebSocketSendRelays(root);
  1875. }
  1876. void _relayWebSocketOnAction(uint32_t, const char* action, JsonObject& data) {
  1877. if (strncmp_P(action, PSTR("relay"), 5) == 0) {
  1878. if (!data.is<size_t>(F("id")) || !data.is<String>(F("status"))) {
  1879. return;
  1880. }
  1881. const auto id = data[F("id")].as<size_t>();
  1882. const auto status = data[F("status")].as<String>();
  1883. _relayHandlePayload(id, status);
  1884. }
  1885. }
  1886. void _relayWsReport() {
  1887. if (_relay_report_ws) {
  1888. wsPost(_relayWebSocketUpdate);
  1889. _relay_report_ws = false;
  1890. }
  1891. }
  1892. } // namespace
  1893. void relaySetupWS() {
  1894. wsRegister()
  1895. .onVisible(_relayWebSocketOnVisible)
  1896. .onConnected(_relayWebSocketOnConnected)
  1897. .onData(_relayWebSocketUpdate)
  1898. .onAction(_relayWebSocketOnAction)
  1899. .onKeyCheck(_relayWebSocketOnKeyCheck);
  1900. }
  1901. #endif // WEB_SUPPORT
  1902. //------------------------------------------------------------------------------
  1903. // REST API
  1904. //------------------------------------------------------------------------------
  1905. #if API_SUPPORT
  1906. namespace {
  1907. template <typename T>
  1908. bool _relayApiTryHandle(ApiRequest& request, T&& callback) {
  1909. const auto param = request.wildcard(0);
  1910. size_t id;
  1911. if (!_relayTryParseId(param, id)) {
  1912. return false;
  1913. }
  1914. return callback(id);
  1915. }
  1916. } // namespace
  1917. void relaySetupAPI() {
  1918. if (!_relays.size()) {
  1919. return;
  1920. }
  1921. apiRegister(F(MQTT_TOPIC_RELAY),
  1922. [](ApiRequest&, JsonObject& root) {
  1923. JsonArray& out = root.createNestedArray("relayStatus");
  1924. for (auto& relay : _relays) {
  1925. out.add(relay.target_status ? 1 : 0);
  1926. }
  1927. return true;
  1928. },
  1929. nullptr
  1930. );
  1931. apiRegister(F(MQTT_TOPIC_RELAY "/+"),
  1932. [](ApiRequest& request) {
  1933. return _relayApiTryHandle(request, [&](size_t id) {
  1934. request.send(String(_relays[id].target_status ? 1 : 0));
  1935. return true;
  1936. });
  1937. },
  1938. [](ApiRequest& request) {
  1939. return _relayApiTryHandle(request, [&](size_t id) {
  1940. return _relayHandlePayload(id, request.param(F("value")));
  1941. });
  1942. }
  1943. );
  1944. apiRegister(F(MQTT_TOPIC_PULSE "/+"),
  1945. [](ApiRequest& request) {
  1946. return _relayApiTryHandle(request, [&](size_t id) {
  1947. using namespace espurna::relay::pulse;
  1948. const auto duration = findDuration(id);
  1949. const auto seconds = std::chrono::duration_cast<Seconds>(duration);
  1950. request.send(String(seconds.count(), 10));
  1951. return true;
  1952. });
  1953. },
  1954. [](ApiRequest& request) {
  1955. return _relayApiTryHandle(request, [&](size_t id) {
  1956. return _relayHandlePulsePayload(id, request.param(F("value")));
  1957. });
  1958. }
  1959. );
  1960. apiRegister(F(MQTT_TOPIC_LOCK "/+"),
  1961. [](ApiRequest& request) {
  1962. return _relayApiTryHandle(request,
  1963. [&](size_t id) {
  1964. request.send(_relayTristateToPayload<RelayLock>(_relays[id].lock));
  1965. return true;
  1966. });
  1967. },
  1968. [](ApiRequest& request) {
  1969. return _relayApiTryHandle(request,
  1970. [&](size_t id) {
  1971. return _relayHandleLockPayload(id, request.param(F("value")));
  1972. });
  1973. }
  1974. );
  1975. }
  1976. #endif // API_SUPPORT
  1977. //------------------------------------------------------------------------------
  1978. // MQTT
  1979. //------------------------------------------------------------------------------
  1980. #if MQTT_SUPPORT || API_SUPPORT
  1981. espurna::StringView relayPayloadOn() {
  1982. return _relay_payload_on;
  1983. }
  1984. espurna::StringView relayPayloadOff() {
  1985. return _relay_payload_off;
  1986. }
  1987. espurna::StringView relayPayloadToggle() {
  1988. return _relay_payload_toggle;
  1989. }
  1990. espurna::StringView relayPayload(PayloadStatus status) {
  1991. switch (status) {
  1992. case PayloadStatus::Off:
  1993. return _relay_payload_off;
  1994. case PayloadStatus::On:
  1995. return _relay_payload_on;
  1996. case PayloadStatus::Toggle:
  1997. return _relay_payload_toggle;
  1998. case PayloadStatus::Unknown:
  1999. break;
  2000. }
  2001. return "";
  2002. }
  2003. #endif // MQTT_SUPPORT || API_SUPPORT
  2004. #if MQTT_SUPPORT
  2005. namespace {
  2006. // TODO: it *will* handle the duplicates, but we waste memory storing them
  2007. // TODO: mqttSubscribe(...) also happens multiple times
  2008. //
  2009. // this is not really an intended use-case though, but it is techically possible...
  2010. struct RelayCustomTopic {
  2011. using Mode = RelayMqttTopicMode;
  2012. RelayCustomTopic() = delete;
  2013. RelayCustomTopic(const RelayCustomTopic&) = delete;
  2014. RelayCustomTopic(RelayCustomTopic&& other) noexcept :
  2015. _id(other._id),
  2016. _topic(std::move(other._topic)),
  2017. _parts(_topic, std::move(other._parts)),
  2018. _mode(other._mode)
  2019. {}
  2020. RelayCustomTopic(size_t id, String topic, Mode mode) :
  2021. _id(id),
  2022. _topic(std::move(topic)),
  2023. _parts(_topic),
  2024. _mode(mode)
  2025. {}
  2026. size_t id() const {
  2027. return _id;
  2028. }
  2029. const char* c_str() const {
  2030. return _topic.c_str();
  2031. }
  2032. const String& topic() const {
  2033. return _topic;
  2034. }
  2035. const PathParts& parts() const {
  2036. return _parts;
  2037. }
  2038. Mode mode() const {
  2039. return _mode;
  2040. }
  2041. bool match(const String& other) const {
  2042. PathParts parts(other);
  2043. return _parts.match(parts);
  2044. }
  2045. bool match(const PathParts& parts) const {
  2046. return _parts.match(parts);
  2047. }
  2048. private:
  2049. size_t _id;
  2050. String _topic;
  2051. PathParts _parts;
  2052. RelayMqttTopicMode _mode;
  2053. };
  2054. std::forward_list<RelayCustomTopic> _relay_custom_topics;
  2055. void _relayMqttSubscribeCustomTopics() {
  2056. const size_t relays { _relays.size() };
  2057. if (!relays) {
  2058. return;
  2059. }
  2060. // TODO: previous version attempted to optimize the settings loop by creating a temporary
  2061. // mapping of {id, topic, mode} from build values and then do settings::foreach with
  2062. // matcher for topic & mode key prefixes. but, that also required parsing of the id,
  2063. // which could be either avoided by creating something like {{key, topic}, {key, mode}} instead,
  2064. // but the tradeoff would be searching that array for each key match. this one is *much* shorter
  2065. _relay_custom_topics.clear();
  2066. for (size_t id = 0; id < relays; ++id) {
  2067. auto subscription = espurna::relay::settings::mqttTopicSub(id);
  2068. if (!subscription.length()) {
  2069. continue;
  2070. }
  2071. auto topic = RelayCustomTopic{
  2072. id, std::move(subscription),
  2073. espurna::relay::settings::mqttTopicMode(id)};
  2074. if (!topic.parts()) {
  2075. continue;
  2076. }
  2077. mqttSubscribeRaw(topic.topic().c_str());
  2078. _relay_custom_topics.emplace_front(std::move(topic));
  2079. }
  2080. }
  2081. void _relayMqttPublishCustomTopic(size_t id) {
  2082. const auto topic = espurna::relay::settings::mqttTopicPub(id);
  2083. if (!topic.length()) {
  2084. return;
  2085. }
  2086. auto status = _relayPayloadStatus(id);
  2087. auto mode = espurna::relay::settings::mqttTopicMode(id);
  2088. if (mode == RelayMqttTopicMode::Inverse) {
  2089. status = _relayInvertStatus(status);
  2090. }
  2091. mqttSendRaw(topic.c_str(), relayPayload(status).begin());
  2092. }
  2093. void _relayMqttReport(size_t id) {
  2094. if (_relays[id].report) {
  2095. _relays[id].report = false;
  2096. mqttSend(MQTT_TOPIC_RELAY, id, relayPayload(_relayPayloadStatus(id)).c_str()); // TODO FIXED LENGTH
  2097. }
  2098. if (_relays[id].group_report) {
  2099. _relays[id].group_report = false;
  2100. _relayMqttPublishCustomTopic(id);
  2101. }
  2102. }
  2103. void _relayMqttReportAll() {
  2104. for (unsigned int id=0; id < _relays.size(); id++) {
  2105. mqttSend(MQTT_TOPIC_RELAY, id, relayPayload(_relayPayloadStatus(id)).c_str()); // TODO FIXED LENGTH
  2106. }
  2107. }
  2108. void _relayMqttReportDescription() {
  2109. static const char Topic[] = MQTT_TOPIC_DESCRIPTION "/" MQTT_TOPIC_RELAY;
  2110. for (size_t id = 0; id < _relays.size(); ++id) {
  2111. const auto name = espurna::relay::settings::name(id);
  2112. if (name.length()) {
  2113. mqttSend(Topic, id, name.c_str());
  2114. }
  2115. }
  2116. }
  2117. } // namespace
  2118. void relayStatusWrap(size_t id, PayloadStatus value, bool is_group_topic) {
  2119. #if MQTT_SUPPORT
  2120. const auto forward = mqttForward();
  2121. #else
  2122. const auto forward = false;
  2123. #endif
  2124. switch (value) {
  2125. case PayloadStatus::Off:
  2126. relayStatus(id, false, forward, !is_group_topic);
  2127. break;
  2128. case PayloadStatus::On:
  2129. relayStatus(id, true, forward, !is_group_topic);
  2130. break;
  2131. case PayloadStatus::Toggle:
  2132. relayToggle(id, true, true);
  2133. break;
  2134. case PayloadStatus::Unknown:
  2135. default:
  2136. _relays[id].report = true;
  2137. _relayMqttReport(id);
  2138. break;
  2139. }
  2140. }
  2141. namespace {
  2142. bool _relayMqttHeartbeat(espurna::heartbeat::Mask mask) {
  2143. if (mask & espurna::heartbeat::Report::Relay) {
  2144. _relayMqttReportAll();
  2145. }
  2146. if (mask & espurna::heartbeat::Report::Description) {
  2147. _relayMqttReportDescription();
  2148. }
  2149. return mqttConnected();
  2150. }
  2151. void _relayMqttHandleCustomTopic(espurna::StringView topic, espurna::StringView payload) {
  2152. PathParts received(topic);
  2153. for (auto& topic : _relay_custom_topics) {
  2154. if (topic.match(received)) {
  2155. auto status = relayParsePayload(payload);
  2156. if (topic.mode() == RelayMqttTopicMode::Inverse) {
  2157. status = _relayInvertStatus(status);
  2158. }
  2159. const auto id = topic.id();
  2160. _relayHandleStatus(id, status);
  2161. _relays[id].group_report = false;
  2162. }
  2163. }
  2164. }
  2165. void _relayMqttHandleDisconnect() {
  2166. using namespace espurna::relay::settings;
  2167. for (size_t id = 0; id < _relays.size(); ++id) {
  2168. _relayHandleStatus(id, mqttDisconnectionStatus(id));
  2169. }
  2170. }
  2171. struct RelayMqttTopicHandler {
  2172. using Handler = bool(*)(size_t, espurna::StringView);
  2173. espurna::StringView topic;
  2174. Handler handler;
  2175. };
  2176. PROGMEM_STRING(MqttTopicRelay, MQTT_TOPIC_RELAY);
  2177. PROGMEM_STRING(MqttTopicPulse, MQTT_TOPIC_PULSE);
  2178. PROGMEM_STRING(MqttTopicLock, MQTT_TOPIC_LOCK);
  2179. static constexpr RelayMqttTopicHandler RelayMqttTopicHandlers[] PROGMEM {
  2180. {MqttTopicRelay, _relayHandlePayload},
  2181. {MqttTopicPulse, _relayHandlePulsePayload},
  2182. {MqttTopicLock, _relayHandleLockPayload},
  2183. };
  2184. } // namespace
  2185. void relayMQTTCallback(unsigned int type, espurna::StringView topic, espurna::StringView payload) {
  2186. static bool connected { false };
  2187. if (!_relays.size()) {
  2188. return;
  2189. }
  2190. if (type == MQTT_CONNECT_EVENT) {
  2191. mqttSubscribe(MQTT_TOPIC_RELAY "/+");
  2192. mqttSubscribe(MQTT_TOPIC_PULSE "/+");
  2193. mqttSubscribe(MQTT_TOPIC_LOCK "/+");
  2194. _relayMqttSubscribeCustomTopics();
  2195. connected = true;
  2196. return;
  2197. }
  2198. if (type == MQTT_MESSAGE_EVENT) {
  2199. const auto t = mqttMagnitude(topic);
  2200. for (const auto pair: RelayMqttTopicHandlers) {
  2201. if (t.startsWith(pair.topic)) {
  2202. size_t id;
  2203. if (!_relayTryParseIdFromPath(t, id)) {
  2204. return;
  2205. }
  2206. pair.handler(id, payload);
  2207. _relays[id].report = mqttForward();
  2208. return;
  2209. }
  2210. }
  2211. _relayMqttHandleCustomTopic(topic, payload);
  2212. return;
  2213. }
  2214. if (type == MQTT_DISCONNECT_EVENT) {
  2215. if (connected) {
  2216. connected = false;
  2217. _relayMqttHandleDisconnect();
  2218. }
  2219. return;
  2220. }
  2221. }
  2222. void relaySetupMQTT() {
  2223. mqttHeartbeat(_relayMqttHeartbeat);
  2224. mqttRegister(relayMQTTCallback);
  2225. }
  2226. #endif
  2227. //------------------------------------------------------------------------------
  2228. // Settings
  2229. //------------------------------------------------------------------------------
  2230. #if TERMINAL_SUPPORT
  2231. namespace {
  2232. using TerminalRelayPrintExtra = void(*)(const Relay&, char* out, size_t size);
  2233. void _relayPrint(Print& out, const Relay& relay, size_t index) {
  2234. const auto provider = relay.provider->id();
  2235. const char* target_status = relay.target_status
  2236. ? PSTR("ON") : PSTR("OFF");
  2237. const char* current_status = relay.current_status
  2238. ? PSTR("ON") : PSTR("OFF");
  2239. const auto lock = _relayTristateToPayload(relay.lock);
  2240. out.printf_P(PSTR("relay%u {Prov=%.*s TargetStatus=%s CurrentStatus=%s Lock=%.*s}\n"),
  2241. index, provider.length(), provider.begin(),
  2242. current_status, target_status,
  2243. lock.length(), lock.c_str());
  2244. }
  2245. void _relayPrint(Print& out, size_t start, size_t stop) {
  2246. for (size_t index = start; index < stop; ++index) {
  2247. _relayPrint(out, _relays[index], index);
  2248. }
  2249. }
  2250. PROGMEM_STRING(RelayCommand, "RELAY");
  2251. static void _relayCommand(::terminal::CommandContext&& ctx) {
  2252. if (ctx.argv.size() == 1) {
  2253. _relayPrint(ctx.output, 0, _relays.size());
  2254. terminalOK(ctx);
  2255. return;
  2256. }
  2257. size_t id;
  2258. if (!_relayTryParseId(ctx.argv[1], id)) {
  2259. terminalError(ctx, F("Invalid relayID"));
  2260. return;
  2261. }
  2262. ctx.output.println(id);
  2263. if (ctx.argv.size() > 2) {
  2264. auto status = relayParsePayload(ctx.argv[2]);
  2265. if (PayloadStatus::Unknown == status) {
  2266. terminalError(ctx, F("Invalid status"));
  2267. return;
  2268. }
  2269. _relayHandleStatus(id, status);
  2270. _relayPrint(ctx.output, _relays[id], id);
  2271. terminalOK(ctx);
  2272. return;
  2273. }
  2274. settingsDump(ctx, espurna::relay::settings::query::IndexedSettings, id);
  2275. terminalOK(ctx);
  2276. }
  2277. PROGMEM_STRING(PulseCommand, "PULSE");
  2278. static void _relayCommandPulse(::terminal::CommandContext&& ctx) {
  2279. if (ctx.argv.size() < 3) {
  2280. terminalError(ctx, F("PULSE <ID> <TIME> [<TOGGLE>]"));
  2281. return;
  2282. }
  2283. size_t id;
  2284. if (!_relayTryParseId(ctx.argv[1], id)) {
  2285. terminalError(ctx, F("Invalid relayID"));
  2286. return;
  2287. }
  2288. const auto time = espurna::relay::pulse::settings::parse_time(ctx.argv[2]);
  2289. if (!time.ok) {
  2290. terminalError(ctx, F("Invalid pulse time"));
  2291. return;
  2292. }
  2293. const auto duration = espurna::relay::pulse::settings::native_duration(time);
  2294. bool toggle = true;
  2295. if (ctx.argv.size() == 4) {
  2296. auto* convert= espurna::settings::internal::convert<bool>;
  2297. toggle = convert(ctx.argv[3]);
  2298. }
  2299. const auto status = relayStatus(id);
  2300. if (toggle && _relayPulseActive(id, status)) {
  2301. terminalError(ctx, F("Pulse already active!"));
  2302. return;
  2303. }
  2304. const auto target = toggle ? status : !status;
  2305. espurna::relay::pulse::trigger(duration, id, target);
  2306. if ((duration.count() > 0) && toggle) {
  2307. relayToggle(id, true, false);
  2308. }
  2309. terminalOK(ctx);
  2310. }
  2311. PROGMEM_STRING(LockCommand, "LOCK");
  2312. static void _relayCommandLock(::terminal::CommandContext&& ctx) {
  2313. if ((ctx.argv.size() != 2) && (ctx.argv.size() != 3)) {
  2314. terminalError(ctx, F("LOCK <ID> [<TARGET>]"));
  2315. return;
  2316. }
  2317. size_t id;
  2318. if (!_relayTryParseId(ctx.argv[1], id)) {
  2319. terminalError(ctx, F("Invalid relayID"));
  2320. return;
  2321. }
  2322. const auto status = relayStatus(id);
  2323. if (relayStatusTarget(id) != status) {
  2324. terminalError(ctx, F("Relay change in-progress"));
  2325. return;
  2326. }
  2327. auto lock = (status) ? RelayLock::On : RelayLock::Off;
  2328. if (ctx.argv.size() == 3) {
  2329. lock = _relayTristateFromPayload<RelayLock>(ctx.argv[2]);
  2330. }
  2331. _relays[id].lock = lock;
  2332. switch (lock) {
  2333. case RelayLock::None:
  2334. relayStatus(id, status);
  2335. break;
  2336. case RelayLock::Off:
  2337. case RelayLock::On:
  2338. relayStatus(id, (RelayLock::On == lock));
  2339. break;
  2340. }
  2341. terminalOK(ctx);
  2342. }
  2343. PROGMEM_STRING(UnlockCommand, "UNLOCK");
  2344. static void _relayCommandUnlock(::terminal::CommandContext&& ctx) {
  2345. if (ctx.argv.size() != 2) {
  2346. terminalError(ctx, F("UNLOCK <ID>"));
  2347. return;
  2348. }
  2349. size_t id;
  2350. if (!_relayTryParseId(ctx.argv[1], id)) {
  2351. terminalError(ctx, F("Invalid relayID"));
  2352. return;
  2353. }
  2354. const auto status = relayStatus(id);
  2355. if (relayStatusTarget(id) != status) {
  2356. terminalError(ctx, F("Relay change in-progress"));
  2357. return;
  2358. }
  2359. _relays[id].lock = RelayLock::None;
  2360. relayStatus(id, status);
  2361. terminalOK(ctx);
  2362. }
  2363. static constexpr ::terminal::Command RelayCommands[] PROGMEM {
  2364. {RelayCommand, _relayCommand},
  2365. {PulseCommand, _relayCommandPulse},
  2366. {LockCommand, _relayCommandLock},
  2367. {UnlockCommand, _relayCommandUnlock},
  2368. };
  2369. void _relayCommandsSetup() {
  2370. espurna::terminal::add(RelayCommands);
  2371. }
  2372. } // namespace
  2373. #endif // TERMINAL_SUPPORT
  2374. //------------------------------------------------------------------------------
  2375. namespace {
  2376. void _relayReport(size_t id [[gnu::unused]], bool status [[gnu::unused]]) {
  2377. for (auto& change : _relay_status_change) {
  2378. change(id, status);
  2379. }
  2380. #if MQTT_SUPPORT
  2381. _relayMqttReport(id);
  2382. #endif
  2383. #if WEB_SUPPORT
  2384. _relayScheduleWsReport();
  2385. #endif
  2386. }
  2387. void _relayReport() {
  2388. #if WEB_SUPPORT
  2389. _relayWsReport();
  2390. #endif
  2391. }
  2392. /**
  2393. * Walks the relay vector processing only those relays
  2394. * that have to change to the requested mode
  2395. * @bool mode Requested mode
  2396. */
  2397. bool _relayProcess(bool mode) {
  2398. const auto relays = _relays.size();
  2399. bool changed { false };
  2400. for (size_t id = 0; id < relays; ++id) {
  2401. // Only process the relays:
  2402. // - target mode in the one requested by the arg
  2403. // - target status is different from the current one
  2404. // - change delay has expired
  2405. const bool target { _relays[id].target_status };
  2406. if ((target != _relays[id].current_status)
  2407. && (target == mode)
  2408. && ((!_relays[id].change_delay.count())
  2409. || (Relay::TimeSource::now() - _relays[id].change_start > _relays[id].change_delay)))
  2410. {
  2411. // delay will be reset back to the correct value via relayStatus
  2412. _relays[id].change_delay = Relay::Delay::zero();
  2413. _relays[id].current_status = target;
  2414. _relays[id].provider->change(target);
  2415. _relayReport(id, target);
  2416. // try to immediately schedule 'normal' state
  2417. _relayProcessActivePulse(_relays[id], id, target);
  2418. // and make sure relay values are persisted in RAM and flash
  2419. _relayScheduleSave(id);
  2420. changed = true;
  2421. DEBUG_MSG_P(PSTR("[RELAY] #%u set to %s\n"), id, target ? "ON" : "OFF");
  2422. }
  2423. }
  2424. return changed;
  2425. }
  2426. } // namespace
  2427. //------------------------------------------------------------------------------
  2428. // Setup
  2429. //------------------------------------------------------------------------------
  2430. namespace {
  2431. void _relayLoop() {
  2432. const bool changed[] {
  2433. _relayProcess(false),
  2434. _relayProcess(true),
  2435. };
  2436. if (changed[0] || changed[1]) {
  2437. _relayProcessPulse();
  2438. _relayPrepareUnlock();
  2439. }
  2440. _relayProcessUnlock();
  2441. _relayReport();
  2442. _relaySave();
  2443. }
  2444. } // namespace
  2445. // Dummy relays for virtual light switches (hardware-less), Sonoff Dual, Sonoff RF Bridge and Tuya
  2446. void relaySetupDummy(size_t size, bool reconfigure) {
  2447. if (size == _relayDummy) {
  2448. return;
  2449. }
  2450. const size_t new_size = ((_relays.size() - _relayDummy) + size);
  2451. if (new_size > RelaysMax) {
  2452. return;
  2453. }
  2454. _relayDummy = size;
  2455. _relays.resize(new_size);
  2456. if (reconfigure) {
  2457. _relayConfigure();
  2458. }
  2459. }
  2460. namespace {
  2461. constexpr size_t _relayAdhocPins() {
  2462. return 0
  2463. #if RELAY1_PIN != GPIO_NONE
  2464. + 1
  2465. #endif
  2466. #if RELAY2_PIN != GPIO_NONE
  2467. + 1
  2468. #endif
  2469. #if RELAY3_PIN != GPIO_NONE
  2470. + 1
  2471. #endif
  2472. #if RELAY4_PIN != GPIO_NONE
  2473. + 1
  2474. #endif
  2475. #if RELAY5_PIN != GPIO_NONE
  2476. + 1
  2477. #endif
  2478. #if RELAY6_PIN != GPIO_NONE
  2479. + 1
  2480. #endif
  2481. #if RELAY7_PIN != GPIO_NONE
  2482. + 1
  2483. #endif
  2484. #if RELAY8_PIN != GPIO_NONE
  2485. + 1
  2486. #endif
  2487. ;
  2488. }
  2489. struct RelayGpioProviderCfg {
  2490. GpioType type;
  2491. uint8_t main;
  2492. uint8_t reset;
  2493. };
  2494. RelayGpioProviderCfg _relayGpioProviderCfg(size_t index) {
  2495. return RelayGpioProviderCfg{
  2496. .type = espurna::relay::settings::pinType(index),
  2497. .main = espurna::relay::settings::pin(index),
  2498. .reset = espurna::relay::settings::resetPin(index),
  2499. };
  2500. }
  2501. std::unique_ptr<GpioProvider> _relayGpioProvider(size_t index, RelayType type) {
  2502. const auto cfg = _relayGpioProviderCfg(index);
  2503. auto* base = gpioBase(cfg.type);
  2504. if (!base) {
  2505. return nullptr;
  2506. }
  2507. auto main = gpioRegister(*base, cfg.main);
  2508. if (!main) {
  2509. return nullptr;
  2510. }
  2511. auto reset = gpioRegister(*base, cfg.reset);
  2512. if (GpioType::Hardware == cfg.type) {
  2513. hardwareGpioIgnore(cfg.main);
  2514. if (GPIO_NONE != cfg.reset) {
  2515. hardwareGpioIgnore(cfg.reset);
  2516. }
  2517. }
  2518. return std::make_unique<GpioProvider>(
  2519. type, std::move(main), std::move(reset));
  2520. }
  2521. RelayProviderBasePtr _relaySetupProvider(size_t index) {
  2522. auto provider = espurna::relay::settings::provider(index);
  2523. auto type = espurna::relay::settings::type(index);
  2524. RelayProviderBasePtr result;
  2525. switch (provider) {
  2526. case RelayProvider::Dummy:
  2527. result = std::make_unique<DummyProvider>();
  2528. break;
  2529. case RelayProvider::Gpio:
  2530. result = _relayGpioProvider(index, type);
  2531. break;
  2532. case RelayProvider::Stm:
  2533. #if RELAY_PROVIDER_STM_SUPPORT
  2534. result = std::make_unique<StmProvider>(index);
  2535. #endif
  2536. break;
  2537. case RelayProvider::Dual:
  2538. #if RELAY_PROVIDER_DUAL_SUPPORT
  2539. result = std::make_unique<DualProvider>(index);
  2540. #endif
  2541. break;
  2542. case RelayProvider::LightState:
  2543. #if LIGHT_PROVIDER != LIGHT_PROVIDER_NONE
  2544. result = lightMakeStateRelayProvider(index);
  2545. #endif
  2546. break;
  2547. case RelayProvider::Fan:
  2548. #if FAN_SUPPORT
  2549. result = fanMakeRelayProvider(index);
  2550. #endif
  2551. break;
  2552. case RelayProvider::Lightfox:
  2553. #ifdef FOXEL_LIGHTFOX_DUAL
  2554. result = lightfoxMakeRelayProvider(index);
  2555. #endif
  2556. break;
  2557. case RelayProvider::Tuya:
  2558. #if TUYA_SUPPORT
  2559. result = tuya::makeRelayProvider(index);
  2560. #endif
  2561. break;
  2562. case RelayProvider::None:
  2563. break;
  2564. }
  2565. return result;
  2566. }
  2567. void _relaySetup() {
  2568. auto relays = _relays.size();
  2569. _relays.reserve(relays + _relayAdhocPins());
  2570. for (size_t id = relays; id < RelaysMax; ++id) {
  2571. auto impl = _relaySetupProvider(id);
  2572. if (!impl) {
  2573. break;
  2574. }
  2575. if (!impl->setup()) {
  2576. break;
  2577. }
  2578. _relays.emplace_back(std::move(impl));
  2579. }
  2580. relaySetupDummy(espurna::relay::settings::dummyCount());
  2581. }
  2582. } // namespace
  2583. namespace espurna {
  2584. namespace relay {
  2585. namespace settings {
  2586. namespace query {
  2587. namespace {
  2588. bool checkSamePrefix(StringView key) {
  2589. PROGMEM_STRING(Prefix, "relay");
  2590. return espurna::settings::query::samePrefix(key, Prefix);
  2591. }
  2592. String findIndexedValueFrom(StringView key) {
  2593. return espurna::settings::query::IndexedSetting::findValueFrom(_relays.size(), IndexedSettings, key);
  2594. }
  2595. bool checkExact(StringView key) {
  2596. for (const auto& setting : Settings) {
  2597. if (key == setting.key()) {
  2598. return true;
  2599. }
  2600. }
  2601. return false;
  2602. }
  2603. String findValueFrom(StringView key) {
  2604. return espurna::settings::query::Setting::findValueFrom(Settings, key);
  2605. }
  2606. void setup() {
  2607. ::settingsRegisterQueryHandler({
  2608. .check = checkSamePrefix,
  2609. .get = findIndexedValueFrom
  2610. });
  2611. ::settingsRegisterQueryHandler({
  2612. .check = checkExact,
  2613. .get = findValueFrom
  2614. });
  2615. }
  2616. } // namespace
  2617. } // namespace query
  2618. } // namespace settings
  2619. } // namespace relay
  2620. } // namespace espurna
  2621. void relaySetup() {
  2622. migrateVersion(_relaySettingsMigrate);
  2623. _relaySetup();
  2624. espurna::relay::settings::query::setup();
  2625. _relayConfigure();
  2626. _relayBootAll();
  2627. _relayLoop();
  2628. #if WEB_SUPPORT
  2629. relaySetupWS();
  2630. #endif
  2631. #if API_SUPPORT
  2632. relaySetupAPI();
  2633. #endif
  2634. #if MQTT_SUPPORT
  2635. relaySetupMQTT();
  2636. #endif
  2637. #if TERMINAL_SUPPORT
  2638. _relayCommandsSetup();
  2639. #endif
  2640. // Main callbacks
  2641. espurnaRegisterLoop(_relayLoop);
  2642. espurnaRegisterReload(_relayConfigure);
  2643. }
  2644. RelayAddResult relayAdd(RelayProviderBasePtr&& provider) {
  2645. RelayAddResult out;
  2646. const auto id = _relays.size();
  2647. if (espurna::relay::settings::provider(id) != RelayProvider::None) {
  2648. return out;
  2649. }
  2650. if (!provider) {
  2651. return out;
  2652. }
  2653. if (!provider->setup()) {
  2654. return out;
  2655. }
  2656. out.id = id;
  2657. _relays.emplace_back(std::move(provider));
  2658. espurnaRegisterOnceUnique([]() {
  2659. _relayConfigure();
  2660. _relayBootAll();
  2661. });
  2662. return out;
  2663. }
  2664. #endif // RELAY_SUPPORT == 1