Mirror/AI-on-the-edge-device-docs
1
0
Fork 0
mirror of https://github.com/jomjol/AI-on-the-edge-device-docs.git synced 2025-12-12 14:37:09 +03:00
Code Issues Packages Projects Releases Wiki Activity

Fix typos and small inconsistencies (#12)

Browse Source 
Co-authored-by: CaCO3 <caco3@ruinelli.ch>
This commit is contained in:
tljuniper
2023-02-03 20:35:37 +01:00
committed by GitHub
parent 7c599658cd
commit 7c3821357f
29 changed files with 140 additions and 147 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/FAQs.md
View File

@@ -6,7 +6,7 @@ There are several reasons for the reboot:
* Frequent HTML requests
* Wrong configuration, missing configuration files
* Unstable hardware - see [[Hardware Compatibility]]
* Unstable hardware - see [Hardware Compatibility](../Hardware-Compatibility).
There is a dedicated page about this: [Frequent Reboots](../Frequent-Reboots/).
@@ -38,9 +38,10 @@ As mentioned above, the AI algorithm is not perfect. Sometimes it may read an in
We can tune the software to _almost_ never report an incorrect value. There is a tradeoff though: the software may report _stale_ values - i.e. it will drop incorrect values for a potentially long period of time, resulting in the meter reading being outdated by hours. If never receiving an incorrect value is important to you, consider tolerating this tradeoff.
You can change the following settings to reduce incorrect readings (but potentially increase staleness of data):
* Set a prevalue via the UI, then change `PostProcessing` configuration option `PreValueAgeStartup` to a much larger number (e.g. `43200` = 30 days).
* Change `PostProcessing` configuration option `MaxRateType` to be time based instead of absolute. Set `MaxRateValue` to something realistic (e.g. `5` gal/min). You can often find the max flow rate your meter supports directly on the cover.
* Reduce `AutoTimer` configuration option `Intervall` to the lowest it can be (e.g. `3` min). The more often you take readings, the less likely for data staleness to occur.
* Reduce `AutoTimer` configuration option `Interval` to the lowest it can be (e.g. `3` min). The more often you take readings, the less likely for data staleness to occur.
## Even after I have setup everything perfect there is a false reading - especially around the zero crossing (roll over to next number)
* The roll over behavior is different for the different meters. E.g.:
@@ -48,7 +49,7 @@ You can change the following settings to reduce incorrect readings (but potentia
* The neutral position (no rolling) is not perfectly at zero, but rather at something like 7.9 or 8.1, even if it should be exactly 8
* The "PostProcessingAlgo" is trying to judge out of the individual readings, what number it should be.
* For example if the previous number is a "1", but the next number seems to be a "8.9", mos probably there was a "zero crossing" and the number is a "9" and not still an "8"
* For example if the previous number is a "1", but the next number seems to be a "8.9", most probably there was a "zero crossing" and the number is a "9" and not still an "8"
* Currently the setting of the algorithm is set to fit most of the meters and cases. But the parameters do not fit perfectly for all situations. Therefore there might be intermediate states, where the reading is false.
This is especially the case, at the positions, where the roll over (zero crossing) is just starting.
@@ -56,8 +57,3 @@ You can change the following settings to reduce incorrect readings (but potentia
Usually after some time and movement of the counters a bit further, the reading is getting back to a stable reading.
* To handle this, a parametrized setting would be needed. This is rather complicated to implement as subtle changes make a relevant difference. Currently this is not implemented.
So please be a bit patient with your meter :-)