Temp/Humidity item reporting 0 around the same time every day

Setup, Configuration and Use Beginners
1

  • Platform information:

    • Hardware: Raspberry Pi 4
    • OS: Raspian (IOTstack)
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version: 2.5.9

  • Issue of the topic: Everyday around the same time in the morning (but not exact) the kitchen humidity and temperature both read 0. I cant figure out what can be causing this and would be greatful for some suggestions. The sensor is a standard aqara temp/humidity/pressure sensor that connects via MQTT through zigbee2mqtt and mosquitto to Openhab. I have checked and there is no MQTT message in the zigbee2mqtt logs that has a zero value. So something else must be setting this value to 0. In the openhab.log i can see mapdb (strategy everyChange) storing this 0 value in the db. However I cant tell where this is coming from. From all the items that I am tracking this is the only one that behaves funny. Shortly after I get an actual reading from the sensor and all is good again. However this 0 value is messing with my graphs in Grafana as everyday there briefly is a drop to 0.

  • If logs where generated please post these here using code fences:
    influxdb records with a 0 value

> select * from Keuken_Humidity where value = 0
name: Keuken_Humidity
time                     value
----                     -----
2021-04-19T05:05:07.401Z 0
2021-04-19T11:44:17.061Z 0
2021-04-19T12:00:00.19Z  0
2021-04-20T05:03:14.438Z 0
2021-04-21T05:00:15.218Z 0
2021-04-22T04:58:15.89Z  0
2021-04-22T05:00:00.51Z  0
2021-04-23T04:56:16.486Z 0
2021-04-23T05:00:00.542Z 0
2021-04-24T04:54:17.087Z 0
2021-04-24T05:00:00.567Z 0
2021-04-25T04:52:17.819Z 0
2021-04-25T05:00:00.589Z 0
2021-04-26T04:50:18.468Z 0
2021-04-26T05:00:00.615Z 0
2021-04-27T04:48:19.15Z  0
2021-04-27T05:00:00.64Z  0
2021-04-28T04:47:19.773Z 0
2021-04-28T05:00:00.664Z 0
2021-04-29T04:45:20.397Z 0
2021-04-29T05:00:00.689Z 0
2021-04-30T04:43:18.735Z 0
2021-04-30T05:00:00.759Z 0
2021-05-01T04:41:19.241Z 0
2021-05-02T04:39:19.991Z 0
2021-05-03T04:37:20.627Z 0
2021-05-04T04:35:21.157Z 0
2021-05-04T05:00:00.023Z 0
2021-05-05T04:34:21.893Z 0
2021-05-06T04:32:22.514Z 0
2021-05-06T05:00:00.147Z 0
2021-05-07T04:30:23.148Z 0
2021-05-08T04:28:23.757Z 0
2021-05-08T05:00:00.226Z 0
2021-05-09T04:27:24.252Z 0
2021-05-10T04:25:25.065Z 0
2021-05-11T04:24:50.972Z 0
2021-05-12T04:22:51.662Z 0

openhab.log (system time difference between influx container and openhab container of 2 hours)

2021-05-12 06:21:28.560 [DEBUG] [pdb.internal.MapDBPersistenceService] - store called for Keuken_Humidity
2021-05-12 06:21:28.562 [DEBUG] [pdb.internal.MapDBPersistenceService] - Stored 'Keuken_Humidity' with state '55.21' in mapdb database
2021-05-12 06:22:51.644 [DEBUG] [pdb.internal.MapDBPersistenceService] - store called for Keuken_Humidity
2021-05-12 06:22:51.660 [DEBUG] [pdb.internal.MapDBPersistenceService] - Stored 'Keuken_Humidity' with state '0' in mapdb database
2021-05-12 06:47:39.132 [DEBUG] [pdb.internal.MapDBPersistenceService] - store called for Keuken_Humidity
2021-05-12 06:47:39.139 [DEBUG] [pdb.internal.MapDBPersistenceService] - Stored 'Keuken_Humidity' with state '55.17' in mapdb database
2

Do you see the Item changing to 0 in events.log?

Since MapDB cannot be used to generate charts what it’s doing is largely irrelevant. What persistence are you using as the default?

Connect an MQTT client such as MQTTExplorer and review the actual messages published to the topic around that time. Verify that a 0 is not being published.

Review any rules that reference this Item. Could they be running to update the Item to 0?

1 Like
3

I had another look at my events.log and noticed something I missed before. An update of gKeuken (kitchen group) to 0. Which are the lights that are switch off 30 minutes after sunrise. The kitchen humidity and temperature item were part of the same group… I removed them from the group and should no longer have the issue. Because the rule is based on sunrise it explains why it shifted a couple of minutes every day :slight_smile:

Thanks

2 Likes
4

Updating Group never affects member Items (unlike commands to Group).
It saves confusion if you show us what you see.

5

Although I wrote “update” it is actually a command given to the group from Node-Red.

6

Since it’s pointless sending commands to sensors anyway, you could just disable autoupdate on the sensor Items so that commands no longer affect Item state, and keep the Items in the Group.

1 Like
7

I am not yet familiar with disabling auto update but will look into it, as removing them from the group impacts some other things. Thanks for the suggestion.