MapDB Persistence Configuration with nested Groups

Setup, Configuration and Use Items & Sitemaps
1

Hi everyone,

I have a new problem since OpenHAB 5.0 (no issue with OpenHAB 4). Following persistence configuration:

configurations:
  - items:
      - mapdb_change_restore*
    strategies:
      - restoreOnStartup
      - everyChange
    filters: []
cronStrategies: []
defaultStrategies:
  - restoreOnStartup
  - everyChange
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

I have an Item with the following configuration (a group switch for another switches) with ID ventilation_management:

label: Ventilation Management
type: Group
category: switch
groupNames:
  - mapdb_change_restore
  - influxdb_change
  - ventilation
tags:
  - Equipment
groupType: Switch
function:
  name: OR
  params:
    - ON
    - OFF

The group ventilation is another group:

label: Ventilation
type: Group
category: fan
groupNames: []
tags:
  - Equipment
groupType: None
function: None

The group mapdb_change_restore looks as follows:

label: 000 MapDB Change Restore
type: Group
category: ""
groupNames: []
tags: []
groupType: None
function: None

With OpenHAB 4 the switch value from ventilation_management was written and restored correctly. With OpenHAB 5 the value either never gets persisted or never gets restored (did not manage to look into the mapdb files yet). Every other item in the group mapdb_change_restore gets persisted. Any ideas? Is this a new bug or did the behavior of grouped persistence configurations change?

There are no errors or warnings in the log whatsoever.

Cheers,
Daniel

  • Platform information:
    • Hardware: ARM Raspberry Pi 4
    • OS: Ubunto 24.04
    • Java Runtime Environment: openjdk 21.0.6 2025-01-21
    • openHAB version: 5.0.0-M1
2

Tried some szeanarios. It is not related to MapDB, the same behavior exists with any other persistence service like RRD4j. Found out that the value of ventilation_management never gets persisted itself, but the children of this switch group do. So it seems the handling of switch groups (or groups in general) changed in terms of persistence. This would be ok in case of a switch aggregation, since the value depends on its children. But this is not working when restoring the states after a restart. I guess I have to file an issue.

3

It’s always been the case, as long as I can remember, that the states of Group Items are not saved nor restored unless the Group Item is separately listed in the strategies. Being the member of a Group whose members are configured to be saved and restores isn’t enough.

Furthermore, a Group’s state is calculated from the states of it’s members. There would never be a reason to restore the state of the Group independently. It’ll get calculated when all it’s members are updated. I’m not sure that it’s even possible to update a Group Item, only command it, for that very reason.

If there is a problem here, I suspect it has to do with the fact that the Group’s aggregation function is not calculating the new state for the Group when it’s members get restored. I don’t think persistence ever updated such a Group Item indipendently.

4

There was a change in behaviour, but it should be fixed with Fix restoring nested group items from persistence by mherwege · Pull Request #4651 · openhab/openhab-core · GitHub

So far, all the nested items (down to the lowest level possible) in the group if not a group itself would be persisted and restored. The group state would then be recalculated when restoring. As we now can also restore last state, last state update and last state change, this could not be restored for a group item and the group item recalculation was missed in the original PR. The linked fix will also now also store the nested group items (not the group itself) if they have a state and restore these explicitely. Any state change to an item in the group will still lead to recalculation.

See linked issue: Persistence Configuration with nested Groups: restore on startup broken · Issue #4649 · openhab/openhab-core · GitHub

2 Likes
5

Thanks Mark for clarification. Looking forward for M2. :slight_smile: