This is one of the most important features of this firmware. The presence of scripts allows you to implement almost any application in automation, taking into account the hardware available on board.
Possible implementation network scenarioswhich further expands the application of the firmware.
Before going directly to the description of scenarios, we emphasize once again that the IoTmanager system event-based and all actions in it, except for the routine ones, are performed by the system based on events.
General principle of scripting:
if "some event" then "we did something";
or
if "some event" then "we did something"; else if "some event" then "we did something";
In scenarios, you can use sensor data, variables, Gpio status (pins), and functions.
Sample scenario: if btn==1 then led=1;
- The comparison uses the operator ==, in the assignment =
- The script always ends ;
- Possible comparisons: equal to ==, not equal to !=, greater than or equal to >= , less than or equal to <=, more >, less than <
- Simple math is possible *, /, —, +. When using math, separate characters with spaces.
- Double, triple or more conditions are possible And (&), OR (|) for example if btn1 == 1 & btn2 == 1 & var_bin == 7 then pump0_out = 1,
if n100s1 | n101s1 then log1 = n100s1/2 + n101s1/2; - In the executive part, it is possible to perform several actions concluded in the following order: {} For example if btn1 == 1 then {var_pump0 = 1; led = 1;}
(commands can be separated by a space, semicolon, and the beginning of another definition)
Another example:
if t
btn1 = 1 — btn1;
// button inversion var = var + 1;
if var == 112 then var = 109;
}
- You can use an asterisk(*) in comparisons to exclude a numeric character from the comparison, which means any character in place of*.
Usage example, Turn on btn12 and the LED indicator every 10 minutes in the interval from 8 to 23 hours.:
if timer_l==0&getHours() > 07&getHours() <23&gethhmm() == «**:*1» then {btn12= 1; led=1;}
Turn it off after 2 minutes
if timer_l==0&getHours() > 07&getHours() <23&gethhmm() == «**:*3» then {btn12 = 0; led = 0;}
The following commands will return the correct value if the time is received from the Internet or RTC (in development), otherwise while zeros
getHours(); - get the current number of hours.
getMinutes(); - get the current number of minutes.
getSeconds(); - get the current number of seconds.
getMonth(); - get the current month's number.
getDay(); - get the number of the current day of the month.
gethhmm(); - get a string like hh: mm.
gethhmmss(); - get a string like hh:mm:ss.
getTime(); — get a string like dd. mm. yy hh:mm:ss
getUptime(); - get a string like dd. mm. yy hh:mm:ss about the system's uptime
!!! Important: at the moment, we can use time in scripts and create flexible configurations and schedules based on it.
However !!! The arrival of time itself is not an event that we can use with confidence if. The occurrence of time itself does not generate an event.
Therefore, to compare the time, we use a timer as an event generator. For example, a looped minute timer.
Therefore, time events always look like this if timer_l==0&getHours() > 07 then ...
For convenience, you can use comments in scripts, everything that comes after the sign. # it will be ignored.
if timer0 == 0 then btn1 = 1 # Enable after the timer runs out.
Changing the sensor state is also an event. This allows you to respond to changes in readings. For example, your sensor is polled every 5 seconds. This design will allow you to track changes and respond to them, and even perform the simplest math with readings.:
If sensor then data = sensor*5;
if data > limit then out1 = 1;
Error handling
The modules (not all of them yet, the old ones need to be updated) have an algorithm for generating errors in case of incorrect actions. For example, the lack of sensor data. If necessary, you can handle and use this error. An error is an element id_onError, where id this is our element.
Error handling differs on the local device, where the sensor is directly connected, and on the remote device, which receives data from the sensor over the network (global and network data reception is enabled)
Case on a local device:
if temp-the temperature sensor sent data other than zero ( the event is true). Data polling can be treated as an error if no data is available.
if temp_onError — an error occurred inside the module during measurement. We didn't get the temperature. This may be due to the lack of a module or its malfunction, frequent polling, etc.
A case on a remote device: (For more information, see about network scenarios)
if the temp element exists, it means that it sent data other than zero ( the event is true)
if temp_onError-the sensor didn't send the event in time
Still unprocessed information from Ilya Belyakov
Added the ability to concatenate strings, including numbers, in the script. You need to test it.
Now you can use the following constructs::
if btn == 1 then { var2 = «/pic» + var1 + «.jpg»; var1 = var1 + 1;}
You can view examples of scenarios in a special section of our website of the channel