I’m completely lost with a simple rule and especially with the return behavior…
I read out my solar converter with SBFspot and try to devide the result string into the relevant values:
import java.util.concurrent.locks.ReentrantLock
var ReentrantLock lock = new ReentrantLock()
rule "SBFspot"
when
Time cron "0,30,45,15 * * * * ?"
then
lock.lock()
try
{
var String raw_output = executeCommandLine("/usr/local/bin/sbfspot.3/SBFspot -v -finq -nocsv -nosql",10000)
var lines = raw_output.split('\n')
logInfo("Exit at", "1")
var V_EToday = lines.get(39).split(': ').get(1).split('kW').get(0)
logInfo("Exit at", "2")
var V_ETotal = lines.get(40).split(': ').get(1).split('kW').get(0)
logInfo("Exit at", "3")
var V_EAct = lines.get(52).split(': ').get(1).split('k').get(0)
logInfo("Exit at", "4")
PV_EAct.postUpdate(V_EAct)
PV_ETotal.postUpdate(V_ETotal)
PV_EToday.postUpdate(V_EToday)
}
finally{
lock.unlock()
}
end
Nothing special and in principal it works… but it figured out, that not all values are updated and the rule does not be executed until the last command. The log looks like:
Looking at timings, the rule is sometimes getting lost in/before the first lines.get()
Maybe the preceding executeCommandLine() doesn’t always return what you expect. I would add a report logInfo of the number of text lines as well. You might need to do something else if you don’t have 40 lines.
Why are you using a ReentrantLock for a cron triggered rule?
I strongly recommend against the use of locks unless you are absolutely certain that you have a problem caused by multiple changes being made to the same resource from multiple rules running at the same time. And even then I recommend reconsidering your architecture or approach to not need the lock.
To start, get rid of the lock.
I agree with rossko57, the most likely problem is the output is not what you think it is every time you execute that script. Either there are not 39 lines of text or there are no ‘:’ or the like and the best way to solve something like that is to actually log raw_output.
Seems that the root cause is the mysterious “Error 1” in the rule. Has anybody an translation for the that error codes? And what’s about the error in line 3:
“Configuration model ‘pv.rules’ is either empty or cannot be parsed correctly!”
Are you accessing/saving your rules file over a Samba share? That could cause this error.
I have a similar rule that parses data, but I use grep for it. This approach should work even if the data format is inconsistent. Hopefully this doesn’t muddy things up worse for you!
@5iver
Yes, I use Samba to access the openhab config stuff on my RP. I tried to create a new rule file directly and this doesn’t lead to the error log message - so I will ignore that message in the future.
Secondly I tried out your grep stuff - not easy for me as grep-Newby
Your rule lead to the following error:
Early bird debugging
Your right, the <<< operator was the problem. Your last proposal without seems to work fine. I let it run during the day and report you later.
