Lovelace: Home Feed Card

[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.

[jwelter (John Welter)]

Same for me on 98.

[Steven_Rollason]

That’s strange about the CPU use. I have the home feed card on the home page of my Lovelace UI and Home Assistant running on a Raspberry Pi 3 B+. The highest the CPU usage of the hass process has got up to was around 30%, and that was only briefly, most of the time it’s around 1-2%

I am currently running a version of the code which I have not yet released, which includes a fix to the click handler code. There was previously the possibility that it could create multiple instances of the click handler which may cause memory and/or CPU issues (but this would more likely affect the computer you are accessing the Lovelace UI from and not the Home Assistant server).

I have not yet released this fix, but you can test it by installing the dev version from HACS.

If that doesn’t help, can you let please let me know some details of the config of your cards (number of entities, whether you were including history, etc) as it may be some combination which is causing high CPU usage.

Another possibility could be having multiple browsers displaying the Lovelace UI on a page with the home feed card. These could end up simultaneously calling the history API and could put a higher load on the server.

[hsepm (Holger)]

I have the simplest of configurations and can reproduce the high CPU load (30%) with the latest release 0.2.11b3 and 0.98.

- type: 'custom:home-feed-card'
  title: ""
  show_empty: false

Removing the card and restarting the HA server brings the CPU utilization into the long term average of 4%. Running UBUNTU server on an Atom Z8350 mini PC with hassio in docker.

[DendelX]

same here, I have a lot of css customization on this card and I thought that it’s my fault but I see that default configs has same glitching.