From time to time I experience some problems with my flukso box.
It works just fine but sometimes my chart on the dash just stops and
I have to unplug my box and plug it in again.
After 5 minuts every thing works as expected, except I get a straight
line on the chart for the time it was out.
What could be the problem here?
I get the same issue normally after a power outage even for a brief moment. To make it work again I have to turn off power to Flukso and on again to reset.
seeing this is posted in the "Flukso would need to " section... I would request an auto reset IF no output transmitted for "X" time.
Bazzle
That is indeed a good idea! And the brief power outage explains it for me :)
Had the same issue; the FLM seemed faster than the router after an outage, then didn't catch up with the NTP service. So it seems there shall be a refresh on the DHCP and NTP service if it presumably did not catch up...
+1 on Bazzle
Regards, Markus
@gebhardm Did you try reproducing the issue on your setup by power cycling the router and FLM at the same time?
@bazzle What if your internet connection goes down? The FLM should then buffer the readings, not repetitively restart itself. Restarting an FLM blindly is not the cure. Pinpointing the root cause of an issue instead will help to fix it in a next firmware release.
@Bart: At 18:00 I did a simulated power outage (switched off the breakers of the corresponding circuits were cable modem, router, and the FLMs are attached to); both my FLMs synched their time base after 00:01:18; the modem and router were up before that. So it seems to be not as easy as that.
The power outage with the actual failure was more tricky than above condition; while our street had power already, parts of our village can up later. That means that there might be something in the way of the, for example internet cable, that came up later - that is practically impossible to re-test.
What I experience is, that after simulation at the moment I do not get a minute display on neither FLM (nothing happens when switching to the minutes dash) - that was also after the real outage, but came back some time by itself... (now it is 18:30)
Thanks for testing, Markus.
Addendum: Dates and times run completely out of sync!
System Time [UTC]
Fri Nov 30 19:11:02 2012
Flukso server ping test succeeded
Last synchronisation time [UTC]
Wed Nov 21 18:57:50 2012
Last synchronisation status
successful
Sync mismatch did not change even after cold reset. Both FLMs have a sync failure now. Funnily the hour dash looks ok, but access to the minutes tab is not possible. I leave it alone now...
Doing a plain save in the sensor config this morning now successfully synched my FLMs; displayed times and days are within the expected range...
Had the same a few weeks ago, also clicked 'save' in the sensor config to fix this.
I think there's a misunderstanding here. The FLM only needs to synchronize with the sensor board and the Flukso server when the sensor configuration has changed. A synchronization is automatically triggered when the local sensor page is saved. In other words, it is perfectly normal that the last synchronization time is older than the system time (= 'now' according to the FLM).
...but it shouldn't be Jan 1, 1970 , or?
(on my second FLM)
For clarity's sake: Synchronization time is not related to synchronizing clocks. It's the timestamp of the most recent synchronization attempt of the sensor settings.
Why so annoyed? Sorry to bother you... So back to the fact, that after an outage the FLMs did not come up in the way they should. And others seem to experience a similar behavior. So, I gave some indication what is not comprehensible for me as a user. As it is open source, well, anybody can look into the code - if there is nothing else to be done...
I did not realize my comments came across as me being annoyed. Sorry for that. I was trying to focus on finding and fixing the root cause. And be very clear about things that were not relevant.
1/ If the issue is related to NTP not setting the FLM's time correctly, commit 820cba should fix this. I originally thought the problem only occurred with Belgacom's Bboxes. That's why I wanted to get clear confirmation that a terminating ntpclient process was indeed the culprit.
2/ It should become easier to get debugging info out of a remote FLM, even if you're not tech-savvy. Any input for this feature is very welcome.