Logging, trend log, resident scripts... best practices

[npinguin]

Just wanted to start a thread to see what the best practices are regarding everything that is resource hungry because I am starting to hit limits with my old LM reactor v2

Here is what I currently do

scripts
- event handling scripts are with me mainly tagged scripts where I map based on configuration the corresponding actions. Simple loop over the config and then perform the corresponding action, like that I do not have to write x scripts for simular or related functionalities
- in the scripts I use cached information as much as possible in the order GRP objects first then storage
- resident scripts take care of the hot caching of various external IP interfaces. Here I probably create a part of my resource issue, because the intervals are sometimes to aggressive 

I see lots of scripts using
  require('genohm-scada.eibdgm')
  client = eibdgm:new({ timeout = 0.25 })
  clientethandler('groupwrite', eventhandler)

as I do not find the proper documentation/explaination I do not use it, what are the benefits of using this client mechanism ? memory consumption ? thread usage ?


trends, object logs, logs
- Trends I use trends for 10-20 objects for which i need history over long period and graphs
- log/alert/ ... I do this all over the place but typically I add an if (debug) then ... arround it to log only during development and when done disable it

Is there a better way to handle logging in scripts, the scripts get cluttered with if then else and it takes time. Is there something like log4j, log.debug, log.error, log.info with filtering based on config  

- object logs I thought I did not use, only for some debugging, but seems that I had 10-20 setup.

Is there a link between the trends and the object logs ? if i disable the logs of the objects, do the trends still work ?

storage vs, grp objects, vs virtual objects
- if it needs to be visualized or handled on the bus I use grp objects, where I use virtual group adresses when it is only for virtualization (typically these are txt messages with a particular formatting / mask)
- if it is needed for configuration, handling logic with interfaces or states I use storage objects. probabaly another source of my resource limitation, because I do not filter the information that much that i need to cache the status of the interfaces

bus communication
- only publish information on the bus with changes grp.checkwrite / grp.checkupdate

BUT there is a bug/limitation grp.checkwrite/ grp.checkupdate. currently this only supports booleans and uint, not text, .. does the new firmware support all data types ?

background processes, resident vs scheduled vs init scripts
- i mainly use resident scripts where I cache the state in storage using variables like lastrun timestamp to determine when to handle the logic again
- probably I should make some scripts scheduled or init scripts

  
Anyone else ready to share their best practices and give feedback on my way of working and questions above ?

Thanks
Nicky

[admin]

1. Local bus monitoring is recommended way for resident scripts which have to work with many objects at once. Otherwise you need to use polling which increases delays and add extra CPU load.

2. You can create some wrappers around log() in common functions so you can enable/disable it globally when needed.

3. Object logs have no connection to trends. Trends use the current value from each object.

4. Latest FW has support for strings in grp.checkwrite / grp.checkupdate.

Anwyay it's hard to give some advice without any particular details

[npinguin]

Thanks
That gives some pointers, i think it would be nice to have some more best practices/example to incourage developing

[legolas2069]

2. You can create some wrappers around log() in common functions so you can enable/disable it globally when needed.

Can you explain a little bit more this point?

ty

[admin]

Add this to common functions:

Code:

local current_log_level = 0 -- adjust as needed

function log_level(level, ...)
  if current_log_level >= level then
    log(...)
  end
end

Then specify log level as first argument to log_level() function and use it the same as standard log(). The only limitation is that this approach will not work for resident scripts as common functions library is loaded only once when script starts.

[legolas2069]

Add this to common functions:

Code:

local current_log_level = 0 -- adjust as needed

function log_level(level, ...)
 if current_log_level >= level then
   log(...)
 end
end

Then specify log level as first argument to log_level() function and use it the same as standard log(). The only limitation is that this approach will not work for resident scripts as common functions library is loaded only once when script starts.

Thanks admin