Is there a persistance bug in 5.1.0 for MapDB?

This is my current file, but it wont record the state for GarageAir_MasterSwitch

Current mapdb.persist file is:


Items {
    GarageAir_MasterSwitch : strategy = everyChange, restoreOnStartup
    Motion_PartyMode : strategy = everyChange, restoreOnStartup
    TimeOfDay : strategy = everyChange, restoreOnStartup
    gAllLights* : strategy = everyChange, restoreOnStartup
    gMotionSensors* : strategy = everyChange, restoreOnStartup
    gDoorSensors* : strategy = everyChange, restoreOnStartup
    gGarage_Average_Temperature : strategy = everyChange, restoreOnStartup
}

Im running a rule/script to check the state and it seems mapdb has no record of the persistance on this item.

Some of the code is here: try {
// Manually importing the core persistence extension to fix “ReferenceError”
const PersistenceExtensions = Java.type(“org.openhab.core.persistence.extensions.PersistenceExtensions”);

          // Direct call to MapDB
          const lastChangeRaw = PersistenceExtensions.lastChange(masterSwitch.rawItem, "mapdb");
          
          if (lastChangeRaw) {
              const lastChangeZDT = time.toZDT(lastChangeRaw);
              minsSinceLastChange = time.Duration.between(lastChangeZDT, now).toMinutes();
              logger.info("AC Logic | Temp: " + avgTemp.toFixed(1) + "°C | Last Change: " + minsSinceLastChange + "m ago");
          } else {
              logger.warn("AC Logic | MapDB has no record for " + masterSwitch.name);
          }
      } catch (e) {
          logger.error("AC Logic | Java Persistence Failure: " + e);
      }

Hi @dastrix80

A quick tes to determine what persistence your item has is go to the Developer Tools → API Explorer → Persistence → GET /persistence/items{itemname} and run the API call (adding your item name in the relevant field) to determine if it returns anything.

If there is data returned then the issue is not persistence.

Also you do not mention your openHAB version 5.x we also get the previous value returned with the event object ( referenced as “.was” ) File: USAGE — openHAB JRuby

(EDIT: you mentioned in the title your version)

Has the Item changed since adding that line to the .persist file?
After changing the file did you see in the logs that OH loaded it?

What triggers this rule? Persistence will return null if it sees that the current state of the Item is different from the most recent value stored in the database. This is because in that situation OH doesn’t know when the lastChange was.

Note, as @BrettLHolmes points out, if the lastChange is really what you are after, you do not and should not rely on persistence for this and use masterSwitch.lastStateChangeTimestamp. The last update and last change timestamp and state are stored on the Item now independently of persistence. It’s always going to be accurate and not dependent on timing.

The REST API (as @BrettLHolmes suggests) the best way to determine if the Item is being stored in persistence. That will be immune to timing issues.

This is JS Scripting code. It’s way overly complicated as written (LLM generated?). I should be:

const lastChange = masterSwitch.lastChange("mapdb"); // returns `null` if there's a problem
if(lastChange){
  const minsSinceLastChange = time.Duration.between(lastChange, time.toZDT()).toMinutes();
  logger.info("AC Logic | Temp: " + avgTemp.toFixed(1) + "°C | Last Change: " + minsSinceLastChange + "m ago");
}
else {
  logger.warn("AC Logic | MapDB has no record for " + masterSwitch.name);
}

Or if you use the property on the Item

const minsSinceLastChange = time.Duration.between(masterSwitch.lastStateChangeTimestamp, time.toZDT()).toMinutes();
logger.info("AC Logic | Temp: " + avgTemp.toFixed(1) + "°C | Last Change: " + minsSinceLastChange + "m ago");

Thanks, I’ve convered over the persist files into the UI and then used the LLM to convert my code, its working now and I can see the last update time using mapdb.

Likely the LLM conversion from DSL to Java is way too complicated, once ive converted everything over in a working state, I might refactor things for another language to simplify it. But for now, i’m happy to be working, converted from things, items, rules in files into the UI and on 5.1.0

One step at a time! :slight_smile: Thanks

Indeed, since this code isn’t even Java.

I’m astonished it produces anything that even works. Most of the time LLMs end up just making stuff up when they try to do anything with OH rules. In this particular case it generated something half Nashorn JavaScript and half GraalVM JavaScript and it’s only because those two can be compatible that it worked at all.

1 Like

hahah! Yes, its been talking about Graal. RE: languages, if im using LLMs whats the best way forward in terms of rule scripting? I’m glad it all just works. its achieving things in openhab I could have only dreamed of. I’m WAY happier with OH now with LLMs than ever before :slight_smile:

In my experience LLMs aren’t that bad when copying the documentation into them. I’ve used them to generate parts of the rules for the demo server EMS simulation.
Simply copy JavaScript Scripting - Automation | openHAB into the prompt and the results won’t be as bad as without, but still far from being perfect code.

1 Like

My big caution though is when it fails, often the code is not going to be something that even we on the forum can fix for you. Over time, I know that I’m personally growing less and less motivated to correct bad AI generated code. What motivates me is to teach people how to code better. If someone isn’t going to take my post to learn from it, what’s the point?

I’d like to see a policy on the forum that any code posted that was generated by an LLM should be clearly labeled as such. Not sure that would be enforceable though. For now, the code is often so overly complex and incorrect in really “creative” ways that it’s pretty obvious when it’s LLM generated. Maybe that’s good enough.

2 Likes