Replies: 3 comments 8 replies
-
|
It's difficult to say. This version is running for a quite long time (multiple months) on four devices without any issue. Are you sure, your SD is not already worn. Have you tried to use an new one. For me it seems that the device cannot read the file on SD card for some reason. Have you checked the logs?
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the prompt reply. Perhaps I didn't explain the issue succinctly. It appears I am unable to access the overview page (or any of the WebUI pages) after some time. It sometimes takes days for that to occur. Like I said in the previous message, I think I've correlated it to a Process Error Value being reported. This likely occurs if the character recognition is not accurate for that particular round and the raw value being reported is greater than the max value in the configuration file. What's strange is how that would kill the WebUI but not the rest of the functionality. I'll have to try to force some errors and see if I can pin down the exact failure mode. I do have a quick question though. I'm assuming your fork doesn't write anything during normal operation to the SD card if logging is not turned on, correct? I'm also assuming the only time the SD card is written to is when saving the configuration file, reference images, alignment markers, etc. If this is the case, I'm not sure how I'd be getting the failure mode I'm seeing because of a faulty SD card. |
Beta Was this translation helpful? Give feedback.
-
I understood that correctly. The message
Accessing to WebUI is not in any case related to process error. BTW: Which board are you using? Maybe you're device is getting hot and therefore SD is not behaving like when it's cold. Especially XIAO board is getting quite hot if no heat sink is used.
That's correct. Process related files are only read once after boot and then kept in RAM. Only config and image updates are written to SD card. But as I wrote all HTML files are instantly served when you access WebUI pages. Therefore they need to be readable all the time. |
Beta Was this translation helpful? Give feedback.
-
|
Using an ESP32Cam. Chip temp is reporting around 35-39 so I think that should be ok. Your explanation makes sense on why I am still getting active MQTT messages while not being able to access the SD card. I think I've said it before but when I was running the original firmware, I would occasionally getting a 3-2 blink error (SD Write Error). At that time I tried another card and several weeks later, same thing. When that error occurred, the entire firmware would hang... nothing from the WebUI, nothing coming from MQTT. Only a hard reset would recover it. That's what lead to some google-foo and I stumbled across your project thinking it may be the answer to my issues since I don't really need anything constantly being saved on the card (hence no "write" error) since I'm pushing everything to Home Assistant via MQTT. Since the first time this occurred, I've been hitting the WebUI from time to time, with no issues. I have Home Assistant set up to send me a text when the "Process Error Value" is non-zero. At that point I hit the WebUI to see what's going on and get the "oh oh message". Intermittent problems are always the tough ones to solve. I will try and dig up another SD card and try to see if that changes anything. |
Beta Was this translation helpful? Give feedback.
-
|
Were you able to solve your issues by replacing the SD card? |
Beta Was this translation helpful? Give feedback.
-
|
I replaced the card and added an an additional 220uF cap (giving me a total of 440uF) to the ESP32 Cam Board 5v supply. I was optimistic this had solved the issue. It ran perfectly for about a month, taking a reading every 1 minute. A few days ago I saw the "oh oh! This page does not exist! )" message when trying to access the WebUI. As before, the MQTT data continues to be transmitted to my broker. I power cycled the board and WebUI started responding as expected. Two day later (which is today), same issue. This seems similar to what I experienced before. After formatting the SD Card It will run, error free, for some time before getting the "oh oh! This page does not exist! )" message. Power cycling does correct it but the failure returns more frequently. Really strange. One feature I would suggest is add a feature that would facilitate Hardware Resetting the Board via MQTT. |
Beta Was this translation helpful? Give feedback.
-
|
I should also note I did receive the following MQTT message under "Value Status": "Changed to E92 Rate too high (<) | Value: 40411.8, Fallback: 40471.8, Rate: -59.0" a few hours before I noticed the WebUI was no longer responsive. I know we discussed this earlier and you didn't think these were correlated but I thought I'd mention it again. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to hear that it is still not fixed. I still believe this is somehow hardware-related, either SD card (which you have already replaced) or maybe SD card interface of the board (quality of those ESP32CAM boards is sometimes questionable)? I've never heard about such an issue before and I'm with this project for at least 3 years. Have you the chance to try another board? You're able to reboot the device remotely using the REST API |
Beta Was this translation helpful? Give feedback.
-
It seems the model misinterprets 7 as 1 or vice versa. It's mostly related to not perfect image quality or reflections. Try to have a good picture quality (not blurry and without reflection in the ROIs) and place the ROI properly. Have you tried using another model? BTW: There are quite some issues with newer ana-cont models 1300, 1400 and 1500. Do not use these models and try a different one if using one the mentioned. Please have a look to issue report in jomjol repo. |
Beta Was this translation helpful? Give feedback.
-
|
Yea, not really sure what to make of this. Question: When I got the Value change to Changed to E92 Rate too high....", would something be written to the SD card at that point. If so, this may be another indicator that something is going on with the SD card is the root of the issue. I believe I have everything in the configuration file that writes to the SD card disabled but I didn't know if these types of errors trigger an SD write. I forgot about the REST API reboot. Since my device was still only responding with MQTT messages since last night I though I'd try to reset it with that. Unfortunately, the whole device hung during reboot, stopping even the MQTT messages and was flashing out the 3-2 code. Weird thing is, I power cycled the device and all is working, at least for now. I may have a flakey board. I have some spares that I may try to swap out. Not the easiest task since I really didn't design my 3D printed enclosure with the idea of an easy swap of the board but I may have to roll up my sleeves and give it a go. As for the model, I'm using the digi-class11_1910_s2_q. I am reading LCD digits from a water meter. For the most part I think it's been working quite well. Like I said before, it ran a whole month, taking a reading every minute without an error. Now if I could only figure out this WebUI hanging situation. At least, when the WebUI hangs, MQTT messages are still being transmitted so I'm still able to have my automation achieve the goal of determining if too much water is being used (a leak!), when I'm away. |
Beta Was this translation helpful? Give feedback.
-
There are just a few parameters which could result in a SD card write when this status occurs.
Not directly related to mentioned status:
If these parameters are disabled, no SD card write is performed at this stage. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Guten tag:
Thank you for forking this project with an emphasis on limited SD card writes. Over that past few months, the original AI-On-The-Edge-Device projects would randomly hang with a 3-2 blink code which was an SD write error. I don't have a need for saving anything locally so your project seemed to fit the bill BUT.......
After a short period of time (about a week or so) I've noticed that on two occasions this version of the forked software reported a Process Error Value of "1". After that, when I try to access the WebUI I get the "oh oh! This page does not exist! )" message. So obviously, the program is still running and able to serve something. Also, the MQTT messages appear to keep updating. The only way to revive the WebUI is a hard power down - power up reset. Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions