[SOLVED] Yet another changedSince that is not working anymore

Basically I have this inside a rule, it’s always assuming “false” no matter what, although in the past this was working:

offTimer = createTimer(now.plusSeconds(2), [|
    if (Portao_Garagem.changedSince(now.minusMinutes(3)) == false) {
        Portao_Garagem.sendCommand(ON)
    }
])

I even use this 2 seconds timer (which does NOT seem to be working since this activates immediately), to give it time to go into DB prior to check for changedSince.

I am using RPi4 with OH 3.3.0.M5 and JDBC (MySQL) as persistance.

For instance, if I have this in my DB, it should assume 1 minute later that there WAS change and not consider it as “false”, but NOT 1 hour later as it happens:

image

What am I missing here?

I have many more rules using information from DB such as:

Sensor_Humidade_Rua.historicState(now).state < 90

And this works like a charm! So if this works, I assume it is not a problem from the DB but instead from the “changedSince”.

To see if I understood properly the “changedSince” logic, what this does in my case is checking if in the last 3 minutes, there was some change. Or will it actually check, from now minus 3 minutes if there was a change ever? Because in that case, it makes sense to be always true since, obviously, in the past there was a lot of changes…

The way it works is it gets all the values stored in the database between now and the passed in timestamp.

If there is no value at the timestamp but there are entries since the timestamp, a change is assumed and true is returned.

It then iterates over all the values returned from the database and if any of them are different from the Item’s current state true is returned.

You can find the code here: openhab-core/bundles/org.openhab.core.persistence/src/main/java/org/openhab/core/persistence/extensions/PersistenceExtensions.java at 1074e5918360657753e65d039992552b04d41cef · openhab/openhab-core · GitHub

Note that the key here is whether the Item’s current state became that current state after that time stamp. So, given your two DB entries above:

Time changedSince notes
16:22:57 ? can’t tell without the previous entry and knowing what the persistence strategy is
16:23:00 true the Item’s current state is different from at least one saved state in the last three minutes
16:24:00 true the Item’s current state is different from at least one saved state in the last three minutes
16:25:00 true the Item’s current state is different from at least one saved state in the last three minutes
16:26:00 false the Item has been OFF for at least three minutes

Where things can get confusing is if you have, for example, everyUpdate or something like everyMinute in your persistence strategy because there is no way to know what caused an entry in the database. But that probably doesn’t come into play here.

Then something else is going on and we cannot trust anything we are seeing. There is no reason why the code, as written above, would not create a timer and run in two seconds. How do you know it’s running immediately? There’s no log statements.

The logic seems odd. Why send a command to an Item just because it hasn’t changed in three minutes? Would Expire be a better fit perhaps?

1 Like

I feel so dumb right now wasting your time with this. But it was something I’ve already invested (literally) so many hours that I was starting to get really frustrated.

The entry on the DB for the OFF state that you saw there, was manually inserted by me because I was always seeing ON.

Now bare with me on this dumb thing that was happening!

I am using Sonoff SV to open and close my gates. When in one of them, only recently I’ve put a sensor to it.

This means that I totally forgot to change the JSON from “Power” to “Power1”. I don’t know why but it was still assuming my “ON” command through “Power”.

I’ve now corrected my Thing and properly set the “Power1” and since it now registers the ON and OFF actions, it now works as intended! :slight_smile:

This is because I have a rule on my outside gate to open my garage gate (and vice-versa) so in order to avoid an infinite loop, that is why I’ve put that “safeguard”.