Log Tab
- Thread starter TCoach
- Start date
- Tagged users None
The log tab was added back in post 2.0 reef-pi. It exist to aggregate and visualize any UI client side specific errors in reef-pi that are not core controller related. For example if you have an ato chart set in UI while the original ATO is deleted , or if you try to do some operations from UI that fails on validation (on UI side only) and does not propagate till backend. i.e no main controller function is impacted or not originating from there (like driver loading error or temperature sensor failure). All core controller, serious and persistent errors go under the configuration -> error section. All client side, not series, may be user behavior induced , transient errors are aggregated inside the "log" section.
In retrospect it is confusing, now. When it was built we had lot of those type of errors which will otherwise go way (since in ui those errors are transient modals), unless we give them a place to stay there so that user can check and clear easily. Vast majority of those errors are gone since UI has stabilized significantly, and the user/community has itself matured enough that we just dont see folks doing crazy things in UI
.
I intend to delete that section unless theres any concern.
does that answer your question?
sincerely
ranjib
In retrospect it is confusing, now. When it was built we had lot of those type of errors which will otherwise go way (since in ui those errors are transient modals), unless we give them a place to stay there so that user can check and clear easily. Vast majority of those errors are gone since UI has stabilized significantly, and the user/community has itself matured enough that we just dont see folks doing crazy things in UI
. I intend to delete that section unless theres any concern.
does that answer your question?
sincerely
ranjib
OP
OP
TCoach
Well-Known Member
How about changing the use to let us know what the reef-pi is doing? This would be very helpful and possibly enlightening. Maybe only keep 7 days of data since it could be a large amount?The log tab was added back in post 2.0 reef-pi. It exist to aggregate and visualize any UI client side specific errors in reef-pi that are not core controller related. For example if you have an ato chart set in UI while the original ATO is deleted , or if you try to do some operations from UI that fails on validation (on UI side only) and does not propagate till backend. i.e no main controller function is impacted or not originating from there (like driver loading error or temperature sensor failure). All core controller, serious and persistent errors go under the configuration -> error section. All client side, not series, may be user behavior induced , transient errors are aggregated inside the "log" section.
In retrospect it is confusing, now. When it was built we had lot of those type of errors which will otherwise go way (since in ui those errors are transient modals), unless we give them a place to stay there so that user can check and clear easily. Vast majority of those errors are gone since UI has stabilized significantly, and the user/community has itself matured enough that we just dont see folks doing crazy things in UI
I intend to delete that section unless theres any concern.
does that answer your question?
sincerely
ranjib
Time Item Note
<date time> main pump turned off
<date time> macro abc started
<date time> ato turned on
<date time> macro abc ended
<date time> ato turned off
.
.
.
Etc
that is a good idea. although know that such things will cost pi cpu (because its a constant stream of I/O). But yes, this is a good use. For what is worth, the telemetry integration already does this (grafana/adafruit),
Sorry I'm a little confused how this would cost CPU? The entries can be saved to the database so there should be no limit, load the table from it when someone opens the tab.
There will be io wait or buffer management induced cpu cost . Other than network connection and that you are constantly streaming data.
Cpu is not just for pure logic processing. It’s used for all io including network . You can’t do anything without cpu penalty specifically any io. It may be negligible but it should be of concern for our case. As this is not a mission critical task and we have little headroom with cpu spikes , particularly in pi zero .
I was not even thinking about database . Just network streaming . With database involved it will be even higher cost than just serving those things from memory to network ignoring wear and tear of the sd card. I don’t see any value in storing such transitional data in database. Only the final step is logged in database for persistence (like state of ato )
OP
OP
TCoach
Well-Known Member
This should not really be true. Most devices you control with reef-pi are not being touched most of the time.
I’m not saying every temp, pH or other sensor reading gets added. More so, when a control activity is done. I.e:
1. Equipment/Outlet state changed
2. Macro executed
3. ATO start/stop
4. Lights on/off/major levels
5. Doser runs
there may be a couple of others I can’t think of right now, but that should be pretty close. Personally, I know this sort of data would be extremely valuable. Especially when setting up new equipment/routines and when troubleshooting.
True.
meanwhile you can hook up a lamp to test whether a control event is happening or not during setup
attiland
2500 Club Member
I think logging everything would be excessive however can be useful. Certainly I would not put it into the database but you can put it to txt file in the memory as there is plenty space there only downside when you restart it is lost. You could even limit the size let’s say 1000 entry.
On pi4 cpu usage less than 1%
"Certainly"...
CPU never goes about 3-4% on Pi3 and most of that isn't reef-pi. I hear other reasons but this sounds like more of an excuse. ;Woot
