mh
/
mhsw-espurna
1
0
Fork 0
Code Releases 0 Activity
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.
3069 Commits
18 Branches
212 MiB
Tree: 774a73d1d4
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '774a73d1d4'
${ noResults }
mhsw-espurna/code/test/platformio.ini

20 lines
415 B
Raw Normal View History

Add TUYA_SUPPORT (#1997) - add experimental `relayDummy` to configure dummy relays at runtime - add tuya-generic-dimmer #1729 - cleanup broker interface to allow Tuya module to properly receive events, modify broker methods to allow different function signatures - add basic tests for Tuya frame and data protocol
5 years ago
​
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
Add TUYA_SUPPORT (#1997) - add experimental `relayDummy` to configure dummy relays at runtime - add tuya-generic-dimmer #1729 - cleanup broker interface to allow Tuya module to properly receive events, modify broker methods to allow different function signatures - add basic tests for Tuya frame and data protocol
5 years ago
​
​
​
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
​
​
​
Add TUYA_SUPPORT (#1997) - add experimental `relayDummy` to configure dummy relays at runtime - add tuya-generic-dimmer #1729 - cleanup broker interface to allow Tuya module to properly receive events, modify broker methods to allow different function signatures - add basic tests for Tuya frame and data protocol
5 years ago
​
ci: run pio test directory
4 years ago
Add TUYA_SUPPORT (#1997) - add experimental `relayDummy` to configure dummy relays at runtime - add tuya-generic-dimmer #1729 - cleanup broker interface to allow Tuya module to properly receive events, modify broker methods to allow different function signatures - add basic tests for Tuya frame and data protocol
5 years ago
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
​
ci: run pio test directory
4 years ago
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
Add TUYA_SUPPORT (#1997) - add experimental `relayDummy` to configure dummy relays at runtime - add tuya-generic-dimmer #1729 - cleanup broker interface to allow Tuya module to properly receive events, modify broker methods to allow different function signatures - add basic tests for Tuya frame and data protocol
5 years ago
 
  1. [platformio]
  2. test_dir = unit
  3. src_dir = ../espurna
  4. 

  5. [env:test]
  6. platform = native
  7. lib_compat_mode = off
  8. test_build_project_src = true
  9. src_filter =
  10.     +<../espurna/terminal_commands.cpp>
  11.     +<../espurna/terminal_parsing.cpp>
  12. lib_deps =
  13.     StreamString
  14.     https://github.com/bxparks/UnixHostDuino#d740398e
  15. build_flags =
  16.     -DMANUFACTURER="PLATFORMIO"
  17.     -DDEVICE="TEST"
  18.     -std=gnu++11
  19.     -Os
  20.     -I../espurna/