I believe it this happened this past Wednesday where it was working and now no longer does.
I have a EmonPi running at work and at home both with Dataplicity and both have been working for months.
Suddenly it no longer works and below is what I now get.
And I get this at home and at work.
But if I log in while on the same subnet it works as expected both at home and at work.
This leads me to believe:
-it is not EmonPi itself because it works if I type in their IP address while on their subnet.
-same symptoms at home confirm this is not something IT at work did.
Have same problem across multiple Emonpis on different networks. Worked OK on Thursday as I set up a unit. Didn’t work yesterday when I tried the same thing with another one. Then found a common problem across all Dataplicity linked devices.
One thing I could not figure out with Dataplicity is how to pass parameters (specifically the read only key) so that I could allow others to access the dashboard without having to provide credentials.
I noticed that it’s the browser blocking the css and js files as it says these are not being encrypted properly as per https requirements. It is possible to temporarily bypass but probably not recommended.
We were relying on the $_SERVER parameter ‘HTTP_X_FORWARDED_PROTO’ or apache_request_headers equivalent to state ‘https’. For some reason this has changed and it’s coming through as ‘http’.
Parameter ‘HTTP_X_FORWARDED_PORT’ however is coming through as the correct port for https (443) and so I’ve added a check for this as well. If it detects either HTTP_X_FORWARDED_PROTO == https or HTTP_X_FORWARDED_PORT == 443, emoncms will now return paths with https at the start.
For a couple of years or more I’ve been successfully using …
It’s free for upto 5 devices
Here’s my ‘control screen’. If I click on HTTP at the far right for node 15 then the emon Data Viewer comes up. Another of the HTTP’s brings up the OpenEVSE charger for example.
Our apologies for inconvenience you’re experienced caused by that issue, we already found it and have deployed a fix.
As pointed out by @TrystanLea, the issue arose from a recent infrastructure upgrade, which resulted in the export of HTTP_X_FORWARDED_PROTO http instead of https. Big thanks for your help. We appreciate it much.
Also thanks for everyone who pointed out the issue and reported it to us. It helped to solve the problem fast. Please not hesitate to contact us in future through chat on our main page in case of any problems or questions.
