Hi - I’ve got emonpi all running nicely locally here with a few weeks of data. External access is also set up and working using dataplicity. I’ve created my first system on heatpumpmonitor, it’s all approved and showing as public, but no data is appearing on the dashboard. If I try clicking the manual ‘Load rolling…’ or ‘Load monthly…’ buttons then I get a pop-up saying ‘undefined’. Have I totally missed a step somewhere or misconfigured this somehow? I’d love to contribute to the leaderboard but this part of the process is puzzling me!
Thanks for the reply but no, it was all self-installed and when I say emonpi, I should have said emoncms installed myself on an old Raspberry Pi hence I thought I should ask for help on here instead.
Your instance is very slow to load, and HeatpumpMonitor site looks to be timing out when trying to pull the data from it. Is there anything you can do to speed it up?
Edit: we have two other dataplicity systems listed, which are also slow, but load data okay. Must be something else.
I also see some data disappearing when zooming in on the power graph. Check that the feed intervals match the frequency they’re being written to.
Ta-da we have data, thanks! I think the step to make each feed ‘public’ was the one that did it. None of them had that option ticked, and indeed I didn’t notice that option was even available hidden there! Looks like it’s pulling in some data now though so thanks. Other changes I made were to specifically set the start date, and manually select each feed in the app rather than leave it on auto. Too many changes made at the same time to be certain which one fixed it, but there’s data flowing in now.
You mention setting the feed intervals to match the frequency of the data updates - yes that is an issue but I can’t see any easy way of editing the interval at all without deleting the feed and starting again. Is there an easy way to update it at all? When I set it up I just kept clicking until things started working, so I didn’t exactly put the correct values in at certain points of the process so would like to go back in and rectify that without destroying the feed totally.
Unfortunately it’s not possible to change the interval without recreating the feed. You could try creating a new feed with the right interval (or variable interval), and then importing the data from the old one. If the new feed still isn’t right, delete it and try again. Once you’re happy with it update the inputs. It’s a bit fiddly.
A cheap hack is to change log to log_join on the input which will fill in the gaps between values, but will result in odd artefacts when there’s an outage. Bit wasteful on space too, if that’s a consideration.
Thanks - I think the data gaps caused by excessive null data points is solved now by re-creating the feeds. Not a fun task! Export the old data but at a longer interval using averages to fill in any gaps, manually checking it for nulls, then importing into a new feed that’s using dynamic intervals. An option to change the interval would be a lot easier for users, but I guess rarely used so low priority in terms of where development effort should go! Thanks again anyway, all working well now.
Unfortunately, this is simply impossible due to the way the data is recorded and handled. In the Fixed Interval Timeseries, the start time and interval are recorded as metadata, then the time of each subsequent data point is calculated from start time + record number × interval.
I’ve thought for a long time that a stand-alone GUI application to do this and offer the ability to manually correct or draw in missing data points might be useful, but it’s progressed no further than the first thought.
It is possible to downsample feeds on a local emonPi/emonBase install using the post process module, I do appreciate this is not documented!
Setup > Post Process > Create new > downsample
Select the feed to downsample and enter in new interval:
You may want to do as I’ve done here and first create a copy of the original feed so as to test the process without overwriting the original feed, but it’s also fine to do directly:
There’s actually an average post process as well that effectively does the same thing but the code is different. I need to double check why we have those two different implementations.
