Fork of the espurna firmware for `mhsw` switches
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.

191 lines
6.2 KiB

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. */
  4. #pragma once
  5. #include "espurna.h"
  6. constexpr double _relayPulseTime(unsigned char index) {
  7. return (
  8. (index == 0) ? RELAY1_PULSE_TIME :
  9. (index == 1) ? RELAY2_PULSE_TIME :
  10. (index == 2) ? RELAY3_PULSE_TIME :
  11. (index == 3) ? RELAY4_PULSE_TIME :
  12. (index == 4) ? RELAY5_PULSE_TIME :
  13. (index == 5) ? RELAY6_PULSE_TIME :
  14. (index == 6) ? RELAY7_PULSE_TIME :
  15. (index == 7) ? RELAY8_PULSE_TIME : RELAY_PULSE_TIME
  16. );
  17. }
  18. constexpr RelayPulse _relayPulseMode(unsigned char index) {
  19. return (
  20. (index == 0) ? RELAY1_PULSE_MODE :
  21. (index == 1) ? RELAY2_PULSE_MODE :
  22. (index == 2) ? RELAY3_PULSE_MODE :
  23. (index == 3) ? RELAY4_PULSE_MODE :
  24. (index == 4) ? RELAY5_PULSE_MODE :
  25. (index == 5) ? RELAY6_PULSE_MODE :
  26. (index == 6) ? RELAY7_PULSE_MODE :
  27. (index == 7) ? RELAY8_PULSE_MODE : RELAY_PULSE_NONE
  28. );
  29. }
  30. constexpr unsigned long _relayDelayOn(unsigned char index) {
  31. return (
  32. (index == 0) ? RELAY1_DELAY_ON :
  33. (index == 1) ? RELAY2_DELAY_ON :
  34. (index == 2) ? RELAY3_DELAY_ON :
  35. (index == 3) ? RELAY4_DELAY_ON :
  36. (index == 4) ? RELAY5_DELAY_ON :
  37. (index == 5) ? RELAY6_DELAY_ON :
  38. (index == 6) ? RELAY7_DELAY_ON :
  39. (index == 7) ? RELAY8_DELAY_ON : 0
  40. );
  41. }
  42. constexpr unsigned long _relayDelayOff(unsigned char index) {
  43. return (
  44. (index == 0) ? RELAY1_DELAY_OFF :
  45. (index == 1) ? RELAY2_DELAY_OFF :
  46. (index == 2) ? RELAY3_DELAY_OFF :
  47. (index == 3) ? RELAY4_DELAY_OFF :
  48. (index == 4) ? RELAY5_DELAY_OFF :
  49. (index == 5) ? RELAY6_DELAY_OFF :
  50. (index == 6) ? RELAY7_DELAY_OFF :
  51. (index == 7) ? RELAY8_DELAY_OFF : 0
  52. );
  53. }
  54. constexpr unsigned char _relayPin(unsigned char index) {
  55. return (
  56. (index == 0) ? RELAY1_PIN :
  57. (index == 1) ? RELAY2_PIN :
  58. (index == 2) ? RELAY3_PIN :
  59. (index == 3) ? RELAY4_PIN :
  60. (index == 4) ? RELAY5_PIN :
  61. (index == 5) ? RELAY6_PIN :
  62. (index == 6) ? RELAY7_PIN :
  63. (index == 7) ? RELAY8_PIN : GPIO_NONE
  64. );
  65. }
  66. constexpr RelayType _relayType(unsigned char index) {
  67. return (
  68. (index == 0) ? RELAY1_TYPE :
  69. (index == 1) ? RELAY2_TYPE :
  70. (index == 2) ? RELAY3_TYPE :
  71. (index == 3) ? RELAY4_TYPE :
  72. (index == 4) ? RELAY5_TYPE :
  73. (index == 5) ? RELAY6_TYPE :
  74. (index == 6) ? RELAY7_TYPE :
  75. (index == 7) ? RELAY8_TYPE : RELAY_TYPE_NORMAL
  76. );
  77. }
  78. constexpr GpioType _relayPinType(unsigned char index) {
  79. return (
  80. (index == 0) ? RELAY1_PIN_TYPE :
  81. (index == 1) ? RELAY2_PIN_TYPE :
  82. (index == 2) ? RELAY3_PIN_TYPE :
  83. (index == 3) ? RELAY4_PIN_TYPE :
  84. (index == 4) ? RELAY5_PIN_TYPE :
  85. (index == 5) ? RELAY6_PIN_TYPE :
  86. (index == 6) ? RELAY7_PIN_TYPE :
  87. (index == 7) ? RELAY8_PIN_TYPE : GPIO_TYPE_NONE
  88. );
  89. }
  90. constexpr unsigned char _relayResetPin(unsigned char index) {
  91. return (
  92. (index == 0) ? RELAY1_RESET_PIN :
  93. (index == 1) ? RELAY2_RESET_PIN :
  94. (index == 2) ? RELAY3_RESET_PIN :
  95. (index == 3) ? RELAY4_RESET_PIN :
  96. (index == 4) ? RELAY5_RESET_PIN :
  97. (index == 5) ? RELAY6_RESET_PIN :
  98. (index == 6) ? RELAY7_RESET_PIN :
  99. (index == 7) ? RELAY8_RESET_PIN : GPIO_NONE
  100. );
  101. }
  102. constexpr int _relayBootMode(unsigned char index) {
  103. return (
  104. (index == 0) ? RELAY1_BOOT_MODE :
  105. (index == 1) ? RELAY2_BOOT_MODE :
  106. (index == 2) ? RELAY3_BOOT_MODE :
  107. (index == 3) ? RELAY4_BOOT_MODE :
  108. (index == 4) ? RELAY5_BOOT_MODE :
  109. (index == 5) ? RELAY6_BOOT_MODE :
  110. (index == 6) ? RELAY7_BOOT_MODE :
  111. (index == 7) ? RELAY8_BOOT_MODE : GPIO_NONE
  112. );
  113. }
  114. constexpr RelayProvider _relayProvider(unsigned char index) {
  115. return (
  116. (index == 0) ? (RELAY1_PROVIDER) :
  117. (index == 1) ? (RELAY2_PROVIDER) :
  118. (index == 2) ? (RELAY3_PROVIDER) :
  119. (index == 3) ? (RELAY4_PROVIDER) :
  120. (index == 4) ? (RELAY5_PROVIDER) :
  121. (index == 5) ? (RELAY6_PROVIDER) :
  122. (index == 6) ? (RELAY7_PROVIDER) :
  123. (index == 7) ? (RELAY8_PROVIDER) : RELAY_PROVIDER_NONE
  124. );
  125. }
  126. constexpr RelayMqttTopicMode _relayMqttTopicMode(unsigned char index) {
  127. return (
  128. (index == 0) ? (RELAY1_MQTT_TOPIC_MODE) :
  129. (index == 1) ? (RELAY2_MQTT_TOPIC_MODE) :
  130. (index == 2) ? (RELAY3_MQTT_TOPIC_MODE) :
  131. (index == 3) ? (RELAY4_MQTT_TOPIC_MODE) :
  132. (index == 4) ? (RELAY5_MQTT_TOPIC_MODE) :
  133. (index == 5) ? (RELAY6_MQTT_TOPIC_MODE) :
  134. (index == 6) ? (RELAY7_MQTT_TOPIC_MODE) :
  135. (index == 7) ? (RELAY8_MQTT_TOPIC_MODE) : RELAY_MQTT_TOPIC_MODE
  136. );
  137. }
  138. constexpr const char* _relayMqttTopicSub(unsigned char index) {
  139. return (
  140. (index == 0) ? (RELAY1_MQTT_TOPIC_SUB) :
  141. (index == 1) ? (RELAY2_MQTT_TOPIC_SUB) :
  142. (index == 2) ? (RELAY3_MQTT_TOPIC_SUB) :
  143. (index == 3) ? (RELAY4_MQTT_TOPIC_SUB) :
  144. (index == 4) ? (RELAY5_MQTT_TOPIC_SUB) :
  145. (index == 5) ? (RELAY6_MQTT_TOPIC_SUB) :
  146. (index == 6) ? (RELAY7_MQTT_TOPIC_SUB) :
  147. (index == 7) ? (RELAY8_MQTT_TOPIC_SUB) : ""
  148. );
  149. }
  150. constexpr const char* _relayMqttTopicPub(unsigned char index) {
  151. return (
  152. (index == 0) ? (RELAY1_MQTT_TOPIC_PUB) :
  153. (index == 1) ? (RELAY2_MQTT_TOPIC_PUB) :
  154. (index == 2) ? (RELAY3_MQTT_TOPIC_PUB) :
  155. (index == 3) ? (RELAY4_MQTT_TOPIC_PUB) :
  156. (index == 4) ? (RELAY5_MQTT_TOPIC_PUB) :
  157. (index == 5) ? (RELAY6_MQTT_TOPIC_PUB) :
  158. (index == 6) ? (RELAY7_MQTT_TOPIC_PUB) :
  159. (index == 7) ? (RELAY8_MQTT_TOPIC_PUB) : ""
  160. );
  161. }
  162. constexpr PayloadStatus _relayMqttDisconnectionStatus(unsigned char index) {
  163. return (
  164. (index == 0) ? (RELAY1_MQTT_DISCONNECT_STATUS) :
  165. (index == 1) ? (RELAY2_MQTT_DISCONNECT_STATUS) :
  166. (index == 2) ? (RELAY3_MQTT_DISCONNECT_STATUS) :
  167. (index == 3) ? (RELAY4_MQTT_DISCONNECT_STATUS) :
  168. (index == 4) ? (RELAY5_MQTT_DISCONNECT_STATUS) :
  169. (index == 5) ? (RELAY6_MQTT_DISCONNECT_STATUS) :
  170. (index == 6) ? (RELAY7_MQTT_DISCONNECT_STATUS) :
  171. (index == 7) ? (RELAY8_MQTT_DISCONNECT_STATUS) : RELAY_MQTT_DISCONNECT_NONE
  172. );
  173. }