Logbook missing entries that are in the database

Configuration
1

I’m using MariaDB as my database in my HassOS/Supervised HA install (0.111.4 currently), and I’m trying to understand why some of my entities’ state changes aren’t showing up in my logbook. Many do show up properly, but in this case, I’m focusing on an MQTT template sensor defined like this:

- platform: mqtt
  state_topic: 'monitor/fr-beacon/iphone'
  value_template: '{{ value_json.confidence }}'
  unit_of_measurement: '%'
  name: 'iphone_fr'

My recorder: integration is set up like this:

db_url: mysql://xx:xxx@core-mariadb/homeassistant?charset=utf8
purge_keep_days: 5
exclude:
  domains:
    - automation
    - weblink
    - updater
    - zwave
    - media_player
    - script
    - weather
    - light
    - switch
  entities:
    - sun.sun
    - sensor.date
    - sensor.time
....

There are lots of other excluded entities below, but not sensor.iphone_fr.

history: and logbook: are enabled via default_config: without being explicitly called out in my configuration.yaml.

I expect sensor.iphone_fr to be recorded by default (I only exclude other entities) and I see them in my MariaDB “states” table:

MariaDB [homeassistant]> select * from states where entity_id = 'sensor.iphone_fr';
+----------+--------+------------------+-------+-----------------------------------------------------------------------------------------------+----------+---------------------+---------------------+---------------------+----------------------------------+-----------------+
| state_id | domain | entity_id        | state | attributes                                                                                    | event_id | last_changed        | last_updated        | created             | context_id                       | context_user_id |
+----------+--------+------------------+-------+-----------------------------------------------------------------------------------------------+----------+---------------------+---------------------+---------------------+----------------------------------+-----------------+
|  2832269 | sensor | sensor.iphone_fr | 90    | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3552356 | 2020-06-18 18:00:08 | 2020-06-18 18:00:08 | 2020-06-18 18:00:08 | 82ae3afa3d1d4e67af384b3bbc1d9d9e | NULL            |
|  2832274 | sensor | sensor.iphone_fr | 100   | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3552361 | 2020-06-18 18:00:14 | 2020-06-18 18:00:14 | 2020-06-18 18:00:14 | 2fd42f465b4d433dba4549c050651c57 | NULL            |
|  2832867 | sensor | sensor.iphone_fr | 90    | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3552960 | 2020-06-18 18:10:08 | 2020-06-18 18:10:08 | 2020-06-18 18:10:08 | 2fa528a430564eb4888c950000b3983e | NULL            |
|  2832871 | sensor | sensor.iphone_fr | 45    | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3552964 | 2020-06-18 18:10:14 | 2020-06-18 18:10:14 | 2020-06-18 18:10:14 | ff8ce7686d154bbfafd533d6acd89ca9 | NULL            |
|  2832873 | sensor | sensor.iphone_fr | 0     | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3552966 | 2020-06-18 18:10:15 | 2020-06-18 18:10:15 | 2020-06-18 18:10:15 | c7683ae1ad0a411f8b0f339a621d253c | NULL            |
|  2832945 | sensor | sensor.iphone_fr | 100   | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3553038 | 2020-06-18 18:11:20 | 2020-06-18 18:11:20 | 2020-06-18 18:11:20 | 05bb9fc77dbd442db32d5d7386c30bf4 | NULL            |
|  2833132 | sensor | sensor.iphone_fr | 90    | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3553226 | 2020-06-18 18:14:28 | 2020-06-18 18:14:28 | 2020-06-18 18:14:28 | 312048387d1a49e0ad9b1b560ca5bdb4 | NULL            |
|  2833142 | sensor | sensor.iphone_fr | 45    | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3553236 | 2020-06-18 18:14:35 | 2020-06-18 18:14:35 | 2020-06-18 18:14:35 | 0773949ea451481081c87d9bae83430f | NULL            |
|  2833145 | sensor | sensor.iphone_fr | 0     | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3553239 | 2020-06-18 18:14:38 | 2020-06-18 18:14:38 | 2020-06-18 18:14:38 | 8b20164fdb564a6ab7e1ac2bba117b90 | NULL            |
|  2833204 | sensor | sensor.iphone_fr | 100   | {"unit_of_measurement": "%", "friendly_name": "iphone_fr", "device_class": "signal_strength"} |  3553298 | 2020-06-18 18:15:45 | 2020-06-18 18:15:45 | 2020-06-18 18:15:45 | ddf9a27d908a4d999338a0df82316d45 | NULL            |
+----------+--------+------------------+-------+-----------------------------------------------------------------------------------------------+----------+---------------------+---------------------+---------------------+----------------------------------+-----------------+
10 rows in set (0.001 sec)

You can see the state changing from time to time for sensor.iphone_fr, where last_changed == last_updated.

I can see the state changing in the history tab:

image

image

But I get “No logbook entries found.” when I pull down the Entity drop-down and select sensor.iphone_fr. The very fact that it shows up in the entity dropdown tells me that it knows about it, but seems to be filtering it out of the list for some reason. Changing the duration from 1 to 3 to 7 days doesn’t help.

Other entities are acting the same way, including another very similar MQTT sensor, and a min_max sensor that aggregates the two.

Anyone know why?

2

Sensors with units display in history, not the logbook.

3

Wow, interesting. I guess that’s to prevent the logbook from being spammed with numeric sensors changing frequently. I was just looking through the code and saw this:

                    # Don't show continuous sensor value changes in the logbook
                    if _get_attribute(hass, entity_id, event, "unit_of_measurement"):
                        continue

Thanks for the pointer! The documentation doesn’t mention that, so I’ll submit a PR to add it.

1 Like