Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

rule cannot be processed because of uninitialized script #3131

Open
maglnet opened this issue Mar 9, 2017 · 7 comments
Open

rule cannot be processed because of uninitialized script #3131

maglnet opened this issue Mar 9, 2017 · 7 comments
Labels

Comments

@maglnet
Copy link

maglnet commented Mar 9, 2017

Hello,

I sometimes (about 25%-50% of restarts) experience the following log messages at startup:

2017-03-07 21:48:19.057 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model '_default.rules'
2017-03-07 21:48:28.091 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Public Holiday': Script 'holiday' cannot be found.
2017-03-07 21:48:28.335 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'holiday.script'

my rule:

rule "Public Holiday"
when
    Time cron "0 0 0 * * ?" or
    System started
then
    callScript("holiday")
end

When the log message appears the holidays wont be calculated at startup, at midnight the script is called normally and holidays are calculated.

I feel like scripts should be loaded prior the rules?

I'm running openHAB 2.1.0-SNAPSHOT Build #816 on a RaspberryPI 3.

best regards,
Matthias

@kaikreuzer
Copy link
Contributor

Yes, the "System started" trigger is indeed not reliable for such cases - I assume we would first need #1896 to find the right moment when everything is up and fully loaded...

@maglnet
Copy link
Author

maglnet commented Mar 15, 2017

Thank you for your response.
What would be the way to go?

I'll try to add the calculated Items to persistence / restoreOnStartup and call the script after a delay of one minute, that should be enough, imho.

I'll give feedback in some days if my idea works :)

@maglnet
Copy link
Author

maglnet commented Mar 16, 2017

The following seems to work for now (restarted about 10 times, no Warning appeared):

rule "Public Holiday"
when
    Time cron "0 0 0 * * ?" or
    System started
then
    createTimer(now.plusSeconds(15)) [|
        callScript("holiday")
    ]
end

@kaikreuzer
Copy link
Contributor

Sounds like a viable workaround.

@DriesA
Copy link

DriesA commented Nov 22, 2017

Hi,
I have a similar issue.

Sometimes (in 10% of the cases), my rules are even triggered before all my items are loaded. Then I get something like this in my log:
2017-11-19 22:22:26.696 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'some.rules' 2017-11-19 22:22:30.524 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Some rule': The name 'someItem' cannot be resolved to an item or type; line 286, column 8, length 35 2017-11-19 22:22:35.540 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'some.items'

On top of that, many of my rules are triggered because of restoreOnStartup. I would expect items to be restored, and after that rules are initialized.

I think it makes sense that the following sequence is applied during the start of OH:

  • Load all things & items;
  • Load persistence strategies and perform restoreOnStartup;
  • Load rules;
  • Load sitemaps;

Link to Community topic:
https://community.openhab.org/t/keep-when-item-received-update-rules-from-running-during-restoreonstartup/

@kaikreuzer
Copy link
Contributor

Makes sense. Note that we can only reliably guarantee such an order once #1896 is solved.

@lsiepel
Copy link

lsiepel commented Aug 22, 2018

I experience similair problems. And the logs shows the rules are read (and executed) before the item and script files. I also read #1896 discussion. While one could make it as complex as possible, wouldn't it be a first step to trigger the system started event after all userdata was loaded?
After the discuission in #1896 evolves, that trigger/state could also be update to incorperate all the services ready, handler available or whatever is decided to be a good moment to start the rules.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants