search

ccutrer / openhab-jrubyscripting

JRuby Libraries for Openhab
Eclipse Public License 2.0
1 stars 1 forks source link

feat: allow setting item's tags #168

Closed jimtng closed 1 year ago

jimtng commented 1 year ago

A proposal: instead of calling update inside settag, setlabel, etc. How about just adding an Item.provider.update method so one can call it after a series of changes, IF that's desired. Then, inside #update is where we check whether it has a managedprovider where update is applicable.

We will then link to #update from #tags=, #label= etc in the docs to remind them that they need to call update.

Wdyt?

ccutrer commented 1 year ago

That's... kind of abusive, and yet pretty cool (changing a file-based item's label from a rule so that sitemaps update). I did a bit of testing to confirm my suspicions. I wanted to see how much of openHAB updates immediately when and item has update called on its provider after you change it's label. For a managed item, I used this code (changing the label each time I saved it), with the current RC of the gem:

MainUITestSwitch.label = "Main UI Test Switch E"
OpenHAB::Core::Items::Provider.registry.managed_provider.get.update(MainUITestSwitch.__getobj__)

When viewing the Items list in MainUI (/settings/items/), the list will automatically refresh and show the item's new label when that script runs. But if you have a sitemap showing that item open in BasicUI, it will not refresh immediately. I'd consider this a bug in openHAB, but unsurprising as sitemaps are essentially considered legacy. Obviously using a file-based item you simply cannot call update, and thus it won't be able to update anywhere immediately.

It's funny you mentioned the update block when you did. I was thinking of doing a similar thing minutes before you posted, for slightly different reasons - to be able to batch changes to an item into a single update call to the provider. And then having a force: true param to that method to signal "I know what I'm doing, allow me to mess with non-managed items". I'll send up a PR for that.

ccutrer commented 1 year ago

Following on the conversation about skipping the provider#update call: if https://github.com/openhab/openhab-core/issues/3329 gets implemented, and then UIs start relying on it, it would effectively mean that modifications made without the provider's knowledge might never be seen by UIs. You could still work around it--depending on how ETags are implemented--by forcing a no-op "update" to the registry.