restoreOnStartup to preserve config Item states

[rkoshak]

Changes include:

• define what addons to install using $OH_CONF/services/addons.cfg which should make upgrades easier in the future. addons.cfg takes precedence over what is done through PaperUI/REST API so no changes need to be made to the SD image.
• added the MapDB Persistence add-on so we can restoreOnStartup
• created a mapdb.persist file to set the policy to save and restore the states of all the members of the RestoreOnStartup Group, all updates to these Items get saved to the database which shouldn't be that often.
• modified default.items by adding a RestoreOnStartup Group Item and added all the setting Items to that Group
• hvac.rules, generic.rules:
  • Rewrote the initialization Rule to only call the script or initialize the setting Items to a default when it is NULL or UNDEF.
  • If the Item already has a state because of restoreOnStartup or because the .rules file is being reloaded, sendCommand with it's current state so the UI picks up the setting.
  • The rewritten Rule illustrates the sorts of things that can be done using lambdas. These are local to the Rule but lambdas can be made global and shared between Rules.
  • I also added some logging to see when the Rule starts and stops and to see which Items are initialized with scripts or defaults and which ones are restored from mapdb.
  • The C TempType only checked that the setpoint was < 40 and the F TempType only checked that the setpoint as > 32. I modified to test both a max and a min for both (0 < setpoint < 40 for C and 32 < setpoint < 100 for F) TempTypes.
  • Because we only go out to the shell for those Items that are NULL and UNDEF, the rule should run faster after the first boot. On the first boot of OH all the Items will be NULL or UNDEF. The System started Rule will initialize them all with the defaults that were already being used. That initialization will become captured by MapDB as will any changes to these Items. The next time OH starts up, it will see that the Item already has a state and not call the script to initialize it.

Everything seems to check out on my system. It's really nice not to lose the settings on a restart. It also is a nice way to see when the System started Rule starts to run as the display switches from the default showing "Off" to the version with the three icons at the top and my restored setpoint value. I wonder if one could/should use a command from OH in this System started rule to change from the "HestiaPi is starting" display to functional?

In the future, I'd like to understand why the UI requires commands to show the current settings correctly given that the MQTT messages are sent with the retained flag set. When the UI comes up it should pick up the most recent setting values from MQTT automatically when it connects to the broker. But that's for later.

Solves Issue #8.

Signed-off-by: Richard Koshak rlkoshak@gmail.com

[rkoshak]

Shoot! Somehow this undid a bunch of changes. I was sure I was up to date with ONE but I guess not. I need to fix the .rules files and the .items file. Hold off on the review until I fix that stuff.

[gulliverrr]

I'm off to bed. Won't touch anything until you say so and it doesn't have to be today, so no rush.

[rkoshak]

OK, the diffs now look right. There are no-unintentional changes, ready for review.

[rkoshak]

Now I lost one of my changes. StringType cannot be sent as a command so the lambdas at the top of the Rule need to use toString. This should be the last commit. To this PR until there is a review.

[gulliverrr]

@rkoshak For EU/Generic systems, humidity control and hot water have the following same issue:

• Web UI shows correctly the state as ON
• LCD UI shows incorrectly the state as OFF (icon stays white)
• Pin and relay is OFF

[rkoshak]

I'll take a look at this later today. But given this branch has been merged we probably should open an issue and I'll submit a fix in a new PR.

[rkoshak]

Could you go to #31 and post the contents of openhab.log from when you change the Humidity mode? Also verify that HumidityType has a valid value. If not I may need to add something to the initialize rule to make sure that happens as it should. I'm not seeing the same behavior.