from the “sendTelegram” statement in the following rule;
rule "test rule Temp"
when
Item TTNseawTemp received update
then
var DateTimeType prevOnState = TTNseawTemp_LastUpdate.state as DateTimeType
var int execDurationMin = (Seconds::secondsBetween(new DateTime(prevOnState.calendar.timeInMillis), now ).getSeconds()) / 60
postUpdate(TTNseawTemp_MinBetweenReadings, execDurationMin)
postUpdate(TTNseawTemp_LastUpdate, new DateTimeType())
sendTelegram("bot1", "Temp from Temp Sensor received: %s - %.0f minutes since last reading", TTNseawTemp.state, execDurationMin)
end
I can see that it has something to do with the mapping of the int variable - and I have tried %d and %s as well as %.0f - but nothing works. If I just put in TTNseawTemp_MinBetweenReadings.state instead of execDurationMin - it will give me the value from the last update of that item - like it didnt yet register the updated value.
What am I doing wrong in using the locally declared var/val in the sendTelegram statement ?
Not that there is anything wrong with how you are putting the numbers together, but if you’d like to prepare for OH 3.0 (no Joda), you could use ZoneDateTime and ChronoUnit.
import java.time.temporal.ChronoUnit
...
val prevOnState = TTNseawTemp_LastUpdate.getStateAs(DateTimeType).zonedDateTime.until((new DateTimeType).zonedDateTime, ChronoUnit.MINUTES)
That’s normal enough. postUpdate (and sendCommand) are asynchronous; the directive whirls away onto to openHAB event bus to possibly trigger other rules, bindings etc., and eventually to update the Item itself. That takes a few milliseconds and your rule does not stop and wait for it to complete.
There’s no need, you already know what you sent.
Clearly a floating point format like %.0f isn’t going to work on an integer.
I think I’d tackle it a different way, and avoid the primitive int altogether. Also, I’m not sure if the action supports two objects to format.
