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 })
client
ethandler('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
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 })
client
ethandler('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