Add `getLastStateChange`, `getLastStateUpdate`, and `getLastState` to GenericItem #4351

jimtng · 2024-08-17T02:04:48Z

These methods are handy in many situations and isn't possible with mapdb persistence, so previously it would require something like influxdb.

It also solves the issue of needing to wait until persistence write operation is finished (if it was at all set up to persist on change), so this gives us a cheap and reliable / dependable way of getting the last change / last update time.

See discussions in
https://community.openhab.org/t/persistence-on-off-transitions-with-influx/156271/
https://community.openhab.org/t/blockly-persistence-last-changed-returns-no-result-quite-often/157842

jimtng · 2024-08-17T02:09:48Z

ping @mherwege @rkoshak

rkoshak · 2024-08-17T02:17:46Z

I like the idea of this information being part of the Item. Of course it won't go back beyond OH startup but something is better than nothing. It certainly handles this use car better than persistence I think given all the different ways perspective can be configured.

How does this interact with restoreOnStartup? If an item is restored and not changed does this return the restored time or null? What makes the most sense? I'm not sure I know (it's close to bed time here so maybe I'll sleep on it).

jimtng · 2024-08-17T02:20:02Z

How does this interact with restoreOnStartup? If an item is restored and not changed does this return the restored time or null?

It is not aware of persistence restoration, so I guess once persistence restores the state, it will return the time the state was restored.

spacemanspiff2007 · 2024-08-17T03:58:04Z

Imho it should be possible to query these values from the db so restore on startup should work as expected.
Will these fields also be part of the RestAPI / Websockets response?

jimtng · 2024-08-17T04:06:21Z

Imho it should be possible to query these values from the db so restore on startup should work as expected.

@spacemanspiff2007 would you mind elaborating this please?

Will these fields also be part of the RestAPI / Websockets response?

Good point. I will add them there too.

spacemanspiff2007 · 2024-08-17T04:22:53Z

It's possible to query the last persisted state from persistence and subsequently restore this state as the current state on startup. It's also possible to query the persisted state before that.
Subsequently it should be possible (imho) to get all the values from the persistence service so restore on startup should also work for these fields as expected.

jimtng · 2024-08-17T04:35:49Z

It's possible to query the last persisted state from persistence and subsequently restore this state as the current state on startup.

Yes, isn't this what restoreOnStartup does?

It's also possible to query the persisted state before that.
Subsequently it should be possible (imho) to get all the values from the persistence service so restore on startup should also work for these fields as expected.

I don't quite understand the above statements.

This PR doesn't interfere with persistence's restoreOnStartup. If I understand @rkoshak's question correctly, it is a question of whether getPreviousState should return (java) null as is the case when there was no previous state being set on the item, or whether it should return UnDefType.NULL because that's the item's state before restoration. Currently it's the latter.

spacemanspiff2007 · 2024-08-17T04:49:36Z

I think it's a misunderstanding.
All I am saying is that it's technically possible to restore these new fields from persistence so imho it makes sense to do so during restoreOnStartup.

…icItem Signed-off-by: Jimmy Tanagra <[email protected]>

jimtng · 2024-08-17T05:24:02Z

@spacemanspiff2007 I've added it to the REST response

{
  "link": "http://192.168.1.10:8484/rest/items/TestSwitch1",
  "state": "ON",
  "previousState": "NULL",
  "lastUpdate": 1723872081231,
  "lastChange": 1723871965049,
  "editable": false,
  "type": "Switch",
  "name": "TestSwitch1",
  "tags": [],
  "groupNames": [
    "TestSwitches"
  ]
}

mherwege · 2024-08-17T11:03:32Z

All I am saying is that it's technically possible to restore these new fields from persistence so imho it makes sense to do so during restoreOnStartup.

That depends on the persistence service. And it is not the case for mapDB, the most used persistence service for restoreOnStartup.

I would argue that, when the item state is updated as a consequence of restoreOnStartup, it should not update these lastChange and lastUpdate fields because now is probably the wrong time. But I am not sure this is feasible. I doubt the item knows anything about the source of the update/change.

In general, I think having the extra fields is a good idea. I just feel like we are still not there to give an answer to a simple question: when did my item last change?
If I use this new function (lastChange):

Item did changed since startup -> OK, correct answer, and better then what I could get from persistence as persistence could miss the everyChange strategy or could have compressed
Item did not change since start -> now, which is wrong
If I can figure out the answer is wrong and I have a persistence service with everyChange: call lastChange on the service ->
a. Current state equal to last state in DB -> correct answer from persistence (ignoring for now impact of compression)
b. Current state different from last state in DB -> no answer (null)
c. If no answer, you could return now in the calling rule, although in this case the startup time might be a more appropriate approximation

In an ideal world, mapDB would just store the lastChange time of an item with the state and we could restore that together with the state. I am just not sure it is easily feasible.
Thinking out loud here: As mapDB is kind of a special case which is just used for restoreOnStartup, would it make sense to remove restoreOnStartup from persistence all together and make it part of the core infrastructure, just to take care of this? I would argue you should then persist all items in mapDB all the time, invisible to the user configuration, and use only that special DB in startup to restore item states and their accompanying update dates.

We can keep adding layers to this, but there are always issues and exceptions. I like the idea of keeping lastChange and lastUpdate with the item. But I think the real simplification comes when we have a simpler restore mechanism on startup. Because than, you always get the right answer. Other persistence services then have the focus on data for graphing and calculations, which makes sense in my view.

jimtng · 2024-08-17T11:36:09Z

OK, I think I now understand what @spacemanspiff2007 was alluding to, thanks to @mherwege's explanation.

Thinking out loud here: As mapDB is kind of a special case which is just used for restoreOnStartup, would it make sense to remove restoreOnStartup from persistence all together and make it part of the core infrastructure, just to take care of this? I would argue you should then persist all items in mapDB all the time, invisible to the user configuration, and use only that special DB in startup to restore item states and their accompanying update dates.

Not a bad idea.

rkoshak · 2024-08-17T17:16:19Z

In an ideal world, mapDB would just store the lastChange time of an item with the state and we could restore that together with the state. I am just not sure it is easily feasible.

Why would this not be feasible? I beleive all the apis already exists in persistence to get the time from persistence. Once you have that it's just a matter of adding the last change and last update time as a parameter on the Item.

Thinking out loud here: As mapDB is kind of a special case which is just used for restoreOnStartup,

I'm not sure we can make that case that's it's always only used for restoreOnStartup. It's useable if you only care about the most recent change to the Item in a rule (given it's current default strategies). One could change the strategies and it would work for most recent update.

But if these properties are added to the Item and we go down a path where those are made available and accurate on the the Item this use case is handled.

I would argue you should then persist all items in mapDB all the time, invisible to the user configuration, and use only that special DB in startup to restore item states and their accompanying update dates.

Be careful here.

Not all uses want all Items restored.

Not all users want all Items restored to their most recent change or update (e.g they use a rule with .persist to control when the state gets saved).

These use cases are now currently supported. Any move of restoreOnStartup to core would need to handle these use cases too. How the Item's state is saved and which Items are restored needs to be configurable on an Item by Item basis like it is now in persistence.

spacemanspiff2007 · 2024-08-17T18:34:58Z

That depends on the persistence service. And it is not the case for mapDB, the most used persistence service for restoreOnStartup.

It would be trivial to modify mapDB persistence service to save the additional three values. A quick glance at the docs shows it should be possible. If not it's always possible to name mangle additional values with a separator that's not a valid item name (e.g. MyItem#lastUpdate)
The question is - as you correctly pointed out - if that's something that results in a meaningful behavior.

2. Item did not change since start -> now, which is wrong

No - it should return null because it's undefined.

These use cases are now currently supported. Any move of restoreOnStartup to core would need to handle these use cases too. How the Item's state is saved and which Items are restored needs to be configurable on an Item by Item basis like it is now in persistence.

I strongly agree. For many devices that report the state themselves I explicitly do not save the item state so I don't have the wrong state after startup. If the restore makes sense depends strongly on the device, the user and how the rules are written.
I for once was struggling with a rule and strange startup behavior during testing and the root cause was rrd4j restoring states during startup which was automatically configured (rrd4j).

Just a hint:
HABApp already provides the last_update and last_change datetimes. I deliberately chose not to make them null to simplify the rules so the users don't have to always check for that. Instead I chose to initialize them with the timestamp when the item gets created.

That would also result in a proper behavior when restoring from persistence.

Time 0 - item creation:
  state: NULL
  previousState: NULL
  lastUpdate: 0,
  lastChange: 0,
...
Time 10 - persistence restore:
  state: "asdf"
  previousState: NULL
  lastUpdate: 10,
  lastChange: 10,

So I am basically suggesting the opposite of what I wrote above 🙈 🤣

jimtng · 2024-08-19T13:39:30Z

These use cases are now currently supported. Any move of restoreOnStartup to core would need to handle these use cases too. How the Item's state is saved and which Items are restored needs to be configurable on an Item by Item basis like it is now in persistence.

Each item can have a special metadata restoreOnStartup=true. When this is on a group item, persist all its direct members.

mherwege · 2024-08-19T14:13:34Z

Each item can have a special metadata restoreOnStartup=true. When this is on a group item, persist all its direct members.

I think, what @rkoshak also implied is that one may want to use different rules for persisting values, not just on every change, but e.g. persist it once and always use that same value at startup. And that would mean we also need to support that part of the configuration in core. And then we are back to doing it the way it is done now anyway.

Thinking further about it:

Changing the restoreOnStartup logic to also restore lastChange, lastUpdate and previousState at startup is fairly easy to do. The method to change is

openhab-core/bundles/org.openhab.core.persistence/src/main/java/org/openhab/core/persistence/internal/PersistenceManagerImpl.java

Line 521 in 506ccd4

private void restoreItemStateIfPossible(Item item) {

. You may need some extra methods (or an extended setState method that has extra parameters) in GenericItem to also set these fields, although it should probably only be used for restoreOnStartup.
Many persistence services can already provide the extra info required. MapDB cannot and should be extended to store and retrieve the extra information. I don't know how easy that would be to do. We also seem to be using a very old version of MapDB, so I don't know how much impact that has on feasability.

With the above logic in place, it also would make sense to revisit the persistence extension actions to not return null, but return what is actually in the database, and document it as a breaking change, advising users to use the Item methods for this use case.

mherwege · 2024-08-19T14:32:18Z

Many persistence services can already provide the extra info required. MapDB cannot and should be extended to store and retrieve the extra information. I don't know how easy that would be to do. We also seem to be using a very old version of MapDB, so I don't know how much impact that has on feasability.

Looking at MapDB code, it is actually not that difficult. The item state and time are already stored as a JSON string. Adding extra fields should not be a problem.

rkoshak · 2024-08-19T16:56:05Z

I think, what @rkoshak also implied is that one may want to use different rules for persisting values, not just on every change, but e.g. persist it once and always use that same value at startup. And that would mean we also need to support that part of the configuration in core. And then we are back to doing it the way it is done now anyway.

Since a user needs a rule for calling .persist, if there's also way to turn off the restoreOnStartup for that Item in this new core feature, maybe that would be sufficient as they could create a system started rule to restore the Item's state manually from whatever persistence they are using instead of this new core one. Or maybe we can add a persistence extension to restore the state with the most recent value in the database that could be called from a rule in place of the restoreOnStartup strategy that would be removed.

This new core service doesn't need to do all the use cases. We just need to ensure that all the use cases are covered somehow.

With #4324 I think we will reliably be able to count on persistence being there by runlevel 100. So maybe a system started rule with previousState would be sufficient. I don't know though, I haven't fully explored all the edge cases that can crop up due to timing and such.

Item did not change since start -> now, which is wrong

No - it should return null because it's undefined.

Maybe we are thinking too hard about this.

What do we intend these new properties to represent? I see two options:

reflect the changes/updates made to the Item
refelct the changes/updates to the device

If it's just 1, we don't really need to worry about most of these complexities. If an Item doesn't change after OH startup, getLastChange will be the time when the Item was created and set from restoreOnStartup and getPreviousState would be NULL. If you want the actual device information and not just information about the Item during this run session of OH, then you need to use the existing persistence capabilities. But this also means we don't need a new restoreOnStartup service in core or any of that complexity and the implementation becomes pretty simple.

If we want to make 2 happen then it gets much more complicated, as we can see and we probably need something built into core.

But do we really need to solve 2 here? Maybe 1 is sufficient? I think users who prefer not to use persistence at all would love to have 1.

We also need to thing of second tier impacts like the increase in writes for those running on SD cards and the like if this core restoreOnStartup feature becomes the default behavior.

jimtng · 2024-08-28T09:06:38Z

So what's the next step?

Changing the restoreOnStartup logic to also restore lastChange, lastUpdate and previousState at startup is fairly easy to do. The method to change is

openhab-core/bundles/org.openhab.core.persistence/src/main/java/org/openhab/core/persistence/internal/PersistenceManagerImpl.java

Line 521 in 506ccd4

private void restoreItemStateIfPossible(Item item) {

. You may need some extra methods (or an extended setState method that has extra parameters) in GenericItem to also set these fields, although it should probably only be used for restoreOnStartup.

If we are going to proceed in this direction, I would suggest:

First merge this PR without the extra setState / setters for lastChange, lastUpdate etc.
If and when the integration with the persistence extensions is added, then add the setters as you suggested. This way, it's clearer how the setters are implemented according to how it's actually used.

mherwege

LGTM

mherwege · 2024-08-28T09:26:26Z

If we are going to proceed in this direction, I would suggest:

First merge this PR without the extra setState / setters for lastChange, lastUpdate etc.

If and when the integration with the persistence extensions is added, then add the setters as you suggested. This way, it's clearer how the setters are implemented according to how it's actually used.

I am fine with this.

spacemanspiff2007 · 2024-08-28T19:35:37Z

I think this is the best way, too.
Maybe it makes sense to make persistence of lastChange etc. configurable. This could and should be discussed in the according PR.
Do the the new values also get reported in the corresponding item events?

openhab-bot · 2024-09-01T16:20:50Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/lastupdate-and-null-values/158134/6

openhab-bot · 2024-09-09T10:32:29Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/how-to-monitor-if-item-is-frequently-updated/158260/6

jimtng · 2024-09-09T12:48:31Z

how do we resolve the access to these methods vs the persistence methods with the same name within rulesDSL?

mherwege · 2024-09-09T13:45:42Z

how do we resolve the access to these methods vs the persistence methods with the same name within rulesDSL?

Maybe I miss something here, but what gets called would be determined by the imports I would think. As both items and persistence are imported by default, it indeed leads to a conflict which will force changing the rules to have a fully qualified name.

The options then become:

Give these new methods another name: this is fully backward compatible.
Change the name of the existing persistence actions to getLastPersistedState, getLastPersistedUpdate and getPreviousPersistedState.

In both cases, rules would work without being changed, but 2 would have a slight change in behaviour. I would still prefer 2 because it is more natural not to call persistence if not needed. If one absolutely wants the value from persistence the rule would need to be changed, but it would be very clear what is expected. At the same time, the persistence actions could be modified again to not return null, but the last effective persisted value.
2 also requires adapting the scripting languages to call these changed methods.

jimtng · 2024-11-28T11:17:55Z

So do you agree that renaming the new methods is a better idea?

mherwege · 2024-11-28T11:34:53Z

So do you agree that renaming the new methods is a better idea?

Yes, I do in the end.

jimtng · 2024-11-28T12:50:13Z

@mherwege Perhaps with no naming changes in persistence, at least now instead of returning null, the persistence method can call the Item's method to fulfil the request when such data is not available from the persistence service.

Or another strategy is to try Item's method first, and if it's null (when it was first loaded and still UNDEF), then it can query the persistence service.

This will solve the issues linked in the first post above, without requiring users to change their existing scripts!

mherwege · 2024-11-28T13:00:15Z

@mherwege Perhaps with no naming changes in persistence, at least now instead of returning null, the persistence method can call the Item's method to fulfil the request when such data is not available from the persistence service.

Or another strategy is to try Item's method first, and if it's null (when it was first loaded and still UNDEF), then it can query the persistence service.

This will solve the issues linked in the first post above, without requiring users to change their existing scripts!

Agreed. That makes sense.

Signed-off-by: Jimmy Tanagra <[email protected]>

jimtng · 2024-11-28T23:33:11Z

I've renamed the methods to getLastStateChange, getLastStateUpdate, and getLastState to avoid conflicts with the PersistenceExtensions methods. There should be no issues going forward now, I hope.

I don't think these values need to be "restored on startup" like persistence. If people need that restoration feature, they can call the equivalent PersistenceExtensions method.

I am still not 100% satisfied with the naming, but I can't think of any better names.

andrewfg · 2024-11-28T23:49:29Z

not 100% satisfied with the naming, but I can't think of any better names

You could simply call the original ones 'xyz' and the new ones 'xyz2' ...

mherwege · 2024-11-29T07:58:41Z

I don't think these values need to be "restored on startup" like persistence. If people need that restoration feature, they can call the equivalent PersistenceExtensions method.

Not required, true. But that means a user has to explicitely create startup rules if they want to do this, or have a check in every rule if the values are there to retrieve from persistence if not. So at some point I would like to have it.

I am still not 100% satisfied with the naming, but I can't think of any better names.

Same for me. That's part of the reason why renaming in the PersistenceExtensions class was attractive. It then clearly conveyed the purpose. Putting '2' behind the name does not solve that either. By lack of better idea, I think what you propose is fine.

mherwege · 2024-11-29T17:16:03Z

I have created:

Persistence restore lastState and lastStateChange on startup #4463: makes it possible to restore lastState, lastStateUpdate and lastStateChange on startup
[mapdb] Store and restore lastState, lastStateChange and lastChangeUpdate openhab-addons#17820: enhanced mapDB to store these values

openhab-bot · 2024-12-07T10:18:39Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/ideas-and-discussion-what-features-do-you-want-in-openhab-5-0/160573/161

openhab-bot · 2025-01-22T15:30:07Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/ideas-and-discussion-what-features-do-you-want-in-openhab-5-0/160573/464

openhab-bot · 2025-01-24T10:33:40Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/why-is-persistence-lastupdate-not-always-working/161949/3

kaikreuzer

Thanks @jimtng for this useful feature that nicely integrates into the existing code and thanks to all others for the in-depth discussion. Let's merge this!

…em#last_state_update` methods openhab/openhab-core#4351 Signed-off-by: Jimmy Tanagra <[email protected]>

spacemanspiff2007 · 2025-02-16T06:51:45Z

@jimtng Have you already included the new timestamps in the ItemStateUpdatedEvent and ItemStateChangedEvent?

jimtng · 2025-02-16T07:27:05Z

@jimtng Have you already included the new timestamps in the ItemStateEvent and ItemUpdatedEvent?

no, but it sounds like it might be useful

spacemanspiff2007 · 2025-02-16T07:41:27Z

Should I create an issue as a reminder?

mherwege · 2025-02-22T17:00:00Z

@jimtng Do you have plans to extend documentation for this?
I guess the scripting addons and documentation may also require updating.

jimtng · 2025-02-22T20:49:59Z

There's still a bit of a debate over whether we need to convert this from ZDT to Instant.
In addition to the javadoc, where else should this be mentioned?

As for the scripting addons, I've got a draft for jruby.

mherwege · 2025-02-23T11:35:59Z

For documentation, what about:

https://next.openhab.org/docs/configuration/rules-dsl.html#using-the-states-of-items-in-rules: explain extra methods on the item
https://next.openhab.org/docs/configuration/persistence.html#persistence-extensions-in-scripts-and-rules: explain alternative for getting last state, last state change and last state update.

I will keep jsscripting and Blockly in mind when the dust settles on Instant vs. ZonedDatetime.

jimtng requested a review from a team as a code owner August 17, 2024 02:04

jimtng force-pushed the item-last-change branch from 2cadc5e to 75bc9c9 Compare August 17, 2024 02:17

jimtng force-pushed the item-last-change branch from 75bc9c9 to 0c7eeed Compare August 17, 2024 02:18

Add getLastChange, getLastUpdate, and getPreviousState to Gener…

178df65

…icItem Signed-off-by: Jimmy Tanagra <[email protected]>

jimtng force-pushed the item-last-change branch from 0c7eeed to 178df65 Compare August 17, 2024 05:22

mherwege approved these changes Aug 28, 2024

View reviewed changes

jimtng changed the title ~~Add getLastChange, getLastUpdate, and getPreviousState to GenericItem~~ Add getLastStateChange, getLastStateUpdate, and getLastState to GenericItem Nov 28, 2024

Rename to getLastStateChange, getLastStateUpdate, getLastState

cccb8d0

Signed-off-by: Jimmy Tanagra <[email protected]>

jimtng force-pushed the item-last-change branch from 9beb230 to cccb8d0 Compare November 28, 2024 13:07

This was referenced Nov 29, 2024

Persistence restore lastState and lastStateChange on startup #4463

Merged

[mapdb] Store and restore lastState, lastStateChange and lastChangeUpdate openhab/openhab-addons#17820

Merged

holgerfriedrich added the enhancement An enhancement or new feature of the Core label Dec 4, 2024

kaikreuzer approved these changes Feb 15, 2025

View reviewed changes

kaikreuzer merged commit 3b3fd3a into openhab:main Feb 15, 2025
5 checks passed

jimtng added a commit to jimtng/openhab-jruby that referenced this pull request Feb 15, 2025

Document the new Item#last_state, Item#last_state_change, and `It…

6995a74

…em#last_state_update` methods openhab/openhab-core#4351 Signed-off-by: Jimmy Tanagra <[email protected]>

jimtng mentioned this pull request Feb 15, 2025

Document the new Item#last_state, Item#last_state_change, and Item#last_state_update methods openhab/openhab-jruby#397

Draft

jimtng deleted the item-last-change branch February 15, 2025 23:48

spacemanspiff2007 mentioned this pull request Feb 16, 2025

Add LastStateChange and LastStateUpdate Timestamp to events #4601

Open

jimtng mentioned this pull request Feb 17, 2025

Add lastStateUpdate, lastStateChange to ItemStateUpdatedEvent/ItemStateChangedEvent #4606

Open

Add getLastStateChange, getLastStateUpdate, and getLastState to GenericItem #4351

Add getLastStateChange, getLastStateUpdate, and getLastState to GenericItem #4351

Conversation

jimtng commented Aug 17, 2024 • edited Loading

jimtng commented Aug 17, 2024

rkoshak commented Aug 17, 2024

jimtng commented Aug 17, 2024

spacemanspiff2007 commented Aug 17, 2024

jimtng commented Aug 17, 2024 • edited Loading

spacemanspiff2007 commented Aug 17, 2024

jimtng commented Aug 17, 2024 • edited Loading

spacemanspiff2007 commented Aug 17, 2024

jimtng commented Aug 17, 2024

mherwege commented Aug 17, 2024

jimtng commented Aug 17, 2024

rkoshak commented Aug 17, 2024

spacemanspiff2007 commented Aug 17, 2024

jimtng commented Aug 19, 2024 • edited Loading

mherwege commented Aug 19, 2024

mherwege commented Aug 19, 2024

rkoshak commented Aug 19, 2024 • edited Loading

jimtng commented Aug 28, 2024

mherwege left a comment

Choose a reason for hiding this comment

mherwege commented Aug 28, 2024

spacemanspiff2007 commented Aug 28, 2024

openhab-bot commented Sep 1, 2024

openhab-bot commented Sep 9, 2024

jimtng commented Sep 9, 2024

mherwege commented Sep 9, 2024

jimtng commented Nov 28, 2024

mherwege commented Nov 28, 2024

jimtng commented Nov 28, 2024 • edited Loading

mherwege commented Nov 28, 2024

jimtng commented Nov 28, 2024

andrewfg commented Nov 28, 2024

mherwege commented Nov 29, 2024

mherwege commented Nov 29, 2024

openhab-bot commented Dec 7, 2024

openhab-bot commented Jan 22, 2025

openhab-bot commented Jan 24, 2025

kaikreuzer left a comment

Choose a reason for hiding this comment

spacemanspiff2007 commented Feb 16, 2025 • edited Loading

jimtng commented Feb 16, 2025

spacemanspiff2007 commented Feb 16, 2025

mherwege commented Feb 22, 2025

jimtng commented Feb 22, 2025

mherwege commented Feb 23, 2025 • edited Loading

Add `getLastStateChange`, `getLastStateUpdate`, and `getLastState` to GenericItem #4351

Add `getLastStateChange`, `getLastStateUpdate`, and `getLastState` to GenericItem #4351

jimtng commented Aug 17, 2024 •

edited

Loading

jimtng commented Aug 17, 2024 •

edited

Loading

jimtng commented Aug 17, 2024 •

edited

Loading

jimtng commented Aug 19, 2024 •

edited

Loading

rkoshak commented Aug 19, 2024 •

edited

Loading

jimtng commented Nov 28, 2024 •

edited

Loading

spacemanspiff2007 commented Feb 16, 2025 •

edited

Loading

mherwege commented Feb 23, 2025 •

edited

Loading