I installed openHAB2 beta5 on Ubuntu 16.10 last night to begin learning about the new version so I can prepare to migrate from my existing openHAB 1.8.3 system. Initially, I have only created items for the Yahoo Weather service and set up the MySQL persistence service. This morning I noticed that there are many sets of adjacent rows for the Yahoo Weather items that have the same value. It seems rows are being created roughly every 3 or 4 minutes, rather than on a change of value. The jdbc.persist file on the OH2 system looks like this:
// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
// if no strategy is specified for an item entry below, the default list will be used
everyMinute : "0 * * * * ?"
every5Minutes : "0 */5 * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
default = everyChange
}
/*
* Each line in this section defines for which item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* item (excl. the group item itself).
*/
Items {
// persist all items once a day and on every change and restore them from the db at startup
* : strategy = everyChange, everyDay, restoreOnStartup
Looking at this file I would expect there to be a new row every time the item value (the entries below are temperature in centigrade, it’s winter here in the UK) changed and another entry at 00:00 every day.
Example DB rows from my openHAB2 system:
| 2017-01-02 05:45:28.716 | 0 |
| 2017-01-02 05:50:30.705 | 0 |
| 2017-01-02 05:54:29.174 | 0 |
| 2017-01-02 06:00:28.663 | 0 |
| 2017-01-02 06:03:28.683 | 0 |
| 2017-01-02 06:07:30.121 | 0 |
| 2017-01-02 06:09:31.949 | 0 |
| 2017-01-02 06:12:29.588 | 0 |
| 2017-01-02 06:17:28.719 | 0 |
| 2017-01-02 06:26:28.717 | 0 |
| 2017-01-02 06:33:28.745 | 0 |
| 2017-01-02 06:39:28.832 | 0 |
| 2017-01-02 06:51:32.470 | 0 |
| 2017-01-02 06:54:30.509 | 0 |
| 2017-01-02 06:57:28.746 | 0 |
| 2017-01-02 07:07:28.713 | 0 |
| 2017-01-02 07:12:28.765 | 0 |
| 2017-01-02 07:15:28.710 | 0 |
| 2017-01-02 07:18:28.709 | 0 |
| 2017-01-02 07:22:28.734 | 0 |
| 2017-01-02 07:25:28.709 | 0 |
| 2017-01-02 07:27:28.712 | 0 |
| 2017-01-02 07:30:28.746 | 0 |
| 2017-01-02 07:38:29.831 | 0 |
| 2017-01-02 07:44:28.785 | 0 |
| 2017-01-02 07:46:31.019 | 0 |
| 2017-01-02 07:52:28.740 | 0 |
| 2017-01-02 07:55:28.740 | 0 |
| 2017-01-02 08:02:28.889 | 0 |
From my openHAB1 DB:
| 2017-01-02 03:15:21 | 1 |
| 2017-01-02 05:15:20 | 1 |
| 2017-01-02 06:15:23 | 0 |
| 2017-01-02 08:15:25 | 0 |
| 2017-01-02 11:15:20 | 0 |
Actually, now that I look at the DB entries side by side, there are sets of adjacent OH1 rows that contain the same value, there are just far fewer rows per set than in the OH2 system.
Is this expected behaviour? Does the Yahoo Weather service return a temperature with a decimal place that is truncated when written to the DB but triggers a change event?