Millis in mapdb?

Setup, Configuration and Use Scripts & Rules
1

After getting it up and running with only minor bumps on the way, I noticed a huge flaw. (This might also be due to my inability to configure it better but nevertheless it worked flawlessly in the previous version).

I have a gateway picking up my 433 MHz remotes and spitting them onto mqtt. The remotes I’m using put out a command more than once per second. As I use these commands to trigger several lights, and it is unnecessary to toggle them more than once per (half) a second, I used the following rule (partly shown)

if (gateway_ReceiveCommand.state == 42345 && schlafzimmer_deckenlampe.lastUpdate.isBefore(now.minusMillis(600))) {
    if (schlafzimmer_deckenlampe.previousState.state == OFF) {
        schlafzimmer_deckenlampe.send(ON)
    } else {
        schlafzimmer_deckenlampe.send(OFF)
    }
}

This worked fine, but it seems now (at least with MapDB persistence) the timestamp only accurate to seconds is stored.

I tried using sth like now.minus(600, ChronoUnit.MILLIS), but still the light would flicker around thrice per second.

For now, I changed to

if (gateway_ReceiveCommand.state == 42345 && schlafzimmer_deckenlampe.lastUpdate.isBefore(now.minusSeconds(1))) {
    if (schlafzimmer_deckenlampe.previousState.state == OFF) {
        schlafzimmer_deckenlampe.send(ON)
    } else {
        schlafzimmer_deckenlampe.send(OFF)
    }
}

but this is only barely usable, as it still sometimes triggers the light change twice.

Any idea where I took a wrong turn or what to change?
I’m using around 16 different remote codes to do different stuff, if this should be important

2

I kinda also have the same problem as mentioned by @twhuhn .

3

This would not surprise me, but I would be surprised if it has changed.

@hmerck may have a comment?

4

You mean me ??? Why should I have a comment on this ???

5

I can confirm that MapDB seems to be rounding to the nearest second. And it does appear that it used to save down to the millisecond.

But I have some concerns about this approach anyway. It’s really highly dependent on timing and at the sub second level can often go astray in OH. So much is happening in the background that you might be checking the lastUpdate before the most recent update has been saved.

I would try to find an approach anyway that doesn’t require a write to and then read from the disk so that the timing doesn’t become an issue.

  1. save the last update as a global variable
  2. Use a DateTime Item and the timestamp Profile to keep track of the last update
  3. Use a timer as a flag that the most recent update is too soon.

Another thing to realize which might be coming into play here is the that a given rule can now only have one instance running at a time. In OH 2.5 Rules DSL, if you had the same rule triggered really close together, you’d have multiple instances of the rule running at the same time. On OH 3 that won’t happen. Only one will run and the rest of the triggers will be queued up and run in turn.