Crash_Override/ESP32_ChinaDieselHeater_Control
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update JSON dictionary

Ray Jones 2019-03-06 07:44:20 +00:00
parent 9c30cf4919
commit 2889c08b41
1 changed files with 8 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
JSON-dictionary.md

@ -54,16 +54,19 @@ Certain commands are used to alter the non volatile settings stored by the contr
## Notes on timer commands ## Notes on timer commands
Up to 14 timers are allowed by the ESP32 firmware. Up to 14 timers are allowed by the ESP32 firmware.
There are however only simple JSON names used, with being adorned with numerics. There are however only simple JSON names used, not being adorned with numerics.
This is mainly done to better support App Inventor and the Bluetooth app when decoding received JSON names. The timer associated in the command is instead sent as the first numeric in the Value field. This is mainly done to better support App Inventor and the Bluetooth app when decoding received JSON names. The timer associated in the command is instead identified as the first numeric in the following string Value field.
eg: {"TimerStart":"**XX** HH:MM}, _where XX is the timer identifier_
The Names for the 14 timers are TimerStart, TimerStop, TimerRepeat & TimerDays. The common Names used for the 14 timer parameter sets are TimerStart, TimerStop, TimerRepeat & TimerDays.
A couple of extra commands are used to validate the timer programming, guarding against conflicts. A couple of extra commands are used to validate the timer programming, guarding against conflicts.
TimerConflict & TimerRefresh. TimerConflict & TimerRefresh.
After defining a new timer definition, TimerConflict is sent from a JSON client, the Value being the new timer we wish to test against all others. If the times and days of the nominated timer conflict with any other timer, the ESP32 will send back TimerConflict, this time with the Value being the detected timer that is conflict. After defining and sending a new timer definition, TimerConflict must be sent from a JSON client, the Value being the new timer we have defined and need to test against all others.
If a conflict does occur, the nominated timer is disabled by the ESP32 - removing the immediate conflict without changing the times chosen. The timer can then be revised. If the times and days of the nominated timer conflict with any other timer, the ESP32 will send back TimerConflict, this time with the Value being the detected timer that is conflict.
If a conflict does occur, the nominated timer is disabled by the ESP32 - removing the immediate conflict without changing the times chosen. The timer can then be revised by the client.
Likewise, the changed Timer status will be reflected back to the client via JSON as well. Likewise, the changed Timer status will be reflected back to the client via JSON as well.
TimerRefresh is used to request a complete update of the timer information by a client, or by the ESP32 to say it has delivered all the timer information. The client can use this JSON message to only update the GUI etc once, not upon every element being sent! TimerRefresh is used to request a complete update of the timer information by a client, or by the ESP32 to say it has delivered all the timer information. The client can use this JSON message to only update the GUI etc once, not upon every element being sent!