Strange caching of Web Page card viewing local static index.html page

Configuration
1

Hello - another strange problem here. I am using an AppDaemon Python script to create a static web page in /config/www/my_location/index.html. This updates index.html every hour.

The content of index.html is very simple:

<html>
<head>
<title>My Stuff</title>
</head> 
<body>
<h1>A heading</h1><ul><li>List item</li></ul>
<p>- End -</p> 
</body>
</html>

This is displayed on a dashboard web page card using the simple configuration:

type: iframe
url: /local/my_location/index.html
aspect_ratio: 100%

This displays fine. However changes to the page are never reflected on the dashboard. Update index.html - it shows the old contents. Reload the dashboard - it shows the old contents. Delete index.html - it shows the old contents. Delete the card and recreate a new one - it shows the old contents even if the file is still deleted. Reboot the HA host entirely - you guessed it, it shows the old contents. You get the idea.

Change the name to index2.html and change the card - it shows the new contents.

What is going on here? Where is the cache? How do I fix this?

2

My guess is that it’s the browser that’s caching the content. What happens if you force a refresh of the page?

3

It does seem to be the browser cache - thank you for the hint. Force refresh of the page - it shows the old content. Move to a Chrome incognito window - shows the new content, and updates each time index.html updates.

Question is then - how to fix this? I am mostly interested in how this will display on the Fully Kiosk browser on the main dashboard. This seems to mimic Chrome in behaviour.

4

I haven’t tried it, but apparently you can do a so-called meta-refresh

5

Nope - no effect. This does work refreshing other pages, I use it on other pages, but does not seem to work in this case. I Googled other ideas such as append a random string to the file to force refresh, but that also does not work.

I have index.html open in the file editor on HA, am editing it and then reloading the dashboard page - it is stubbornly unmoved.

6

You can maybe do it with JavaScript?

First set the iframe src to about:blank, wait a bit, and then set src to required URL.

Source

$(function() {
  function setframe(url) {
    var frame = $('.frame iframe').attr('src', 'about:blank');
    setTimeout(function() {
      frame.attr('src', url);
    }, 10);
  }  
});
7

OK this header seems to do the trick - adding the Cache-control meta (reference):

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="refresh" content="5">
    <meta http-equiv="Cache-control" content="no-cache">    
    <title>My custom web page</title>
  </head>
<body>

Thank you for your help.

This gives me new ideas for my other weird open question, in my blog-like question here. I am also suspecting a cache or cookies problem.

1 Like
8

Nice one! :slight_smile:

I’m glad I could help a bit, pointing the finger at the browser.

It’s always Chrome often the browser - causing problems :grinning_face_with_smiling_eyes:

1 Like
9

Unfortunately - this seems to be only a partial fix, sometimes. Today Chrome is back to caching the page and it does not reliably update.

@zenzay42 - perhaps I sound more knowledgeable about web & JavaScript than I am - how would I incorporate that script into a page?

10

You can embed JavaScript in the page by using the <script> tag. Either in the head section or the body.

I’m on my phone right now, so I’ll just give you a quick example:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My custom web page</title>
    <script>
      alert(“Hello Friend!“);
    </script>
  </head>
<body>
11

OK - thank you. That gives me a push.

However I tried, by accident actually, switching the two meta lines around and that seems to have made it work. ie. the meta refresh comes after the meta Cache-control. I can’t imagine why this would make a difference, but what do I know. Perhaps this is just a coincidence again, I will observe and report again.

12

Trial and Error. This is the way :grinning_face_with_smiling_eyes:

13

Yeah, this is not at all scientific - but logical trial and error. The AppDaemon is now running fine, every 15 minutes it pulls the calendar contents, and generates the HTML. The refresh in the HTML is set to 10 minutes, they are not synchronised which does not matter at this stage.

What seems to happen is the dashboard on a Samsung tablet, running Fully Kiosk, updates OK, but Chrome running on the desktop has some kinda bizarre caching that just does not show changes reliably. What really matters is the Fully Dashboard, but still this will aggravate my OCD so will be a challenge for after Easter.

The repository is now on GitHub if anyone wants to have a look.

14

I also had this problem, adding

    <meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
    <meta http-equiv="Pragma" content="no-cache" />
    <meta http-equiv="Expires" content="0" />

to the html page had no effect.

Browsers also adhere to the http headers sent by the web server.

After configuring the appdaemon webserver in /config/appdaemon/appdaemon.yaml like so:

http:
  url: http://127.0.0.1:5050
  headers:
    Cache-Control: max-age=30

It worked.

Oh, another thing I did wrong was I used Home Assistant base url instead of the appdaemon’s.

Hope this helps

15

I defeated this mess with adding a simple javascript to the static HTML file to append a unix time query string. It “stops” the page from loading too. Ignore the ampersand redundancy, it’s needed in my tablet browser for no reason. Added this to header.

    const urlParams = new URLSearchParams(window.location.search);
    const myParam = urlParams.get("poop");
    if(!myParam)
    {
    
        var redir_url = window.location;
        if(!urlParams.size)
            redir_url += "?";
        redir_url += "&poop="+Math.floor(Date.now() / 1000);
        location.href = redir_url;
        document.write("<!--");
    }