I’ve been investigating this issue; and so far I have found the following;
Every time I see the connection error pop up, at the same time the Apache error log shows:
[Sat May 07 08:08:12.438067 2016] [:error] [pid 17667] [client 192.168.11.5:45158] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461
Investigating the feed_model.php the line in question is:
$time = floor($bufferdata[$z]/$outintervalms)*$outintervalms;
$outintervalms is generated from this line (a few lines up in the code)
$outintervalms = $outinterval * 1000;
So the variable that is actually a problem is $outinterval
$outinterval is not checked, so its value could in theory be set to anything, after some poking about I was able to determine that the variable is being set to “0”, and this is causing the divide by zero error.
Using TCP dump - I was able to capture the following hits against the Apache web server from the mobile app:
GET /emoncms/feed/data.json?id=6&start=1462608366000&end=1462608470655&interval=0&skipmissing=1&limitinterval=1&apikey=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa HTTP/1.1
I suspect that this is the root of the issue, what isn’t totally clear is if the mobile app sets the “interval” variable or if this is passed form the server in the first place, while I can handle a bunch of coding, android apps seem to be beyond me still…
In true Star Wars fashion… help me @JumpMaster, you’re my only hope…
I can confirm similar errors in my server log too;
[Sat May 07 09:34:40.991690 2016] [:error] [pid 6647] [client 220.127.116.11:14429] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461 [Sat May 07 09:34:40.991951 2016] [:error] [pid 6647] [client 18.104.22.168:14429] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461 [Sat May 07 09:34:40.992408 2016] [:error] [pid 6647] [client 22.214.171.124:14429] PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/emoncms/Modules/feed/feed_model.php:461) in /var/www/emoncms/index.php on line 186
After digging through the app source, here is the issue;
Starting line 339 of app/src/main/java/org/emoncms/myapps/MyElectricMainFragment.java
int npoints = 1500;
final int graph_interval = Math.round(((endTime - startTime) / npoints) / 1000);
graph_interval is the variable that we see getting set to 0 in the requests made by the app, using the information from the URL I posted earlier we get:
(((1462608470655 - 1462608366000) / 1500 ) / 1000 ) = 0.06977 and when this is rounded, it makes 0
I’d suggest we spring another variable for the “interval” as used in the URL, and create some basic math around that, so that any value less than 1 is rounded up to 1, that should solve the Connection Error messages without messing up the rest of the app.
I’m happy to write some proof of concept code for that and create a pull request if that helps.
The one thing I am not totally sold on, is who’s problem this actually is, while the app is making a sane request all be it with a non sane value of zero, the back end should be checking the variables too in order to stop divide by zero from happening, and it doesn’t yet.
The server side should output some sort of error when you make the request with a zero value. I guess thats another discussion
@JumpMaster - Yes I believe that is where the issue is, its the “interval=0” that is the problem.
I don’t believe the interval should ever be 0
The back end should either give you an error on receiving the 0 value - or it should handle / ignore it.
I’ve not read any of the details of the API at this point, so I can’t tell you which is at fault - but both ends of the software should be able to handle a zero value (I would assume).
@glyn.hudson - the PR I made is only one possible solution, its not a good way to deal with the issue at hand - consider it the last resort and more of a pointer to where the issue may lay for someone who knows emoncms better than I do.
Also to note the HTTP API (Volley) is doing a JsonArrayRequest so is only successful if the response is json. So CONNECTION ERROR can be caused by connection issues or an unrecognized response. I may have to look at doing a different type of request and converting it to a JSON array if successful. I could then give more useful error messages.
@JumpMaster - Yes thats it alright, loaded the app onto my phone, tcpdump shows the “interval” variable set to 1, and without my fix in place I have no errors in the apache log.
So that is definitely the variable in question.
The variable as passed to the back end has to be something greater than zero or you get a divide by zero error, the question is what side is correct. If the maths in the app is correct and zero is the correct figure, then we need to fix the back end to deal with that (or ignore it in the case of a zero value etc).
Thats an open question to those of you who know emoncms better than I do.
I’m on the beta channel, and got a prompt to update a few minutes ago, but the disconnections still persist as before.
Apache log shows; [Sun May 08 23:07:20.732615 2016] [:error] [pid 18150] [client 126.96.36.199:30870] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461 [Sun May 08 23:07:20.732946 2016] [:error] [pid 18150] [client 188.8.131.52:30870] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461 [Sun May 08 23:07:20.733343 2016] [:error] [pid 18150] [client 184.108.40.206:30870] PHP Warning: Division by zero in /var/www/emoncms/Modules/feed/feed_model.php on line 461
Is there anywhere in the app where you can display the installed version/build number?
EDIT - Just deleted the app & re-installed, still the same.
This seems to have fixed the Android app connection issues, and the ‘divide by zero’ errors filling up the apache log. I have asked @TrystanLea to look over it, he knows Emoncms processing better than I do.
That’s strange, I haven’t tried the PR myself, but I thought that @JumpMaster had set the interval to 1 instead of 0 in his recent app update (which duplicates what this PR does), and which doesn’t appear to fix the problem for me.