Tagged: log journal restart
August 7, 2017 at 4:02 am #47390
I’m Fabien from Toulouse (France).
I speak English bad, then i will try to explain my problem “thank you https://translate.google.fr :)”
I have intalled my Opensprinkler v3 last month, whitout problem.
It works good, but a few weeks ago, when I read the journal log (Android App or web application), the blue led (beside wifi module) flashes once, and the system restart by himself.
I have reset the system, after backup my configuration, and the log working again.
The last week, same problem. Read Log > the blue led flashes once > Restart by himself.
Apart form this problem, the system works great (programs, preview programs, run manually, etc…)
Do you know this problem and how to solve it ?
FabienSeptember 18, 2017 at 6:56 am #47729
We are aware of the issue as a few other users reported similar problem. Because it’s not a common problem, we haven’t been able to reproduce the issue but I suspect it has something to do with reported access to the flash memory in a short amount of time. While we are investigating this issue, a temporary work-around is to delete the log when this happens. Below are the details:
The API to delete all log data is:
where x.x.x.x is your device’s IP, pw= gives the password (in MD5 checksum form). To obtain the MD5 checksum, you can use any online MD5 checksum calculator, such as this one:
type in your password as a string at the bottom, and compute it. The MD5 password is generally a 32-byte string (for example, it may look like ABCDE12354…..)
You can also manually obtain the log data in raw format by using the following API:
which requests the log data of the past 7 days. In the cases reported, it seems manually obtain the log data in raw format works fine. You can verify it by using the above API.September 20, 2017 at 8:17 am #47810
It’s very possible the SPI FLASH memory chip inside the ESP8266 is not behaving well. I have done a number of ESP8266 IOT device developments the last year and can confirm that it’s very hit or miss on how well the SPI memory chip behaves. I see were using the file system library to use a portion of the FLASH as storage space. This in theory should work but obviously the quality of the flash is really the thing were all dependent upon.
In earlier systems with an SDCARD you could remove it and reflash. The above API helps to clear the space but if the bit cells inside are marginal then there is not much you can do. That is a fundamental issue with these low cost WiFi systems. The quality of the components under the hood. I have a new AC 3.0 system and I have been playing with the logging as well. It works for me but I am not convinced it will continue to do so based on my earlier experience. ESP8266’s are great hobbyist systems but they have their limitations IMHO.
I have the system sitting on a desk and will let it run for a couple of weeks before I try to rely upon it to run my system. Yeah I’d a bit pessimistic but like I said early on – I have a bit of experience with the ESP8266 ecosystem.October 8, 2017 at 11:30 am #47954
One thing we can improve on is the number of reads of the log data on each ‘view log’ request. Currently every time you click on ‘view log’ it makes 3 requests, one for the regular log data, one for watering level data (wl) and one for flow data (fl). This was done to make it easy for the UI to calculate average watering level and so on. But the downside is that reading the log three times in a roll incurs a lot of overhead, and I suspect it’s also relevant to the rebooting issue reported.
While I agree there may be some quality control issue with ESP8266, I think its reliability can be improved in software. Also, the fact that it’s extremely inexpensive make it easy to replace if any problem occurs. OS3.0 uses separate top-bottom layer design, so if the top layer (containing ESP8266) has any problem, it’s pretty easy to toss it out and replace it.
You must be logged in to reply to this topic.