Modern browsers have started blocking loading javascript over http when embedded in a website served with https. (mind the "s") This is because otherwise nefarious actors (hotspot trap, ISP, government, ..) can inject any javascript code in the page/app.
This impacts the dashboard real-time info (the "Minute" tab), browsers will not show any data (in fact on my system it will retain the previously displayed graph) and show the message "Error - The call for sensor totaal experienced a timeout. You are probably not in the same local network as the FLM."
In broad strokes there are two ways to fix this and still retain the realtime-as-local properties:
1) Serve the json over https from the flukso. uHTTPd supports this and it works reasonably well on Openwrt machines. However, there might be severe performance/load penalty - I haven't tested this on my flukso yet.
2) Load the dashboard page for this section (or at least the graph part) directly from the flukso. This requires modifying the flukso website and having a part of it on the flukso. If this is minimalist enough it could be stored on the flukso, but I think a minimalist reverse proxy would be worth considering too. It's very easy to set up just a tcp or http proxy specifically to the www.flukso.net host and have it serve the required elements from there over plain http.
Eventually it needs to be integrated in the existing dash (iframe, new window or something better).
Edit: I just noticed https://github.com/gebhardm/flmlocal which takes the local-serving local-copy route.
3) Serve the flukso.net dashboard over plain http (ugh..)
4) Users can undo the blocking in the per-site settings. For now this is just a few clicks in the UI, but I'm sure this will eventually be relegated to the deep settings in the browsers.
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content/How_...
(Apologies if this is an elsewhere addressed issue)