anyone know how to get the flukso to read a negative reading for those that have the clamps in a net metering position dues to the solar installation?

delete me

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)

In the http headers of the http://flusko.net requests the header X-Frame-Options is set to DENY.
This causes the image upload popup in the forum to fail to display on modern browser, and disables the on-the-fly attachment processing.

I think they should be considered to be turned off for at least the /img_assist/ and /upload/ html resources.

In nginx this is possible with

location ~* ^/(img_assist/.*|upload/.*)$ {
add_header X-Frame-Options "SAMEORIGIN";
}

Validate the exact security and performance implications for yourself please!

The more refined successor is the frame ancesotrs directive (https://www.w3.org/TR/CSP2/#directive-frame-ancestors)

Hello everyone,

So I'm doing an internship at a company that uses Flukso's in multiple locations to show their usages. My project is to visualize and store the data from all the flukso's.

I started with MQTT, got a flukso to send the data through node-red to influxDB and show it in Grafana. Easy enough but in this way I would have to port forward every flukso not on the same network which isn't possible in every location.

So I guess I should use tmpo (from tmpo-py on github). I get an error in the s.sync() line and I don't have a clue as to how to fix it. Can anyone help me?
In the error.txt you'll find the error I'm getting, I haven't changed the tmpo.ipynb file except for token and sensor ID.
Also any more info on tmpo or anything on this subject would be appreciated and a confirmation if tmpo-py would solve my problem would be lovely.

Thank you!