Homey script cards getting unavailable &

While making homey scripting, I face every 15min (same as calculation cycle) “script-app not avail.”, “Card unavailable” and also below on main screen… all scripts working wo issue, Memory & CPU OK and all back normal after this (expect that I need to initialize again _.codes before next usage (Setting Logic Variable by HomeyScript - #53 by Eko_taas)

Just to be on safe side: anything to worry about and if yes, where to keep eye on? if needed, I could e.g. add delays on more complex ( / unoptimized :grimacing: ) calculation as these not in a hurry…

This what I can see on “Devices”-view in root zone
image
while CPU trend looks from same slot like (50% max, but assuming smoothened…):
image

Sounds like the Homeyscript app is either crashing or it’s being stopped because it’s taking up too much memory.

Yes, seems like optimization of code really needed :face_with_monocle:
image

meanwhile, quick-fix for to see what happens :slight_smile:

No help on quick-fix, App not restarting automatically, even if crashed… seems that needs to simplify approach…

The best way to deal with this is to prevent the app from getting killed.

Was bit hard to find “trouble maker” (with my newbee skills).

Finally this one did the trick (disabled all new coded and enabled one by one to see the one killing me):


(also here, restart will never tricker, but App seems to restart automatically within appr, 2min)

To close the loop just in case someone will face similar issue… I simplified codes, but seems still too much for HomeyScript.

When testing deeper, found very (?) strange behavior:

  • HomeyScript collapse always say 10sec later when code executed
  • I can execute same code many times (when in same flow) (say runtime 30+sec) and again after HomeyScript drops.
    -If I added App-restart to the end of flow, takes hardly 1s to restart (automatic takes around 1.5min)

As set of scripts are calculated every 15min, I made single main flow which is calling all (heavy) sub-flows (challenging ones called several times)
image

Even with overall runtime 38sec (when all executed), looks now more simple also for system-view: