Lovelace: Home Feed Card

[Steven_Rollason]

I think the issue is with the combination of exclude_states and remove_repeats. The states are excluded before the repeats are filtered out. This means thatif you exclude “off” and the state changes from “on” to “off” and back to “on”, you will lose the second “on” state. Is this what you are seeing? I may be able to avoid this by changing the order of processing to this:

1. Exclude unknown states
2. Remove duplicates if option set
3. Exclude states defined in exclude_states

Unfortunately this will mean that “unknown” will always be filtered out, regardless of the exclude_states option.

[tom_l]

@Steven_Rollason

This means thatif you exclude “off” and the state changes from “on” to “off” and back to “on”, you will lose the second “on” state. Is this what you are seeing?

Yep that’s it. Except I don’t just lose the second ‘on’ I lose both. I only want to see one.

e.g. someone moving around in a room will cause many PIR ‘on’ / ‘off’ states, I only want to see the latest ‘on’. Then if they move to another room and move around there the top of the feed should be a single ‘on’ for that room.

As a test I tried removing exclude_sates and enabling remove_repeats and all I see now is repeats due to the show_history (as expected). This is exactly what I want - but without the ‘clear’ states.

card:
  id_filter: ^home_feed_.*
  max_item_count: 20
  scrollbars_enabled: false
  show_empty: true
  style: |
    ha-card {
      border: solid 2px var(--primary-color);
    }
  title: Last Movement
  type: 'custom:home-feed-card'
filter:
  include:
    - entity_id: binary_sensor.pir_*
      options:
        content_template: '{{display_name}} Movement {{state}}'
        include_history: true
        max_history: 20
        remove_repeats: true
type: 'custom:auto-entities'

It definitely has something to do with the interaction you are talking about. It’s just that it’s being a bit overzealous and not just removing the second ‘on’ state but both ‘on’ states.

[Steven_Rollason]

Can you try this with the new beta version, 0.2.10b3, and let me know if it is now working for you?

You may need to wait a short time or do a hard refresh of the page after updating to the new version for the updated logic to take effect due to caching.

[tom_l]

Upgraded to 0.2.10b3

Changed config to remove repeats:

card:
  id_filter: ^home_feed_.*
  max_item_count: 20
  show_empty: true
  style: |
    ha-card {
      border: solid 2px var(--primary-color);
    }
  title: Last Movement
  type: 'custom:home-feed-card'
filter:
  include:
    - entity_id: binary_sensor.pir_*
      options:
        content_template: '{{display_name}} Movement {{state}}'
        exclude_states:
          - 'off'
        include_history: true
        max_history: 20
        remove_repeats: true
type: 'custom:auto-entities'

Did a force refresh (Ctrl + F5) and now the duplicates aren’t being removed completely, but unfortunately they aren’t being removed at all

[Steven_Rollason]

What does it look like without the exclude_states? Does it show Clear states between the Detected states? In that case, I think the change in the order of processing so that the states are filtered after repeats are excluded means that the states aren’t being treated as repeats.

I notice that in your original comment you said:

if I enable remove_repeats for an entity it also removes the most recent entry as well.

The remove_repeats logic actually keeps the earliest entry (over the previous day) rather than the latest. If you try rolling back to the previous beta version, do you see the missing entries if you scroll down to the bottom of the feed? If so, I may be able to add an option to change this so it keeps the latest instead if this would help.

It also looks like the issue is partly related to the the sensitivity of the specific sensors and how often they are switching between Detected and Clear. Could these be smoothed out it any way, such as using a template binary sensor?
It may be possible to have an option in the card which filters out states which repeat within a period of time (e.g. if it changes to Detected, then Clear, then Detected within a 5 minute period) but this would be quite complicated to implement.

[tom_l]

@Steven_Rollason

What does it look like without the exclude_states? Does it show Clear states between the Detected states?

Yes it does:

card:
  id_filter: ^home_feed_.*
  max_item_count: 20
  show_empty: true
  style: |
    ha-card {
      border: solid 2px var(--primary-color);
    }
  title: Last Movement
  type: 'custom:home-feed-card'
filter:
  include:
    - entity_id: binary_sensor.pir_*
      options:
        content_template: '{{display_name}} Movement {{state}}'
        include_history: true
        max_history: 20
        remove_repeats: true
type: 'custom:auto-entities'

@Steven_Rollason

I notice that in your original comment you said:

if I enable remove_repeats for an entity it also removes the most recent entry as well.

The remove_repeats logic actually keeps the earliest entry (over the previous day) rather than the latest.

That’s the problem. It wasnt. It was removing every trace of an entity that had a duplicate entry in the feed. Now it’s not removing anything though.

@Steven_Rollason

It also looks like the issue is partly related to the the sensitivity of the specific sensors and how often they are switching between Detected and Clear. Could these be smoothed out it any way, such as using a template binary sensor?

They are wired PIRs. They come on for 3sec. minimum. Pretty smooth. No bouncing contacts, that’s just me waving my arms in front of the sensor repeatedly to test for duplicates.

[Steven_Rollason]

That’s the problem. It wasnt. It was removing every trace of an entity that had a duplicate entry in the feed. Now it’s not removing anything though.

I think max_item_count (which you have set to 20) may be the cause of this issue. Since the processing of remove_repeats happens before applying the max_item_count (which was a newer feature) the earliest Detected event for that entity may have not have been one of the 20 most recent events and been cut off. Can you try with the previous beta, but without that option set (or with it set to a higher value) and see if that is the cause of your issue?

If it is, I don’t know the best way to deal with that (other than potentially an option to control how much of the history to use, so you could just display the last 6 or 12 hourse, for example).

[tom_l]

@Steven_Rollason

the earliest Detected event for that entity may have not have been one of the 20 most recent events

Yeah it was (less than 1 minute ago). Not only that but newly created events did not show either.

On 0.2.10b2:

With this config:

card:
  id_filter: ^home_feed_.*
  show_empty: true
  style: |
    ha-card {
      border: solid 2px var(--primary-color);
    }
  title: Last Movement
  type: 'custom:home-feed-card'
filter:
  include:
    - entity_id: binary_sensor.pir_*
      options:
        content_template: '{{display_name}} Movement {{state}}'
        exclude_states:
          - 'off'
        include_history: true
        remove_repeats: true
type: 'custom:auto-entities'

I see:

If I wave my arms and trigger the lounge PIR it does not appear at the top of the list.

EDIT: A ha! The lounge PIR is on the list, much further down and listed as triggering 23 hours ago.

I think what is happening is that duplicates are being removed but only the oldest is being kept, not the newest!

[Steven_Rollason]

I have just published a new beta release 0.2.10b4, with a new option keep_latest (and also the filtering logic reverted to the original order). This option will keep both the newest and oldest occurrence when removing duplicates, use it like this:

card:
  id_filter: ^home_feed_.*
  show_empty: true
  style: |
    ha-card {
      border: solid 2px var(--primary-color);
    }
  title: Last Movement
  type: 'custom:home-feed-card'
filter:
  include:
    - entity_id: binary_sensor.pir_*
      options:
        content_template: '{{display_name}} Movement {{state}}'
        exclude_states:
          - 'off'
        include_history: true
        remove_repeats: true
        keep_latest: true
type: 'custom:auto-entities'

[tom_l]

I take it that keeping the oldest was actually what it was supposed to be doing. Keeping the first occurrence does make sense, just not in this case.

The new option works perfectly for this application. Thanks Steven!

[finity]

Just as a heads up for anyone who is doing an update from a previous version using HACS…

I suddenly found my “home-feed-card” giving me the “red box of death” error in lovelace. I pulled out my hair a bit trying to figure out why because I had not changed anything with this recently.

Then I realized that the file name in the installation directory has changed. Since that has changed then the entry in the resources section now needs changed from: “…/home-feed-card.js” to “…/lovelace-home-feed-card.js”.

I’m not sure when this changed or if it was announced here (I must have missed it) but changing the entry in the resources section fixed it.

No more red box!

[Steven_Rollason]

I don’t know exactly when this happened, but I think it may have been caused by a change to HACS rather than this card. The filename has always been lovelace-home-feed-card.js but HACS used to strip the lovelace- part when downloading it, but this is no longer happening.

[finity]

Maybe I’ll have to check all of my other lovelace components to see if the others that started with “lovelace-” did the same thing. I haven’t noticed anything obvious tho aside from your card.

Either way it’s fixed now so just wanted to put that out there in case anyone else had the same issue.

[tom_l]

Yeah it got me too.

@tom_l

Yikes! I upgraded to the beta version and did a force refresh of the page and got a nasty red Custom element doesn't exist: home-feed-card.

I didn’t notice that the resource had changed.

[tom_l]

Since updating to HA 0.98 I’m seeing a lot of glitching (no sensors were updating during this):

video

[Steven_Rollason]

Is it happening all the time?
I haven’t updated to 0.98 myself, but I’ll test that once I have to see if I can work out why it is happening.

[tom_l]

Yeah that random jitteriness is constantly happening. Both Chrome and Firefox.

It’s also happening with a simple home feed notifications card:

show_empty: true
show_notification_title: true
title: Notifications
type: 'custom:home-feed-card'

[Steven_Rollason]

I’m working on a new version which is refactored to use LitElement. I’ve updated to 0.98 and this version seems to display correctly.

This isn’t yet ready for a release yet, as there are some styling issues (such as the position of the dismiss button on notifications), but if you are willing to accept that, you can try it out by installing from the dev branch in HACS.

Edit: I have fixed the styling issues with this, so it is now released as 0.2.11b1

[Steven_Rollason]

Another new release - 0.2.11b2. The LitElement refactor lost the logic to apply the show_empty option, and this has now been restored.

Edit:

Third time’s the charm Version 0.2.11b3 has been release with a fix for an issue where the card would lose the config object.

[tom_l]

v0.2.11b3 has fixed my issue.

Thanks for the rapid response Stephen.

EDIT: Not conclusive but I think this card may be causing excessive CPU use.

Portainer showed the home assistant container responsible. Restarting HA did not change the excessive CPU use. Deleting my two home feed cards did. Coincidence? IDK.

EDIt: I’ve had no repeat of this since deleting both my home feed cards.