My current project consists of current OpenHAB, Javascript classes via GraalVM / node.js and one JSRule. I started with a JSRule being triggered every few seconds due to a changed number item.
Now the project grows and ok, I initially learned to apply JSRule and have a regular call to my Javascript objects and do something with them.
But, would it be a good idea to have my Javascript class method call only once while starting OpenHAB and do the rest inside with loops/etc., so I can avoid these periodic rule triggers? The items are still accessible and it´s not a big thing to periodically loop through my items and do some stuff / logic inside.
I´d see an advantage, because all the triggers would be avoided and overlapping method calls could be avoided. The program workflow would be in the hands of my nodes.js module. Don´t know how to explain better.
Currently, programming is still based on a JSRule, using openhab-js caching the object.
Not sure, if that approach is thought till the end and foreseen in nodes.js or OpenHAB might be slowed down?
It’s a little hard to tell based on the description what you have done. It kind of sounds like instead of creating separate rules triggered by events you’ve built a whole separate framework and all that The OH rule does is kick off your framework.
I would recommend changing your approach to one of the following:
Skip JS Rule entirely. Create a separate Node.js program that runs outside of OH and interact with OH through the REST API and websocket. GraalVM JS doesn’t provide a pure and complete Node.js environment which, if you are not going to write rules as expected, might proove limiting.
Take advantage of how OH is designed and optimized to work. Having that rule trigger like that for every change is by design. OH is an event driven platform. When X happens do Y. If that’s too fast you can add a condition to the rule to only run the logic if the Item changed above a certain amount, or you can use a profile to only update the Item when it changes above a certain amount.
What you are proposing is to essentially “break” the event driven nature of OH and turn it into a polling architecture. Polling is almost always a worse approach compared to event driven. However, there are times where your have no choice. In those cases, on a car by case basis, you can use a cron trigger for that one rule so it periodically polls instead of triggering based on events.
That’s a side effect of the way you’ve built your rules. OH expects reach rule to be it’s own independent thing. But you are sharing an object accross all rules where the actual implementation of your rules reside instead of improrting a library into each individual rule and only using cache for those rare cases where multiple roles need to share data. I would totally expect this to cause problems (e.g. multi threaded access exceptions, GraalVM JS doesn’t all multi threaded access to Object and a good deal of work has been put into the rules engine to prevent that by default).
It sounds like you are trying to work around this problem which only makes my recommendation to do one of the two options above even stronger.
If you don’t want to be limited by GraalVM and have a pure Node.js environment, get outside of OH and user the API instead (this is how HABApp works). If you do want to stay inside of OH, you need to rethink your approach. Instead of a shared Object where all your actual rules logic resides,
code that only belongs to one rule goes in that one rule
code shared across multiple rules goes in a node module imported using require
Data shared between rules are a signal that perhaps those rules need to be combined. But in those rare cases where it is needed, separate the data into separate entries in the cache to avoid potential multi access problems. Or consider using Items instead.
Tl;Dr, your approach is unexpected and suboptimal for use in OH. You should change your approach to take your rules outside of OH or change to work more like OH expects.
Finally I’ll mention that CPU almost never matters in a home automation context. Don’t worry about that unless and until you know you have a performance problem.
What you wrote is quite helpful and expressed my issue.
I´ll give the API a try to better evaluate, if what I have can be moved to a reasonable compromise or the box of pandora opened up.
Thanks a lot
