I’ve been plagued by this for what seems like forever, where a box pops up on the inputs page of emoncms telling me it couldn’t create a device since it already existed!!! Aside from not asking it to create a device I already know that said device already exists, but it blocks the page until I click “ok” (even though it isn’t!) and then to add further insult to injury it cycles through every device telling me the same damn thing. Until now it’s been “annoying” that on the occasions it happens, especially when it then goes into a second, third or fourth lap or more!
There are several references to it on the forum and also github issues, both open and previously closed as “fixed”. But although clearing redis and/or clearing the browser cache sometimes clears the problem temporarily, it doesn’t always and sometimes it takes several stabs so I’m not convinced these actions are directly resolving the issue (even temporarily) and that perhaps something just gets nudged along the way.
Last week I set up a RPi 3B+ with a desktop for a specific task and happened to open emoncms in chromium. The inputs page was absolutely unusable in any way, shape or form. The first error box would be there within seconds and continuously loop endlessly through my inputs. I couldn’t even get a button click in to collapse the inputs to get a better picture let alone scroll down the page.
At this point I fired up my usual PC and found that the input page of that same emoncms instance was currently working fine in Chrome, no device exists errors! Convinced it could be a result of the RPi’s limited power I swapped it out for a 4GB RPi4, same sdcard, also in the same location on the same WiFi. That was still “unusable” IMO but it was better, I could at least get the occasional button press in. this convinced me I might be on to something and decided to pursue further rather than giving up.
For info purposes, the emoncms instance I was using is NOT updated, Nor shall it be any time soon as I do not have the time for the ensuing consequences of updating. However!!! I tried the above tests with an emoncms.org account and got exactly the same results (on the Pi3B+ but the Pi4 wasn’t so bad), so I’m not too concerned about the version of emoncms I’m running at this point.
Using the dev mode of chromium I could see the order of events on each page refresh (autorefresh not manual “reload” type refresh) and by blocking the url/path
device/create.json I was free of all those annoying boxes, as tempted as I was to stick there, I continued by looking into the code of
emoncms/Modules/input/Views/input_view.js and whilst I have no real understanding of Ajax or JS, I came to the conclusion that it probably wasn’t a good idea for the content of an as yet unfulfilled request to be compared to another potentially unfulfilled requests data and therefore edited 2 Ajax calls to be
async: false rather than
async: true which I understand allowed the code to continue without waiting for a response, as both the
device/list.json data and `input/was to be accessed in the line immediately after sending that request I couldn’t see how it could be reliable.
Since editing those lines on my outdated instance I have had no error messages on the Pi4 at all, whilst I do still get them from emoncms.org when reverting back to the RPi3B+ despite the local instance being error free, slow as a glacier, but error free and usable with patience.
The 2 lines I changed were
This issue is definitely way more apparent on the Pi3B+, even emoncms.org is causing errors very frequently. Where the Pi is situated the wifi signal is at it’s limit, so if anyone wants to recreate the issue on demand to try and fix/test, use the least powerful device eg a RPi3B+ (or less) with desktop and if needed maybe shield from wifi to cause a slower connection? I just recalled the Pi4 is 5GHz wifi not 2.4GHz, maybe that helped too?
I’m not a emoncms dev so I have no idea if I’m circumventing another issue, it seems logical to me NOT to try and user data that might not yet be available unless there is a fallback plan ie don’t reset everything if said data isn’t yet available which is what appears to be the case here.
I read this to basically, if revised data or existing data for confirmation purpuses isn’t yet available obliterate existing data with empty and/or false fields.
I have no doubt using
async: false might be slower, but I see no other way, there is no point in the page refreshing faster if that means false errors.
Having written this long post I have just been back to the RPi3b+ with input pages open at my local instance as well as emoncms.org and my local instance is still error free whilst emoncms.org has a error box.
I will raise this on GitHub (with a PR?) for formal consideration but if anyone has any thoughts or any experts can confirm or rule out my findings that would be great.