custom-cards / secondaryinfo-entity-row

Custom entity row for HomeAssistant, providing additional types of data to be displayed in the secondary info area of the Lovelace Entities card

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Extremely slow on mobile if templates are used

covrig opened this issue · comments

commented

If templates are included, the lovelace frontend becomes slow and almost impossible to use.
I tried this on 3 different Android devices, and a couple of different browsers. On a Desktop everything is OK.

I included 5 templates on a view (last triggered, state of a socket etc.), .
Other views work OK since to secondary info is present.

- entity: automation.fridge_door_alarm
    type: "custom:secondaryinfo-entity-row"
    secondary_info: 'Door is: [[ if(binary_sensor.door_window_sensor_158d0000f125f7 == "off", "Closed", "Open") ]]'

- entity: automation.store_work_hours_googledrive
   type: "custom:secondaryinfo-entity-row"
    secondary_info: "Trigger: [[ automation.store_work_hours_googledrive.attributes.last_triggered ]]"

- entity: group.office_lights
   type: "custom:secondaryinfo-entity-row"
   secondary_info: "Trigger: <b style='color:red'>[[ input_number.office ]]</b> lux (slider). Now: <b style='color:red'>[[ sensor.illumination_158d0001e07ed4 ]]</b> lux. PC: <b style='color:red'>[[ sensor.pc_power ]]</b> W"              

Not seeing any issues on my end, but I don't have access to any Android mobile devices - just iOS. Is this still a problem for you?

commented

Yes, the issue is still present. Basically templates introduce some delay when toggling or clicking something.
The more templates, the longer the delay. In my case it takes about 30 sec to toggle a switch. In the meantime everything becomes unresponsive.

Facing the same issue, it seems it start when I use it more than once in a View.

I also have slowness issue on Chrome (PC) on a view that use it 16 times

@covrig
I added about 16 secondary row resulting very slow on mobile as well as chrome.

Chrome cpu hit about 50% on i7 processor. it seems something looping to refresh

commented

Yep! On mobile is unusable.

found this section of code took about .5 sec to process and repeat every 2 second

        async _updateElement(wrappedElement, hass) {
            if (!wrappedElement) return;

            this._wrappedElement.hass = hass;
            await this._wrappedElement.updateComplete;
            await this._wrappedElement.shadowRoot.querySelector("hui-generic-entity-row");
            let secondaryInfoDiv = this._wrappedElement.shadowRoot.querySelector("hui-generic-entity-row").shadowRoot.querySelector(".secondary");
            if (secondaryInfoDiv && this._config.secondary_info) {
                let text = window.cardTools.parseTemplate(this._config.secondary_info, {entity: this._config.entity});
                secondaryInfoDiv.innerHTML = text
            }
        }

As much as i would like to help but my JS is not even half bake. Again thanks for great tools

I might have found a solution, at least that works for me.
I need to have it running for a few days to make sure, but just out of curiosity, are you using HA behind a Proxy? If so, Apache or Nginx?

Yes behind proxy. Apache2.4.

commented

I see no difference before (local IP) or after the proxy.

So what I've been thinking for a while (noticing that using Apache was sometimes make the connection fail and slowing everything), is that each page or proxied connection was remaining "open" for some reason.

Therefore after re-reading the Apache Proxy docs I found this option "disablereuse=On" to be interesting, basically it close the connection as soon as the request is completed, this should prevent Apache to keep a big amount of opened connection towards the proxied path.

So, long story short, I added that to the ProxyPass line:

  ProxyPass / https://127.0.0.1:8123/ disablereuse=On
  ProxyPassReverse / https://127.0.0.1:8123/

And now not only the secondary_info_row is not causing any issue on mobile and Chrome (with 16 entries), but the overall experience of navigation in HA has become very quick and "snappy".

I hope this will fix the problem for you too, for me and for now, it seems to have done the trick!

mine look like this.
my Apache take the ssl cert because I got multiple site proxy


		  ProxyPass /api/websocket ws://192.168.xx.31:8123/api/websocket connectiontimeout=5 timeout=60 disablereuse=on
		  ProxyPassReverse /api/websocket ws://192.168.xx.31:8123/api/websocket
		  ProxyPass / http://192.168.xx.31:8123/ disablereuse=on
		  ProxyPassReverse / http://192.168.xx.31:8123/ 

Did you already had that option or you just added it? Is it helping with this issue?

Did you already had that option or you just added it? Is it helping with this issue?

It been like this for 1 year i think
Maybe i try localhost when possible

That shouldn't make much of a difference since you're still using the IP address of the same server, interesting is that you're facing the problem while this change fixed it for me

That shouldn't make much of a difference since you're still using the IP address of the same server, interesting is that you're facing the problem while this change fixed it for me

It work for 5 or 6 secondary row... Once I crossed 10 it started slowing down. At 15, I can barely use it on the phone. I track the cpu the code above taking about .5 second(10).. as time exponentially increase when you add more. up to 3 sec at 20 secondaryrow.
It seems like the code loop multiple times, in the power of number.
I think each time it refresh the data, it loop all secondaryrow to find the match 1 and update single row. So if you have 20 secondaryrow, it loop all 20 secondaryrow 20 times to update all row.

@MizterB, it is how the loop works ?

That shouldn't make much of a difference since you're still using the IP address of the same server, interesting is that you're facing the problem while this change fixed it for me

I updated HA from 0.100.3 to 0.101.3 and the issue is gone. CPU now normal and mobile works...

So what I've been thinking for a while (noticing that using Apache was sometimes make the connection fail and slowing everything), is that each page or proxied connection was remaining "open" for some reason.

Therefore after re-reading the Apache Proxy docs I found this option "disablereuse=On" to be interesting, basically it close the connection as soon as the request is completed, this should prevent Apache to keep a big amount of opened connection towards the proxied path.

So, long story short, I added that to the ProxyPass line:

  ProxyPass / https://127.0.0.1:8123/ disablereuse=On
  ProxyPassReverse / https://127.0.0.1:8123/

And now not only the secondary_info_row is not causing any issue on mobile and Chrome (with 16 entries), but the overall experience of navigation in HA has become very quick and "snappy".

I hope this will fix the problem for you too, for me and for now, it seems to have done the trick!

I know this is an older reply but I am using this and have lots (about 40) of the secondary info used. I'd like to see where you had put this code to correct your issue. Thank you

In my setup I am using Apache as Reverse Proxy, it is not an HASSIO installation but an HA Virtual Python Environment, therefore this might be different.

If you're using Apache as reverse proxy, you'll need to edit the Apache config used to create the ReverseProxy itself (usually in /etc/httpd/conf/ or /etc/apache2/conf/ (or conf.d))

If you're using Hassio and Nginx Reverse Proxy from the Hassio integration, you'll need to check how to do the same on Nginx and the configs changes would need to happen in the integration configuration.

I revisited this issue and found i have connection timeout set compare to suggested.

So i removed mine and it is slightly better. 'connectiontimeout=5 timeout=60' i dont know here i got it from.

		  ProxyPass /api/websocket ws://192.168.xx.31:8123/api/websocket disablereuse=on
		  ProxyPassReverse /api/websocket ws://192.168.xx.31:8123/api/websocket
		  ProxyPass / http://192.168.xx.31:8123/ disablereuse=on
		  ProxyPassReverse / http://192.168.xx.31:8123/ 

It's possible to reduce the update frequency of the custom component? In my opinion the update calls are the root cause of this issue. If I add a single custom:secondaryinfo-entity-row item to a dashboard the api/template endpoint gets called multiple times per second (cp. screenshot). A dashboard with multiple secondaryinfo-entity-row items becomes very unresponsive because of the heavy traffic/load. In my case it would be fine to retrieve every secondary info just once.

update-calls