Issue of the topic: I need to check status of devices at startup to be able to display the status correctly. My rule receives this “Validation” error when I use HTTPGET as noted below.
rule "Startup"
when
System started
then
var GarageDoorMiddleStatus value = sendHttpGetRequest("http://192.168.1.23/device/status")
I also tried using response instead of value
String GarageDoorMiddleStatus "Middle Door Status [%s]" <garagedoor>
2020-03-29 20:01:10.183 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'GarageDoor.rules', using it anyway:
Any help on how to debug or examples or the correction is greatly appreciated.
Look at the log statement again. Firstly it’s an “INFO” level log statement. This is an informational level log statement. Errors will be logged at the ERROR level. Something that isn’t an error but is a little off would be logged at the WARN level. Also look at what the statment actually says. “using it anyway”. So what ever it found was not severe enough to keep OH from parsing and configuring the Rules to actually run.
Unfortunately you cut off the log statement. Usually after the “…anyway:” there is a new line and a sentence telling you what the validation error is. This error should also show up in VSCode.
The only thing obvious about your rule is there is not end.
My issue is the get value is not returned to the GarageDoorMiddleStatus but the same statement in Postman does return the value. I
VScode says
GarageDoorEastStatus cannot be resolved to a type. (org.eclipse.xtext.diagnostics.Diagnostic.Linking) {8,9]
The value of the local variable value is not used
After shutdown and restart logfile adds this message
2020-03-31 15:58:06.238 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Startup': Couldn't invoke 'assignValueTo' for feature JvmVoid: (eProxyURI: GarageDoor.rules#|::0.2.0.2.0.1::0::/1)your code goes here
and VScode says
This expression is not allowed in this context, since it doesn't cause any side effects.
The method value(String) is undefined
I rechecked the log (below) and there isn’t any further info in the log. I confirmed the “get” was the cause by commenting that line and then restarting the Pi.
2020-03-31 14:54:45.085 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Garage.items'
2020-03-31 14:54:50.427 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'GarageDoor.rules', using it anyway:
2020-03-31 14:54:50.435 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'GarageDoor.rules'
I think the key is the rule thinks that GarageDoorMiddleStatus is a local variable and is not using the string defined in the item file.
Switch GarageDoorMiddleActivate "Activate Middle Door [%s] <switch>"
String GarageDoorMiddleStatus "Middle Door Status [%s]" <garagedoor> //<<<<<
Switch GarageDoorEastActivate "Activate Middle Door [%s] <switch>"
because when the rule is stated as
val GarageDoorMiddleStatus = sendHttpGetRequest("http://192.168.1.23/device/status")
the result in VSC and the log is
2020-03-31 16:43:08.389 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'GarageDoor.rules', using it anyway:
The value of the local variable GarageDoorMiddleStatus is not used
Regardless of whether any Item exists with that name, that statement creates a new variable.
For the duration of the following code block, all references to that name will get the variable, not the Item.
Apparently there are in fact no further references to that name, so the results are never used.
It’s just a dumb machine and doing what it is told.
The way to update an Item’s state is with postUpdate, method or action.
I strongly recommend you do a bit more work here though;
Use a timeout with the http request
Check to see if the results are null before posting to your Item
Thank you rossko57. I made that change and made some progress but still have major reliability issues. Seems that each time I restart the OH 2.5.3 I have a very good chance of getting different errors. It started fine yesterday after making the changes you reccomended but due to inconsistencies I had encounter yesterday I decided to try several start stops and the first scenario being to stop OH, clear the cache, shutdown the Pi and even the AlarmDecoder attached and restart all. This resulted in a
I see a post from 2018 that this can be the result of rules being activated before the items are all processed and as these fields are asked for On Start - I am guessing but think this is an issue for OH? In that post it was said that the Devs are working on sequencing the startup process but that is a while ago.
I repeated the shutdown and restart and the items were loaded. but I got this error
I think the answer is that if I feel a need to clear the cache then I need to start, stop, restart again but would prefer that there was a way to convince OH to complete all the items files before going on to the rules. Any ideas?
There is no way to define what order OH loads text based config files. There are things you can do outside of OH such as move the .rules files out of the rules folder until enough time has passed for everything else to be loaded and then moved them back. openHABian has an option to implement this inside it’s menu structure somewhere.
There is a known bug that hopefully will not be a problem any more or will be fixed in OH 3 where after clearing the cache some Items are simply not loaded. A second and sometime more restarts after first coming back online after a clear the cache corrects the problem. NOTE: an upgrade will perform a clear the cache so you should most often encounter this error on an upgrade.
You should almost never need to clear the cache manually. It is done far to frequently to attempt to solve problems that are completely unrelated to the cache or can be solved in a less disruptive way. One should only clear the cache if there is behavior that looks like it might be corrected by reinstalling all the bindings (that’s basically what clear the cache does). And it should only be done after doing less disruptive corrective stuff like restarting the binding, restarting OH, resetting the config files, etc.
