It seems last_change and last_update been renamed to last_state_change and last_state_update ? or was this a change in an earlier release and I’m slow on my updates
I’ not sure what you mean exactly?
On the item it’s still last_change and last_update.
HABApp 26.9.0 introduced last_state_update and last_state_change on the ItemStateChangedEvent / ItemStateUpdatedEvent that is received from openhab.
What you are doing:
Sending a request to the openHAB API, waiting for the response and then access the last_change field of this response. It does not exist in the API response that why you see this error.
What you probably wanted to do:
Get the openHAB item of HABApp and access the last_change field
OpenhabItem.get_item('BS_Kj_TvStue_Tak').last_change
# or if you know the item type, in this case e.g. StringItem
StringItem.get_item('BS_Kj_TvStue_Tak').last_change
The last one comes from the cache in HABApp and thus has virtually no overhead.
I think so, but I am a little worried of the term “cache”, does that mean at any point there could be a desync in itemstate between habapp and openhab (I’m not thinking milliseconds, but say seconds)?
The reason I ask is I do some reading and writing of metadata on items to control certain energy values/states. And I need to be certain the actual value of given metadata or item state is the current one. There’s no “realtime” updating but the items need to be somewhat synchronized to make sense.
I’ve been using “from HABApp.openhab.interface_sync import get_item” to retrieve item states from OH (or at least so I thought) but maybe I’ve been doing this all wrong? My scope and code has changed through the years and I’ve been picking up things as I learn of new features etc.
HABApp subscribes to the openHAB event bus and automatically updates the items and the item states. So the HABApp internal items always carry the correct item state and item configuration. It’s just a few instants behind openHAB.
In my rules I never use the interface_sync directly - everything “just works”.
Just edit your item and take a look at the HABApp events log. If you see am ItemUpdatedEvent HABApp has already updated the internal item configuration.
Not wrong but unnecessarily slow and complicated. I’d like to improve the docs to make it more clear. Can you hint me to a part where I should add or improve this?
Yes- you probably have two files with the same rule name.
Then HABApp returns a list of rules. It’s on my backlog to enforce rule name uniqueness across all rules but I’ve not yet implemented it.
If the rule name is unique you get the rule directly.
Indeed you found the error. I made a backup directory (with all the rules files) inside the rules directory after updating and didn’t think Habapp would load them, which it did of course, silly mistake. Thanks for helping and sorry for the inconvenience
