chiefwigms / picobrew_pico

MIT License
149 stars 63 forks source link

Session chart using days as the time variable #290

Closed jdmbeer closed 3 years ago

jdmbeer commented 3 years ago

nginx.access.log picobrew_pico.log session

fired it up today and started a brew. It appears that the time variable is using days since my last brew instead of time. shows april 4th as brew start instead of 4/25

tmack8001 commented 3 years ago

What actually appears to have happened here is that the session wasn't "closed successfully" and thus data was appended to the existing session file.

@jdmbeer what version are you running? This information is available on http://<server-hostname-or-ip-address>/about.

jdmbeer commented 3 years ago

this morning it appears to be running local version: 246bad4. I completely agree with your analysis and I can see today when I look at history the data was captured fine. It looks like it is just the current session data that is not being presented. started brewing again today the the current session appears to by unchanged in that it believe the starting point is still april 4th. It does display the name of the current beer being brewed. two questions. 1) is there a file I can delete to reset the starting data point? 2) is there aspecific process to follow when shutting down to make sure the session closes clean? activefiles If the files in the active dir are the issue can I delete them? I tried and it wouldn't let me. couldn't get sudo to work thanks ,JM

jdmbeer commented 3 years ago

ok, I force deleted all of the files before today and restarted the pi - now it is reporting the active session properly. I lost some of the sessions that didn't close and roll over to archive - oh well. So Just the one questions then - is there an appropriate way to "close" the session to cleaning end the session? aside from that we can close this one.

tmack8001 commented 3 years ago

Just to close up here.

So Just the one questions then - is there an appropriate way to "close" the session to cleaning end the session? aside from that we can close this one.

There was a few attempts to resolve this. One thing can still cause problems which is if for any reason the datalogs and single "close" event isn't received or process successfully by the server from the brewing devices. Which I should just add a manual stop/close button like we have for distillation and fermentation devices and/or find a way on starting a new session if detected to be +x hours past the last session to be a new session file (assuming a brew shouldn't exceed x hours in length).

jdmbeer commented 3 years ago

Sounds like that would do it. Or, perhaps put a clean up step in the shut down process of the RPI. pretty much the last thing I do after brewing and cleaning is to "shutdown" that server.

tmack8001 commented 3 years ago

Ah that might be a good enough location as any. Though in theory you could shutdown or restart during a brew and still have it come up with the same session (I've done this to test say a power outage without unsafely pulling the power from the device).

jdmbeer commented 3 years ago

Then you would have to make the “restart after power outage” it’s own button.

JM Sent from my iPhone

On May 12, 2021, at 3:30 PM, Trevor Mack @.***> wrote:

 Ah that might be a good enough location as any. Though in theory you could shutdown or restart during a brew and still have it come up with the same session (I've done this to test say a power outage without unsafely pulling the power from the device).

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.