This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm that you accept these cookies being set.

Logging, trend log, resident scripts... best practices
#1
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 })
  clientConfusedethandler('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
Reply


Messages In This Thread
Logging, trend log, resident scripts... best practices - by npinguin - 02.09.2018, 10:57

Forum Jump: