I have 2 error JSON and can't figure out why it's an error.

[Rudder2]

This one never created Data...
20210115_174143#30aea4c737ec#02acdb4464944d029307240afe3cb441#RINSE#0.json.txt

This one looks complete and the PIServer says it's in error state.
20210115_174247#30aea4c737ec#2c5a8b7ade5742c7bfd83330a78426b3#HopHeads_IPA_#1-3_With_First_Wart_&_Whirlpool#6.json.txt

[tmack8001]

likely related to #206

[Rudder2]

@tmack8001 I read that but couldn't find a coma at the end of my file so created another bug report because thought it might be different problem. To my, untrained eyes when it comes to looking at JSON files, session file looked complete with an opening [ and ending ] and no added stuff before and after the data, Compared it to a working file.

[tmack8001]

Yeah I noticed that too. I'll take a look by copying this to my system and running some tests with them.

Thanks for reporting and sending up the files.

[tmack8001]

@Rudder2 I at least am able to reproduce what you are seeing so I'll take it from here and find what is actually failing while also making that error message in flask a bit more clear what exactly int he file is failing.

It is a properly formatted JSON file... so I went and added some additional logging to figure things out as right now we "swallow" the exception and just print a line saying the file is invalid for some reason.

[2021-01-22 13:37:05,115] ERROR in routes_frontend: An exception occurred parsing /Users/tmack/dev/projects/trevormack/picobrew_pico/app/sessions/brew/archive/20210115_174247#30aea4c737ec#2c5a8b7ade5742c7bfd83330a78426b3#HopHeads_IPA_#1-3_With_First_Wart_&_Whirlpool#6.json
[2021-01-22 13:37:05,116] ERROR in routes_frontend: invalid literal for int() with base 10: '1-3_With_First_Wart_&_Whirlpool'

The session file is absolutely correct syntax, but there is something that isn't deserializing into our python model for the PicoBrewSession.

@Rudder2 for this specific run what was the recipe name? Was there a "#" by chance in the recipe title? Was HopHeads_IPA_#1-3_With_First_Wart_&_Whirlpool the title or the recipe?

[tmack8001]

Regarding the rinse not having any data. Would you have normally gotten a rinse temperature graph on picobrew proper?

For instance the Z publishes out the data log as if it were a normal brew session.

[Rudder2]

@tmack8001 Yes there is a # in the recipe name. There is also an & in the Recipe name also. Welcome, figured you couldn't try to fix with out files.

Yes I normally get a rinse graph from PicoBrew and from the PieServer.
PieServer Rinse JSON from working file:
20210116_001310#30aea4c737ec#c50c1370c3244efe9aa57414fa4a7906#RINSE#0.json.txt

Also when a brew ends when I'm asleep the JSON and graph continues to log data as if the session is still going until I click the continue to rinse button...Than the Rinse graph will continue for ever till I click done with rinse at the end. Like here:
20201215_203329#30aea4c737ec#d2a925d6a4c5405593886cc6f84a272b#Double_IPA#6.json.txt

[tmack8001]

Yup that makes sense.

Yeah that "#" caused problems... We should encode/escape it when creating the session file.

I'll mark that as a task to resolve that problem, still not sure about the rinse issue. By chance was that the rinse after that specific brew session that got reported as invalid?

[Rudder2]

Yes, that rinse is the one associated with the brew that was reported invalid.

Your so good at fixing these problems the PIServer will soon be better than PicoBrew was.

[tmack8001]

@Rudder2 #215 will fix that file have being created in this way again.

If you simply rename the file you have from /picobrew_pico/app/sessions/brew/archive/20210115_174247#30aea4c737ec#2c5a8b7ade5742c7bfd83330a78426b3#HopHeads_IPA_#1-3_With_First_Wart_&_Whirlpool#6.json to /picobrew_pico/app/sessions/brew/archive/20210115_174247#30aea4c737ec#2c5a8b7ade5742c7bfd83330a78426b3#HopHeads_IPA_%231-3_With_First_Wart_&_Whirlpool#6.json you will fix the "invalid" nature of this file. The problem was we are using the "#" character as our "filename separator" (one day I'll change sessions to instead have this information represented in the JSON and not in the filename... cause by doing this we really are forcing the filename to carry any and all metadata for the session... though that will need to be done in a backwards compatible way supporting both formats of files or doing a one way translation/migration at server startup).

[tmack8001]

For additional context to what I have thought of and planned for later see #216

[Rudder2]

Awesome! Worked like a champ. Now that i know, the current brew and next brew will need this manual edit.

Didn't think about # being a separator for three file name. My home brew store have me 3 IPAs like I asked and they used the same recipe just changed hops to change up flavor for me and called them IPA Number 1, 2, 3 so I was being lazy and used # instead. Laziness messes things up again... Lol!

Thank you for looking in to it for me and figuring it out.

I exclusively use the PIServer for every brew and fermentation since i started brewing with my PicoBrew Z, got it cheep on eBay in October to learn PicoBrew was going under... I have a PicoBrew S I loved since the day I got it from their kickstarter so been looking for a Z deal on eBay since they came out. With the PISever and a step filter adaptor i plan on using the S for trial runs and running my PicoStill.

I'm afraid they might update the Picos so they can't be ran offline like we are with a fermware update since someone might see proprietary machines as an asset.

[tmack8001]

Yeah I've heard that Bill was called in to do something recently... But doubt he was writing firmware for these.

Laziness sometimes also finds errors where someone not as knowledgeable might be pulling their hair out over. So I'm just glad to you stuck with it to bring feedback about potential issues happening.

[Rudder2]

Verified that this fixed the problem with the file name with the # in it is fixed and the rinse reported points but I had to delete the ',' (coma) at the end of the rinse file to get the data points to show on the PIServer Session History. I don't mind this that much as I'm a computer guy. I am willing to accept little quirks to keep what I like for the long haul.

20210122_222245#30aea4c737ec#2770f362d25442709eaa1a7e17451ea7#RINSE#0.json.txt

[tmack8001]

Ah yeah that file looks like a newline character was removed when we went to archive the file, but there was still a trailing comma left around. I'll look at fixing this @BuckoWA also has seen this happen more recently which I think is related to a recent change making this happen more frequently.

[Rudder2]

After update and reboot (2021-01-24 @1530), wanted to update to all the great work I've been reading about, all my PicoFerm Data from the last 28 hours or so is gone on my active fermemtation. The data in the file has only one point in it when it use to have tons of points. The time of the file is the time of the reboot, just Eastern Time instead of Central. Which means the original file vanished. All archived sessions are still present and correct. Just wanted to report it.

[tmack8001]

@Rudder2 that is strange. Is there another file in archive that would match the points prior to the reboot? In the past new sessions were created on startup. Also are there multiple "active" files for this specific Picoferm device (would only result in one in the UI)?

[Rudder2]

@tmack8001 The file is just gone. Not in archive or active folder. I thought that was strange also.

This PicoFerm's battery died during the last fermentation and it showed in the graph the last 10 points from before it died at the beginning of the graph when i clicked start fermentation, like they were stored in the PicoFerm some where. I now use AC adaptors because can't afford 2 batteries every brew and they only last 2 weeks. This night be a piece of the puzzle that is missing.

Can't wait to build the iSpangles. Going to get the parts soon. Can't wait to have real SG monitoring in addition to the pressure.

[tmack8001]

Well that is a new one to me... iSpindle or Tilt definitely makes life easier and helps to reduce cold side oxidation (if you like me would be pulling samples every day or 2 to make sure you are trending still).

Definitely let me know if you can reproduce that reliably. As for the original problem that this issue was created for that has been resolved with the PR (I tested with your files in archive locally) so I'm going to close this. Feel free to continue discussion here or if this happens again to open another issue to track that specific issue if we can reliably reproduce it.

The only places that os.remove (how files get deleted) is issued by the server are the following locations:

• starting fermentation when there is an empty fermentation file (aka the prior ferm session never sent data points to the server)
• delete zymatic recipe
• delete z recipe
• delete pico recipe
• delete generic session or recipe file