I’ve been working on customizing the Belchertown skin for my particular site using data from my Tempest, my webcams and my PurpleAir sensor(*). I’m looking for feedback, areas of improvement, etc. I’m also curious to see if the rpi I’m using as a webserver bursts into flames once I get some people hitting it. That’s largely why you’ll notice that the main page is actually one giant iframe. The pacificaview.net site is hosted on a real webserver/webhost and the iframe is displaying the page from my local rpi. To avoid having rsync to my webhost every few minutes I’d like to see what happens with my rpi handling it. But if the rpi gets overwhelmed I can just start rsyncing to my webhost instead of redirecting to my rpi. Note that I did integrate and enable MQTT support which greatly mitigates the rsync issue.
(*) While I did integrate the weewx purple and aqi extensions, so those values are now being calculated, stored and available through weewx - after doing a bit of research on the AQI numbers, PurpleAir and the new “EPA Conversion” that PurpleAir provides, I decided for now to just include the PurpleAir widgets for my station on the page.
It looks good to me! Loading was fast, and everything is up to date. I like the addition of AQI, that has been a big revelation to the weather community in the last year - air quality is an important weather metric that people should see a lot more frequently. We love lightning strikes, but you are far more likely to die of lung cancer exacerbated by pollution than you are by lightning strike.
A few issues/suggestions:
Websockets connection for live updating isn’t working for me, it gives “Connecting to weather station real time data”, but doesn’t actually connect.
Do you need to show both Realtime and 10 minute average AQI? You could probably drop Realtime and then move the smaller frame alongside another frame for a cleaner look.
I like the tide addition and the realtime image - in my mind, they’d be even better if the image was smaller and it was side-by-side with the tides.
Thanks so much for taking the time to look at it and provide thoughtful feedback!
Regarding the websockets - when where you testing? Just now? And/or did you have the page open yesterday? Last night I switched MQTT and websockets to use a secure connection because I also enabled https for my site, and it was rejecting the insecure websockets from a secure webpage. it took me a while to get everything configured and working together after I made the switch. Possibly try doing a shift-reload and see if that clears things up? If not, definitely let me know so I can try and fix it.
Regarding the realtime and 10-minute - that’s not actually the difference between the two charts (or at least it’s not the main reason/difference I’m providing both). I tried to explain it in the AQI information section on my About page. The difference is that the one on the left (the “realtime”) is applying the new US EPA conversion factor PurpleAir introduced to get their numbers to more closely match AirNow, especially when woodsmoke is a large part of the pollution. Due to some details about how the conversion is made, PurpleAir can only do it for real-time, not for any of their normal time averages. So what I’m trying to do is provide both a converted/compensated number that is supposed to more closely match the EPA’s AirNow reporting, as well as the normal PurpleAir number with no conversion.
Interesting thought on the realtime image side-by-side with the tides. But if I did that, then I wouldn’t have a reasonable place for the current sea conditions - unless I made the image really small and put all three on the same line. But I’ll play around with the layout and sizes more. Part of the reason I have the large image is because originally I didn’t have the extra “webcams” page - and local people (surfers, fishermen, beachgoers) like the big version of the image to get a good/detailed idea of conditions. But now that I have the webcams page, possibly I could have the large images there and just a small version on the homepage. The other minor thing about combining the image with the tides is the refresh rate. Due to the way the belcherskin provides “hooks” to add your own sections (such as I have done) and provide refresh rates for those sections, if I put the two together they would refresh at the same rate. I’d like the webcam image to update fairly frequently, but the tide-chart doesn’t need to update very frequently at all (and since I’m hitting another site’s server to do that, I also don’t want to be a “bad citizen”). I could certainly code around it with some effort.
You should use Let’s Encrypt and move to https for any internet-facing site. Super easy to set up once and automate, and it keeps itself updated hands-off automatically.
Yes, as I alluded to in my reply to sam.ley I made that change yesterday on the “underlying” webserver (mixdivr.org). The main site (pacificaview.net) is a a full-fledged, web-hosted system and was already set up for https. Though I just realized I forgot to update the iframe to point to the https version of mixdivr.org - just fixed that.
I haven’t yet forced it to always use https - I wanted to work through updating MQTT and websockets to be secure first, and then do a more thorough check to see if anything else gets messed up with the secure version. After that I’ll force it to https.
Quick update from my view - the websockets connection does not work if I’m at your main URL, but if I open the iFrame content directly then the socket connects and I get realtime data as expected. I’m not sure why that would be but hopefully it is a troubleshooting datapoint for you.
As for your other points, all good ones, my suggestions were just my initial impressions. As for the AQI, I suppose my original point still remains - two numbers that are similar but not the same call the data into question in people’s minds - I’d recommend picking whichever one you deem “most authoritative” by whatever criteria you want, and displaying only that one. That might free up a little horizontal room as well. Your call, of course!
Thanks for the feedback and debugging help. Unfortunately I still can’t replicate your results. I’ve tested it going through pacificaview.net both via http and https and both are working OK. I also tested by going over the cellular network in case there was some type of routing-shorting that was going on when I testing from home. That worked also. I’m curious what browser and OS you’re using? My tests so far have been on various browsers on macos and iOS.
As for the AQI, thanks for the feedback. I’m still on the fence. The problem is there seems to be no consensus as to what’s “right”. And the most common recommendation is to use the US EPA conversion when there’s a lot of wood smoke involved, but use the unconverted number otherwise. The other problem is that the US EPA converted version only provides realtime results, whereas the unconverted provides the average over different time periods. So, I dunno - it seems like having both numbers is useful, but I agree it’s also confusing. I’ll have to ponder that some more.
Well, I tried in a few more locations and it looks like it might be just the machine I’m on, which is a work-provided Windows machine running latest Chrome (86.0.4240.111). However, when I try on one of my Windows VMs in both Chrome and Firefox I’m getting the expected result over http and https, in both browsers using the pacificaview.net url. Linux VM seeing expected results in Firefox (didn’t test Chrome).
If it was as simple as my work computer’s firewall blocking the connection, then why would it work when directly connected to your pi? Hmm…
Well, either way, my other machines all see the live updates fine, so the issue is at least somewhat isolated, rather than a universal issue. If I think of anything to try I’ll let you know.
That’s largely why you’ll notice that the main page is actually one giant iframe. The pacificaview.net site is hosted on a real webserver/webhost and the iframe is displaying the page from my local rpi. To avoid having rsync to my webhost every few minutes I’d like to see what happens with my rpi handling it. But if the rpi gets overwhelmed I can just start rsyncing to my webhost instead of redirecting to my rpi. Note that I did integrate and enable MQTT support which greatly mitigates the rsync issue.