Unfortunately I’m at work and outbound ssh is verboten.
Yes, only the first letter should have been capitalized.
If I could change one thing in openHAB it would be to have errors that are more meaningful and point you at exactly the line that failed.
Gah! I’m missing the opening quote on the logInfo. Oh wherefore art thou Designer. If I had ssh I could get to my machine and at least catch these stupid typos.
logInfo("GenUpTime", "Adding current time to total: timeSinceLastUpdate = " + timeSinceLastUpdate + " oldVal = " + oldVal)
2015-10-20 17:45:44.204 [ERROR] [.o.m.r.i.engine.ExecuteRuleJob] - Error during the execution of rule Increment Generator Runtimes
java.lang.RuntimeException: The name 'java' cannot be resolved to an item or type.
And this is the full script:
var org.joda.time.DateTime whenStarted = null
rule "Generator started"
when
Item Generator received command ON
then
whenStarted = now
end
rule "Generator stopped"
when
Item Generator received command OFF
then
if(whenStarted != null) {
// do the same as the if(Generator.state == ON && whenStarted != null) in the increment rule
}
whenStarted = null
end
rule "Increment Generator Runtimes"
when
Time cron "* */1 * * * ?"
then
if(Generator.state == ON && whenStarted != null){
logInfo("GenUptime", "Getting now")
val long nowMsec = now.millis
logInfo("GenUptime", "Getting whenStarted")
val long wsMsec = whenStarted.millis
logInfo("GenUptime", "Resetting whenStarted")
whenStarted = now
logInfo("GenUptime", "Calculating time difference")
val long timeSinceLastUpdate = nowMsec - wsMsec
logInfo("GenUptime", "Getting total Uptime in msec")
val long oldVal = if(GeneratorRuntimeMSec.state == Undefined || GeneratorRuntimeMSec.state == Uninitialized) 0 else (GeneratorRuntimeMSec.state as Number).longValue
logInfo("GenUpTime", "Adding current time to total: timeSinceLastUpdate = " + timeSinceLastUpdate + " oldVal = " + oldVal)
val long totalMsec = oldVal + timeSinceLastUpdate // calculate total runtime<F2>
logInfo("GenUptime", "Posting totalMsec to Item")
GeneratorRuntimeMSec.postUpdate(totalMsec) // post the full runtime
logInfo("GenUptime", "Calculating hours")
val long hours = java.lang.Math.round(totalMsec/1000/60/60)
logInfo("GenUptime", "Posting hours")
GeneratorRuntimeHours.postUpdate(hours)
}
else if(Generator.state == ON && whenStarted == null){
logInfo("GenUptime", "Generator is ON but Generator started rule never executed")
whenStarted = now
}
else {
logInfo("GenUptime", "Generator is not running")
}
end
I simply add that at the top of the .rules right? As soon as I do that it looks like the rule stops running. I no longer see the:
2015-10-21 10:09:04.339 [INFO ] [openhab.model.script.GenUptime] - Generator is not running
2015-10-21 10:09:05.000 [INFO ] [openhab.model.script.GenUptime] - Generator is not running
If I edit the rule and take out the import line I start seeing the not running lines in logs.
Dealing with decimal points on computers is surprisingly challenging. Most people don’t realize that computers are really horrible at doing decimal math.
This little trick will work most of the time:
val long temp = Math::round((totalMSec/100/60/60) * 10) // calculate the hours and move the decimal place before rounding to preserve the tenths place
val double hours = temp / 10.0 // move the decimal place back to get the tenth's place, change the type to double so we don't lose the decimal place
Because computers are really bad at representing floating point numbers, there may be cases where you end up with something like “5.1000000000000005” instead of “5.1”. I don’t think it will occur frequently, but if it does the “fix” will be a little more tricky and involved.
However, it is better to not round at all and use the formatting on the labeltext for the Item to only show one decimal place.
Awesome thread guys. Bookmarked for the day I have an automatic start/stop generator!
I have done remote site generator monitoring and something that does tend to come up (in many areas in fact) is drift between the generators hour meter and the calculated values from the controller. If you are storing/persisting the total run hours, and you have a means of updating that counter, you can periodically do a manual meter read and update the system with the “correct” value from the generator.
Another though, which is much simpler, but requires more storage, is just to store the current generator state every minute (or 5,10,15 minutes) as well as the run hours. This way it is really easy to just sum the run time between a start and end point in order to see how long the generator ran during that period.
There is always more than one way to solve a problem. I’m glad you posted this alternative method.
I think the big differences between the two approaches is when you do the math to come up with the total hours. Our approach does the math as values come up. Your approach does the math only when you look. Both have their place.