Group Based Persistence in OH3

Setup, Configuration and Use Beginners
,
1

Hello everybody,
I would like to implement a group-based persistence of the Items I have created.
In particular, I’d like to persist a specific item among the whole lot of items to a JDBC mySQL persistence , leaving the remaining ones to RRD4j (for the time being)
I have found this post Design Pattern: Group Based Persistence but I don’t understand how to make it in the OH3 UI, as i am very fresh to the UI.

Should I create the items manually or there is some UI way I am not aware of?

Please suggest

2

You should read the chapter about persistence in the documentation. Unfortunately it is actaul not possible to define persistence in the UI.

Persistence | openHAB

3

Thanks,
I’ll still have to try this but from a quickly read I could define a item based strategy, including the persistence, as described here Persistence | openHAB, leaving the items managed through the UI.
Did I get it right?
That would solve the problem for me :slight_smile:
Thanks for pointing in the right direction. Did not read the doc as I still am not sure what refers to OH3 and what doesn’t

4

Everything at www.openhab.org is for OH3.

Everything at v2.openhab.org is for OH2.

5

gosh. I will never get it. now there is a new one v2.openhab.org.
I thought next.openhab.org was for OH3
openhab.org was for 2.x as this screnshot seemed to confirm

image
image770×940 50.6 KB

Thou shall have no certainty!
Hope someone understands there that the doc organization really looks messy for a first time user. Multiple sites, references to different releases in the sites which is supposed to doc a different ones… I feel doc should be the very last resort for someone trying to figure out the system with no previous knowledge. :pensive:

6

next.openhab.org was for OH3, whilst OH2 was still the default release. But now that OH3 is the default release all documentation was moved from next.openhab.org to www.openhab.org, and all documentation from www.openhab.org was moved to v2.openhab.org.

7

thanks,
ironicaally, I could have understoo that as my GIT edit of the windows installation page shows up in openhab.org. I take it then that next.openhab.org is some kind of dead branch

8

does anybody have a clue where the syntax used to define everyHour below is documented in the doc page Persistence | openHAB?

// persistence strategies have a name and definition and are referred to in the "Items" section
Strategies {
        everyHour : "0 0 * * * ?"
        everyDay  : "0 0 0 * * ?"

        // if no strategy is specified for an Item entry below, the default list will be used
       default = everyChange
}

Moreover: is there a way to define a strategy: do not persist? Could not find that explained

9

Just to summarize and elaborate.

  1. you have to define the persistence strategies in .persist files. To persist all members of a given Group use “GroupName*” for the ltem.

  2. Yes, you can create Groups in the UI add Items to those Groups through the UI. Create the Item by clicking on the + icon in the Items page. Then choose Group as the Item type. Once created, you can add direct members of the Group and select the items you want to be persisted.

  3. The syntax is standard cron syntax. https://openhab.org/docs/configuration/persistence.html#cron-persistence-triggers

openHAB uses Quartz (opens new window)for time-related cron events. See the Rules article for more information.

So everyMinute would be "0 * * * * ?" and it will execute on the 0th second of the minute.

Do not persist means not including the file as part of the strategy. This also requires not using a default strategy or setting the default to something like once a year or the like.

3 Likes
10

thanks, much clearer now.
Since I’m already geared up on the topic, do you think if I cook up an edit of the doc page it could help?

11

I don’t know. I’m not sure what to edit in this case. The persistence docs seemed pretty clear in this manner but if there was something unclear please feel free to correct it. The main confusion here seemed to not know which docs were the OH 3 docs (the ones shown by default now that OH 3 is released).

12

well,
of course you know.
Here I’d inject

  1. the name of the persist file is the name of the persistance once you strip the initial “persistence-” part So you find for instance persistence-jdbc-mysql and that becomes jdbc-mysql.persist. one thing less to fuigure out.
  2. add a link to the rules article and add maybe a link to a page explaining group creation using UI, if I find it
  3. add the note about not persistence.
  4. Also, cannot make this work

Strategies {
toMySQL : everyUpdate
default = everyChange
}
Items {
BUNDLE_TSDC : strategy = toMySQL
}

which to me seems in line with the doc, but gives a missing RULE_STRING at 'everyUpdate' error

Of course you must know all of this, but either we attach you to the page :smiley:or we make it more complete for ppl who don’t know and probably are as dumb as I am.

Still not figured out the syntax to use for alias, I think there should be an example. Is it maybe to assign a specific name when persisted in the persistence engine (read database)? That would be interesting but not explained

13

The persistence docs already say

Persistence Strategies are configured in a file named <persistenceservice>.persist, stored in $OPENHAB_CONF/persistence. Replace “persistenceservice” with the name of your persistence add-on (e.g. rrd4j.persist).

There already is a link to the Rules Article. It even takes you straight to the section that described the full cron sytax. You can even click on it in the quote I copied in the post above.

That is one place where I think the docs is wrong or at least missleading. You’ve already a strategy named everyUpdate. It doesn’t make any sense to use it

in place of strategyName above:

You use everyUpdate to the right of the = in the Items section. If you want to define something like toMySQL to mean every five minutes you could define a new strategy using that cron expression. But you can’t rename an existing strategy, not that it makes much sense to do that in the first place.

14

Any hint of how this can make work?
I am thinking of amending the doc with the points above mentioned and I’d like to understand if this alias reference should be omitted or not…

15

Yes, the docs are mostly right.

aliasName: cron expression

You can’t use

aliasName : otherAliasName like you tried to do. There's no need to anyway.
16

I mean the alias mentioned here

This section defines which items should be persisted with which strategy. The syntax is as follows:

Items {
    <itemlist1> [-> "<alias1>"] : [strategy = <strategy1>, <strategy2>, ...]
    <itemlist2> [-> "<alias2>"] : [strategy = <strategyX>, <strategyY>, ...]
    ...

}

Can you please make an example of one <itemlist1> [-> "<alias1>"] : [strategy = <strategy1>, <strategy2>, ...]
I annot understand the syntax ->

17

According to this in the docs:

Optionally, an alias may be provided if the persistence service requires special names (e.g. a table to be used in a database, a feed id for an IoT service, etc.)

You’ll need to look at the docs for the various persistence add-ons to find which ones use the alias and hopefully an example of it in use.

18

If I understand it correctly, persistence strategies are additional. So, if I assign an item to several persistence strategy groups, the item will be persisted according to the combined group-based persistence strategies. For instance:

Strategies {
	everyMinute	:	"0 * * * * ?"
	everyHour	:	"0 0 * * * ?"
	everyDay	:	"0 0 0 * * ?"

	// if no strategy is specified for an Item entry below, the default list will be used;
	// don't define a default strategy if you don't want persistence by default.
	// default = everyChange
}

Items {
	// Persist group members: use asterisk after group name!
	gPersistEveryChange*			: strategy = everyChange
	gPersistEveryUpdate*			: strategy = everyUpdate

	gPersistRestoreOnStartup*		: strategy = restoreOnStartup

	gPersistEveryDay*				: strategy = everyDay
}

If I define myItem to belong to gPersistEveryChange as well as to gPersistRestoreOnStartup, then the state of myItem will be persisted at every state change and will also be restored after openHAB restarts.

With the semantic model introduced in openHAB 3, an intermediate group item is created between the Things and the Items, to represent the Equipment.

Does group-based persistence in OH3 imply that group-based persistence must be implemented at Item level, or can it also be inferred at Equipment level? The former requires more configuration as every single item must be assigned to one or more persistence strategy groups. In the latter case, all items relating to the Equipment would inherit the persistence strategy…

19

Not sure I understand the question.

Persistence worldview -
"I don’t know nothing about these here semantics, see.
I know only about Items.
Some Items happen to be Groups, and have members.

Give me an Item name, I will persist its state, if it has any state.
Give me an Item name with a *, I will persist its member Items states, if there are any members.
That’s it."

Of course there’s a little more fiddly bit in matters of interpretation only - if we asked for someGroup* and one of its members is subGroup - do you get subGroup own state, or subGroup members state?
Answer, nested Groups with * specified work consistently. It would persist members of subGroup and not subGroup own state.

I believe the only way to get a Group state persisted is by directly naming it.

2 Likes
20

A common mistake that I just have not figured out how to help people avoid is assuming the semantic model means and does more than it really is capable of doing.

The only thing the model does is provide a meaningful hierarchy and a little extra meaning to the Items which are used to generate parts of the Overview Page and, if installed, HABot. That’s it. It doesn’t change how sitemaps work, how rules work, how persistence works or anything like that.

Given this, not everything needs to be nor should it be in the model. In this case, your persistence Groups would exist outside the model. But that doesn’t mean that Items that are inside the model cannot be a member of those persistence Groups.

The tl;dr between this and rossko57’s answer is that it’s worked as it always has.

However, in OH 3 there is one thing that has changed. I believe most (maybe all?) persistence add-ons now come with a default set of strategies. And if you make no other changes (e.g. migrating from OH 2.5 or have an addons.cfg) rrd4j will be installed by default and it’s default strategy is to save all (supported) Items every minute and on every change with restoreOnStartup. I know that MapDB and think InfluxDB also have similar default strategies. But if you create your own strategy through a .persist file, the default strategy is overridden.

2 Likes