Primary EVA CLI tools are eva (./bin/eva) and eva-shell (./bin/eva -I or ./bin/eva-shell). Actually it’s a same program, which automatically starts itself in interactive mode (-I) when called as eva-shell and without any argument.
If command “uc”, “lm” or “sfa” is called without arguments, EVA shell will launch corresponding controller sub-shell, which’s equal to calling uc-cmd, lm-cmd and sfa-cmd directly.
You can execute a pack of several commands at once, separating them with “;” symbol, just like in a system shell:
state -p sensor ; state -p unit
The next very useful trick is command repeating. In real life, there’s a lot of examples, when you mount / setup some equipment and need to check its state every second to get the moment it start working correctly. To repeat the command in EVA shell , symbol “|” (pipe) is used
EVA ICS doesn’t use thread pools in core, number of threads is always fixed (except LM PLC macros), grows together with node configuration, and should be controlled by system administrator/integrator. Majority threads “sleep” until they get an event and don’t produce additional load.
After controller start, core launches several system threads (garbage collectors etc.), plus threads for each item:
Two update threads (update scheduler + update processor) per each unit, sensor and lvar
One action thread per each unit
Two update threads for PHI module, if loaded with update=X parameter
One notification queue thread for each notifier
One thread for UC UDP API, one thread for UC SNMP trap handler (if enabled).
LM PLC launches a single thread which handles queue for scheduled macro exections. After the execution, each macro has its own thread, number of threads for macros isn’t limited by PLC.
Also, each LM PLC logic cycle has own thread as well
If MQTT transport is used for API calls between nodes – one thread per API call (max lifetime = server.timeout)