Picoferm not connecting to the Pi server

Hi Guys, as I work through the various brew cycles (water only) on our Z systems, all running now without any issues showing up 👍, I decided to look at the fermentation side.
The problem I have is that our 2 PicoFerm's will not attach to my Raspberry Pi W 0 WiFi I am running the beta 5 software with updates on. They attach to our home WiFi with no issue also my laptops attache to the Pi WiFi with no issues.
Both PicoFerms are on rev 0.2.6 firmware.
Is there a trick to get the PicoFerm's to attach to the Pi WiFi, I am putting them in factory reset mode (all led's on), attaching to it's WiFi on the laptop, directing the PicoFerm to the Pi WiFi etc... it then flashes through it led's in sequence the green holds for a few seconds then it moves to red and turns of..., or am I just missing something here?
Cheers
Les

@LEFsher does the device show up with a graph entry on the main page of the server http://raspberrypi/ or http:///

@LEFsher does the device show up with a graph entry on the main page of the server http://raspberrypi/ or http:///

I recently added a way to "start" and "stop" fermentation monitoring from the server interface.

I recently added a way to "start" and "stop" fermentation monitoring from the server interface.

Yes but I have explicitly added both Picoferms into the config.yaml file.
From: Trevor Mack<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 05:44
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
@LEFsherhttps://github.com/LEFsher does the device show up with a graph entry on the main page of the server http://raspberrypi/ or http:///http://
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757478649, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXEILQ7JOFMESMVLWJTSZGVLZANCNFSM4V36M7IQ.

Yes but I have explicitly added both Picoferms into the config.yaml file.
From: Trevor Mack<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 05:44
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
@LEFsherhttps://github.com/LEFsher does the device show up with a graph entry on the main page of the server http://raspberrypi/ or http:///http://
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757478649, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXEILQ7JOFMESMVLWJTSZGVLZANCNFSM4V36M7IQ.

How far away are the pico terms from the pi? The range isn't the best, so if they're not close (in the same room etc), you might have issues.

How far away are the pico terms from the pi? The range isn't the best, so if they're not close (in the same room etc), you might have issues.

I have tried in the same room, on top off the Pi away from the Pi in the next room etc. They just will not connect ☹
From: Pete<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 11:58
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
How far away are the pico terms from the pi? The range isn't the best, so if they're not close (in the same room etc), you might have issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757534264, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXBI72SQI6HHIUK73J3SZIBCZANCNFSM4V36M7IQ.

I have tried in the same room, on top off the Pi away from the Pi in the next room etc. They just will not connect ☹
From: Pete<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 11:58
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
How far away are the pico terms from the pi? The range isn't the best, so if they're not close (in the same room etc), you might have issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757534264, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXBI72SQI6HHIUK73J3SZIBCZANCNFSM4V36M7IQ.

Les are you able to get server logs? I added a recent entry for this in the "system" navigation menu.
There is no trick (other than signal strength) to connect to the WiFi of the Pi going through factory reset is that way.
What I have noticed with PicoFerm either on the mothership or local server is it sometimes takes hours to get first measurements of fermentation.

Les are you able to get server logs? I added a recent entry for this in the "system" navigation menu.
There is no trick (other than signal strength) to connect to the WiFi of the Pi going through factory reset is that way.
What I have noticed with PicoFerm either on the mothership or local server is it sometimes takes hours to get first measurements of fermentation.

Yes I have access to the logs… it is rather long what looks like a continuous string of text, what should I be looking for in it?
For the picoferm data I noticed this when using them on the picobrew system it could take a very long time to get any data… I raised this as an issue with their tech teams (when they were still in existence) and they did not know why or could not offer an explanation of why it was taking so long for data to “flow”.
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 13:04
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
Les are you able to get server logs? I added a recent entry for this in the "system" navigation menu.
There is no trick (other than signal strength) to connect to the WiFi of the Pi going through factory reset is that way.
What I have noticed with PicoFerm either on the mothership or local server is it sometimes takes hours to get first measurements of fermentation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757543800, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXEABUXDBPDGEDRWR2DSZII5PANCNFSM4V36M7IQ.

Yes I have access to the logs… it is rather long what looks like a continuous string of text, what should I be looking for in it?
For the picoferm data I noticed this when using them on the picobrew system it could take a very long time to get any data… I raised this as an issue with their tech teams (when they were still in existence) and they did not know why or could not offer an explanation of why it was taking so long for data to “flow”.
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Sunday, January 10, 2021 13:04
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
Les are you able to get server logs? I added a recent entry for this in the "system" navigation menu.
There is no trick (other than signal strength) to connect to the WiFi of the Pi going through factory reset is that way.
What I have noticed with PicoFerm either on the mothership or local server is it sometimes takes hours to get first measurements of fermentation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757543800, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXEABUXDBPDGEDRWR2DSZII5PANCNFSM4V36M7IQ.

Yeah I noticed the formatting on that is messed up. I was looking at improving that, but did it quick to get some logs from someone the other night.
Will more likely concat the logs into a file and pull that file for download instead of trying to display on browser. This way someone can just upload the .log / .txt file for analysis vs copy paste and all the problems that come with that route.

Yeah I noticed the formatting on that is messed up. I was looking at improving that, but did it quick to get some logs from someone the other night.
Will more likely concat the logs into a file and pull that file for download instead of trying to display on browser. This way someone can just upload the .log / .txt file for analysis vs copy paste and all the problems that come with that route.

I have added the data to a txt file and attached. Not certain if this is of any use to you Trevor in its current format…
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Monday, January 11, 2021 06:22
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
Yeah I noticed the formatting on that is messed up. I was looking at improving that, but did it quick to get some logs from someone the other night.
Will more likely concat the logs into a file and pull that file for download instead of trying to display on browser. This way someone can just upload the .log / .txt file for analysis vs copy paste and all the problems that come with that route.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757982166, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXDHH6MFT4ROIZ7VJRTSZMCQPANCNFSM4V36M7IQ.
● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled) Drop-In: /usr/lib/systemd/system/rc-local.service.d └─debian.conf /etc/systemd/system/rc-local.service.d └─ttyoutput.conf Active: active (running) since Thu 2021-01-07 14:42:43 EST; 3 days ago Docs: man:systemd-rc-local-generator(8) Process: 270 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS) Tasks: 5 (limit: 881) CGroup: /system.slice/rc-local.service ├─ 366 /usr/bin/python3 server.py <IP_ADDRESS> 8080 ├─9880 /bin/sh -c systemctl status rc.local -n 20000 └─9881 systemctl status rc.local -n 20000 Jan 07 14:41:44 raspberrypi systemd[1]: Starting /etc/rc.local Compatibility... Jan 07 14:42:43 raspberrypi systemd[1]: Started /etc/rc.local Compatibility. Jan 07 14:42:51 raspberrypi rc.local[270]: WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.  Not certain if this is of any use to you Trevor in its current format…
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Monday, January 11, 2021 06:22
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
Yeah I noticed the formatting on that is messed up. I was looking at improving that, but did it quick to get some logs from someone the other night.
Will more likely concat the logs into a file and pull that file for download instead of trying to display on browser. This way someone can just upload the .log / .txt file for analysis vs copy paste and all the problems that come with that route.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-757982166, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXDHH6MFT4ROIZ7VJRTSZMCQPANCNFSM4V36M7IQ.
● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled) Drop-In: /usr/lib/systemd/system/rc-local.service.d └─debian.conf /etc/systemd/system/rc-local.service.d └─ttyoutput.conf Active: active (running) since Thu 2021-01-07 14:42:43 EST; 3 days ago Docs: man:systemd-rc-local-generator(8) Process: 270 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS) Tasks: 5 (limit: 881) CGroup: /system.slice/rc-local.service ├─ 366 /usr/bin/python3 server.py <IP_ADDRESS> 8080 ├─9880 /bin/sh -c systemctl status rc.local -n 20000 └─9881 systemctl status rc.local -n 20000 Jan 07 14:41:44 raspberrypi systemd[1]: Starting /etc/rc.local Compatibility... Jan 07 14:42:43 raspberrypi systemd[1]: Started /etc/rc.local Compatibility. Jan 07 14:42:51 raspberrypi rc.local[270]: WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.  All other failures in the logs were about socketio which is the transportation protocol we use to community realtime data to the brew/ferm graphs in the UI.
If in the future you store this into a text file and then upload that text file as an attachment (dragging & dropping or pasting the "file" and not the contents of the file) that would be awesome.

The only error I see from those logs (likely cause you have used or interacted with the server more) is your Z machine:
Jan 07 15:59:10 raspberrypi rc.local[270]: [2021-01-07 15:59:10,627] ERROR in app: Exception on /Vendors/input.cshtml [GET] Jan 07 15:59:10 raspberrypi rc.local[270]: Traceback (most recent call last): Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2447, in wsgi_app Jan 07 15:59:10 raspberrypi rc.local[270]: response = self.full_dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1952, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.handle_user_exception(e) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask_cors/extension.py", line 165, in wrapped_function Jan 07 15:59:10 raspberrypi rc.local[270]: return cors_after_request(app.make_response(f(*args, **kwargs))) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1821, in handle_user_exception Jan 07 15:59:10 raspberrypi rc.local[270]: reraise(exc_type, exc_value, tb) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/_compat.py", line 39, in reraise Jan 07 15:59:10 raspberrypi rc.local[270]: raise value Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1950, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1936, in dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: return self.view_functions[rule.endpoint](**req.view_args) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/webargs/core.py", line 443, in wrapper Jan 07 15:59:10 raspberrypi rc.local[270]: return func(*args, **kwargs) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 139, in process_zseries_get_request Jan 07 15:59:10 raspberrypi rc.local[270]: return process_recipe_request(identifier) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 149, in process_recipe_request Jan 07 15:59:10 raspberrypi rc.local[270]: return recipe.serialize() Jan 07 15:59:10 raspberrypi rc.local[270]: AttributeError: 'NoneType' object has no attribute 'serialize' Jan 07 15:59:10 raspberrypi rc.local[270]: <IP_ADDRESS> - - [07/Jan/2021 15:59:10] "GET /Vendors/input.cshtml?type=Recipe&token=240ac424b028&id=0 HTTP/1.0" 500

Which shows there was a serialization error on a recipe you might have had, but looks like the recipe doesn't exist when the Z went to fetch it. All other failures in the logs were about socketio which is the transportation protocol we use to community realtime data to the brew/ferm graphs in the UI.
If in the future you store this into a text file and then upload that text file as an attachment (dragging & dropping or pasting the "file" and not the contents of the file) that would be awesome.

No problem will do 😊
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Monday, January 11, 2021 11:42
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
The only error I see from those logs (likely cause you have used or interacted with the server more) is your Z machine:
Jan 07 15:59:10 raspberrypi rc.local[270]: [2021-01-07 15:59:10,627] ERROR in app: Exception on /Vendors/input.cshtml [GET] Jan 07 15:59:10 raspberrypi rc.local[270]: Traceback (most recent call last): Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2447, in wsgi_app Jan 07 15:59:10 raspberrypi rc.local[270]: response = self.full_dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1952, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.handle_user_exception(e) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask_cors/extension.py", line 165, in wrapped_function Jan 07 15:59:10 raspberrypi rc.local[270]: return cors_after_request(app.make_response(f(*args, **kwargs))) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1821, in handle_user_exception Jan 07 15:59:10 raspberrypi rc.local[270]: reraise(exc_type, exc_value, tb) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/_compat.py", line 39, in reraise Jan 07 15:59:10 raspberrypi rc.local[270]: raise value Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1950, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1936, in dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: return self.view_functionsrule.endpoint Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/webargs/core.py", line 443, in wrapper Jan 07 15:59:10 raspberrypi rc.local[270]: return func(*args, **kwargs) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 139, in process_zseries_get_request Jan 07 15:59:10 raspberrypi rc.local[270]: return process_recipe_request(identifier) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 149, in process_recipe_request Jan 07 15:59:10 raspberrypi rc.local[270]: return recipe.serialize() Jan 07 15:59:10 raspberrypi rc.local[270]: AttributeError: 'NoneType' object has no attribute 'serialize' Jan 07 15:59:10 raspberrypi rc.local[270]: <IP_ADDRESS> - - [07/Jan/2021 15:59:10] "GET /Vendors/input.cshtml?type=Recipe&token=240ac424b028&id=0 HTTP/1.0" 500
Which shows there was a serialization error on a recipe you might have had, but looks like the recipe doesn't exist when the Z went to fetch it. All other failures in the logs were about socketio which is the transportation protocol we use to community realtime data to the brew/ferm graphs in the UI.
If in the future please store this info into a text file and then upload that text file as an attachment (dragging & dropping or pasting the "file" and not the contents of the file) that would be awesome.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-758179020, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXGEELSD3PXNVNEVR63SZNIBLANCNFSM4V36M7IQ.

No problem will do 😊
Cheers
Les
From: Trevor Mack<EMAIL_ADDRESS>Sent: Monday, January 11, 2021 11:42
To: chiefwigms/picobrew_pico<EMAIL_ADDRESS>Cc: LEFsher<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [chiefwigms/picobrew_pico] Picoferm not connecting to the Pi server (#187)
The only error I see from those logs (likely cause you have used or interacted with the server more) is your Z machine:
Jan 07 15:59:10 raspberrypi rc.local[270]: [2021-01-07 15:59:10,627] ERROR in app: Exception on /Vendors/input.cshtml [GET] Jan 07 15:59:10 raspberrypi rc.local[270]: Traceback (most recent call last): Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2447, in wsgi_app Jan 07 15:59:10 raspberrypi rc.local[270]: response = self.full_dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1952, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.handle_user_exception(e) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask_cors/extension.py", line 165, in wrapped_function Jan 07 15:59:10 raspberrypi rc.local[270]: return cors_after_request(app.make_response(f(*args, **kwargs))) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1821, in handle_user_exception Jan 07 15:59:10 raspberrypi rc.local[270]: reraise(exc_type, exc_value, tb) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/_compat.py", line 39, in reraise Jan 07 15:59:10 raspberrypi rc.local[270]: raise value Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1950, in full_dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: rv = self.dispatch_request() Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1936, in dispatch_request Jan 07 15:59:10 raspberrypi rc.local[270]: return self.view_functionsrule.endpoint Jan 07 15:59:10 raspberrypi rc.local[270]: File "/usr/local/lib/python3.7/dist-packages/webargs/core.py", line 443, in wrapper Jan 07 15:59:10 raspberrypi rc.local[270]: return func(*args, **kwargs) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 139, in process_zseries_get_request Jan 07 15:59:10 raspberrypi rc.local[270]: return process_recipe_request(identifier) Jan 07 15:59:10 raspberrypi rc.local[270]: File "/picobrew_pico/app/main/routes_zseries_api.py", line 149, in process_recipe_request Jan 07 15:59:10 raspberrypi rc.local[270]: return recipe.serialize() Jan 07 15:59:10 raspberrypi rc.local[270]: AttributeError: 'NoneType' object has no attribute 'serialize' Jan 07 15:59:10 raspberrypi rc.local[270]: <IP_ADDRESS> - - [07/Jan/2021 15:59:10] "GET /Vendors/input.cshtml?type=Recipe&token=240ac424b028&id=0 HTTP/1.0" 500
Which shows there was a serialization error on a recipe you might have had, but looks like the recipe doesn't exist when the Z went to fetch it. All other failures in the logs were about socketio which is the transportation protocol we use to community realtime data to the brew/ferm graphs in the UI.
If in the future please store this info into a text file and then upload that text file as an attachment (dragging & dropping or pasting the "file" and not the contents of the file) that would be awesome.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/chiefwigms/picobrew_pico/issues/187#issuecomment-758179020, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARULOXGEELSD3PXNVNEVR63SZNIBLANCNFSM4V36M7IQ.

OK now I understand the issue with the data, I transferred it as a txt file attached to the Email... Sorry about that I won't do that again.
I have been looking at the signal strength of the PicoFerm and Pi WiFi's and believe this is where my problem is. I have ordered some parts and will be switching the Pi antenna to an external 9dBi gain AE. Hopefully this will give enough boost to the Pi signal and allow the PicoFerm to actually find it. I'll keep you posted once I have made the mods. :)

OK now I understand the issue with the data, I transferred it as a txt file attached to the Email... Sorry about that I won't do that again.
I have been looking at the signal strength of the PicoFerm and Pi WiFi's and believe this is where my problem is. I have ordered some parts and will be switching the Pi antenna to an external 9dBi gain AE. Hopefully this will give enough boost to the Pi signal and allow the PicoFerm to actually find it. I'll keep you posted once I have made the mods. :)

Oh yeah GitHub doesn't like emailed file attachments. Treats it like plaintext 🤬, but no problem.
I made some modifications today and yesterday to the logs feature and over the coming days.

Oh yeah GitHub doesn't like emailed file attachments. Treats it like plaintext 🤬, but no problem.
I made some modifications today and yesterday to the logs feature and over the coming days.

I have installed the "new" antenna on the Pi, it resulted in a slight improvement of signal strength but the issue still exists the Picoferm will not connect. I have included a photo of the data from the Pi when the Picoferm tries to connect (10 connection attempts) if this is of any help?

I have looked at switching to the iSpindle for my fermentation how well is that working with the Pi server setup?

I have installed the "new" antenna on the Pi, it resulted in a slight improvement of signal strength but the issue still exists the Picoferm will not connect. I have included a photo of the data from the Pi when the Picoferm tries to connect (10 connection attempts) if this is of any help?

I have looked at switching to the iSpindle for my fermentation how well is that working with the Pi server setup?

@LEFsher that looks near perfect actually... Why would you say it is still disconnecting? That access log only shows successes.
Note of you restarted the server with internet access the last couple days you have to explicitly go to the index page and "start fermentation" monitoring like to would at Picobrew's brew house.
Also let it be known others have PicoFerms and iSpindels working great with the server. Though honestly the data gathered from a tilt or iSpindel is much better at knowing status of fermentation given the measurement of specific gravity vs pressure (unrelated to fermentation status, but rather outcome of CO2 released in a pressurized container).

@LEFsher that looks near perfect actually... Why would you say it is still disconnecting? That access log only shows successes.
Note of you restarted the server with internet access the last couple days you have to explicitly go to the index page and "start fermentation" monitoring like to would at Picobrew's brew house.
Also let it be known others have PicoFerms and iSpindels working great with the server. Though honestly the data gathered from a tilt or iSpindel is much better at knowing status of fermentation given the measurement of specific gravity vs pressure (unrelated to fermentation status, but rather outcome of CO2 released in a pressurized container).

Sorry it's been a while getting back on this... Had a system crash... all fixed now.
I connected the external Antenna to the Pi zero W to try and boost the signal strength but still had the same issue when connecting the Picoferm: Put PF in reset all LED on, Attach to PF WiFi, select Pi WiFi to attach to, etc. The PF cycles through it's LED's settles on the Green for 5 seconds then Red then off.
As the logs are showing and you confirmed previously that this is "connected" I decided to run a fermentation session by clicking the start Fermentation icon this resulted in an internal server error, see attached, I have also attached the log file.
My question here is what is happening to cause this internal error, the PF is not overloaded as it is only running this task and before my system died I was not seeing it. The Pi has the latest code and I have rebooted a number of times to see if this is the issue.
Any help would be really appreciated I understand you have a lot going on at present with other issues so no real rush on this one.
Cheers
Les
Internal server error.pdf
picobrew_pico.log

Sorry it's been a while getting back on this... Had a system crash... all fixed now.
I connected the external Antenna to the Pi zero W to try and boost the signal strength but still had the same issue when connecting the Picoferm: Put PF in reset all LED on, Attach to PF WiFi, select Pi WiFi to attach to, etc. The PF cycles through it's LED's settles on the Green for 5 seconds then Red then off.
As the logs are showing and you confirmed previously that this is "connected" I decided to run a fermentation session by clicking the start Fermentation icon this resulted in an internal server error, see attached, I have also attached the log file.
My question here is what is happening to cause this internal error, the PF is not overloaded as it is only running this task and before my system died I was not seeing it. The Pi has the latest code and I have rebooted a number of times to see if this is the issue.
Any help would be really appreciated I understand you have a lot going on at present with other issues so no real rush on this one.
Cheers
Les
Internal server error.pdf
picobrew_pico.log

See https://github.com/chiefwigms/picobrew_pico/issues/226
Clear your ferm sessions folder, reboot, try again.

See https://github.com/chiefwigms/picobrew_pico/issues/226
Clear your ferm sessions folder, reboot, try again.

I'm having the exact same issue.
I'm able to connect the PicoFerm to my home network and to register it with my picobrew.com account.
But when I put the PicoFerm in access point mode, connect to it via web browser, and set it to connect to the PICOBREW network provided by my raspberry pi, it cycles through its LEDs, then blinks the red error LED 3 times and seemingly powers off. I tried changing the picoferm's batteries, tried a factory reset, and tried running the picobrew server on both a Pi Zero W and on a Raspberry Pi 4 (4Gb). The Pi seems to have a good connection to my home network and is in the same room as the PicoFerm. My Pico C seems to have no trouble connecting to the Picobrew server.
I see the following in /var/log/nginx/picobrew.access.log every time I try to connect the PicoFerm:
<IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"
The PicoFerm is visible in the Picobrewserver interface, as a blank graph with no data. If I click the 'Start Fermentation' button it instantly displays the pink "Error: Internal Server Error" box at the top of the page.
I see nothing interesting in picobrew_pico.log, and nothing interesting showing up in /var/log/nginx/*.log other than what I've quoted above. "sudo systemctl status rc.local -n 50" does show something that might be relevant:
Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 - Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 - Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 - Jan 28 18:22:11 picobrewserver rc.local[437]: [2021-01-28 18:22:11,986] ERROR in app: Exception on /device/600194556b08/sessions/ferm [PUT] Jan 28 18:22:11 picobrewserver rc.local[437]: Traceback (most recent call last): Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2447, in wsgi_app Jan 28 18:22:11 picobrewserver rc.local[437]:     response = self.full_dispatch_request() Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1953, in full_dispatch_request Jan 28 18:22:11 picobrewserver rc.local[437]:     return self.finalize_request(rv) Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1968, in finalize_request Jan 28 18:22:11 picobrewserver rc.local[437]:     response = self.make_response(rv) Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2098, in make_response Jan 28 18:22:11 picobrewserver rc.local[437]:     "The view function did not return a valid response. The" Jan 28 18:22:11 picobrewserver rc.local[437]: TypeError: The view function did not return a valid response. The function either returned None or ended without a return statement. Jan 28 18:22:11 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:11] "PUT /device/600194556b08/sessions/ferm HTTP/1.0" 500 - Jan 28 18:22:12 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:12] "POST /socket.io/?EIO=3&transport=polling&t=NTBJUVT&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 - Jan 28 18:22:12 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:12] "GET /socket.io/?EIO=3&transport=polling&t=NTBJOOr&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 - Jan 28 18:22:37 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:37] "POST /socket.io/?EIO=3&transport=polling&t=NTBJacO&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 -
Looks to me like the PicoFerm does connect to Picobrewserver but then doesn't get something it's looking for and disconnects? And subsequent attempts to start fermentation fail.
Thanks for any help or info.
Regression:
ps_server_stable_beta6.zip
Raspberry Pi 4 (4Gb) and Raspberry Pi Zero W
PIcoferm firmware 0.2.6

I'm having the exact same issue.
I'm able to connect the PicoFerm to my home network and to register it with my picobrew.com account.
But when I put the PicoFerm in access point mode, connect to it via web browser, and set it to connect to the PICOBREW network provided by my raspberry pi, it cycles through its LEDs, then blinks the red error LED 3 times and seemingly powers off. I tried changing the picoferm's batteries, tried a factory reset, and tried running the picobrew server on both a Pi Zero W and on a Raspberry Pi 4 (4Gb). The Pi seems to have a good connection to my home network and is in the same room as the PicoFerm. My Pico C seems to have no trouble connecting to the Picobrew server.
I see the following in /var/log/nginx/picobrew.access.log every time I try to connect the PicoFerm:
<IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:16:12 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"
The PicoFerm is visible in the Picobrewserver interface, as a blank graph with no data. If I click the 'Start Fermentation' button it instantly displays the pink "Error: Internal Server Error" box at the top of the page.
I see nothing interesting in picobrew_pico.log, and nothing interesting showing up in /var/log/nginx/*.log other than what I've quoted above. "sudo systemctl status rc.local -n 50" does show something that might be relevant:
Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 - Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 - Jan 28 18:22:03 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:03] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 - Jan 28 18:22:11 picobrewserver rc.local[437]: [2021-01-28 18:22:11,986] ERROR in app: Exception on /device/600194556b08/sessions/ferm [PUT] Jan 28 18:22:11 picobrewserver rc.local[437]: Traceback (most recent call last): Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2447, in wsgi_app Jan 28 18:22:11 picobrewserver rc.local[437]:     response = self.full_dispatch_request() Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1953, in full_dispatch_request Jan 28 18:22:11 picobrewserver rc.local[437]:     return self.finalize_request(rv) Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1968, in finalize_request Jan 28 18:22:11 picobrewserver rc.local[437]:     response = self.make_response(rv) Jan 28 18:22:11 picobrewserver rc.local[437]:   File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2098, in make_response Jan 28 18:22:11 picobrewserver rc.local[437]:     "The view function did not return a valid response. The" Jan 28 18:22:11 picobrewserver rc.local[437]: TypeError: The view function did not return a valid response. The function either returned None or ended without a return statement. Jan 28 18:22:11 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:11] "PUT /device/600194556b08/sessions/ferm HTTP/1.0" 500 - Jan 28 18:22:12 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:12] "POST /socket.io/?EIO=3&transport=polling&t=NTBJUVT&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 - Jan 28 18:22:12 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:12] "GET /socket.io/?EIO=3&transport=polling&t=NTBJOOr&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 - Jan 28 18:22:37 picobrewserver rc.local[437]: <IP_ADDRESS> - - [28/Jan/2021 18:22:37] "POST /socket.io/?EIO=3&transport=polling&t=NTBJacO&sid=bb022c2fe177497da36654d739832d03 HTTP/1.1" 200 -
Looks to me like the PicoFerm does connect to Picobrewserver but then doesn't get something it's looking for and disconnects? And subsequent attempts to start fermentation fail.
Thanks for any help or info.
Regression:
ps_server_stable_beta6.zip
Raspberry Pi 4 (4Gb) and Raspberry Pi Zero W
PIcoferm firmware 0.2.6

Oh... that to me is "good" news (sorry)... means I'm not going crazy :)
Yep I checked the sessions nothing in there, powered off then on again, still the same issue :(

Oh... that to me is "good" news (sorry)... means I'm not going crazy :)
Yep I checked the sessions nothing in there, powered off then on again, still the same issue :(

I mean, this must be at least related to the problem, I'd guess:
Jan 28 18:22:11 picobrewserver rc.local[437]: [2021-01-28 18:22:11,986] ERROR in app: Exception on /device/600194556b08/sessions/ferm [PUT
Sorry I haven't figured out further -- I don't know Python.

I mean, this must be at least related to the problem, I'd guess:
Jan 28 18:22:11 picobrewserver rc.local[437]: [2021-01-28 18:22:11,986] ERROR in app: Exception on /device/600194556b08/sessions/ferm [PUT
Sorry I haven't figured out further -- I don't know Python.

I just fixed a bug from the iSpindel update preventing manual start/stops... see if that fixes it

I just fixed a bug from the iSpindel update preventing manual start/stops... see if that fixes it

Success... I'm now trying to run a (Pseudo) fermentation to see if the PF is actually working with the Pi server and sending data.
Will let you know once I see data or not.

Success... I'm now trying to run a (Pseudo) fermentation to see if the PF is actually working with the Pi server and sending data.
Will let you know once I see data or not.

It worked, see attached. Thanks guys :)
Fermentation chart.pdf

It worked, see attached. Thanks guys :)
Fermentation chart.pdf

This is a very basic question - but @LEFsher can you (or anyone) tell me how you updated the software? I clicked "System>Update/Restart Server" on my picobrewserver's web page but this resulted in no feedback that indicated anything had actually happened and I don't know if it's a live software update feature or a stub. I went to the "Releases" page but all I found there was the same days-old image I'd used to flash the SD card before.
Is there an update process I should be following?
Thanks.

This is a very basic question - but @LEFsher can you (or anyone) tell me how you updated the software? I clicked "System>Update/Restart Server" on my picobrewserver's web page but this resulted in no feedback that indicated anything had actually happened and I don't know if it's a live software update feature or a stub. I went to the "Releases" page but all I found there was the same days-old image I'd used to flash the SD card before.
Is there an update process I should be following?
Thanks.

Go to the System->About menu. It will display some info along with the software version and will indicate if it's current or there is an update. If there's an update, you can click to update from there also.

Go to the System->About menu. It will display some info along with the software version and will indicate if it's current or there is an update. If there's an update, you can click to update from there also.

Aha, went to "System->About" and I see this:

If I run "tail-f /var/log/nginx/*.log" and watch while the Picoferm tries to connect to the server, I see the following messages show up:
`==> /var/log/nginx/picobrew.access.log <==
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"`
Picoferm is still ending its attempt to connect to the Picobrew Server with a few flashes of its error light. Maybe it's time for another factory reset on it.

Aha, went to "System->About" and I see this:

If I run "tail-f /var/log/nginx/*.log" and watch while the Picoferm tries to connect to the server, I see the following messages show up:
`==> /var/log/nginx/picobrew.access.log <==
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [29/Jan/2021:15:17:23 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"`
Picoferm is still ending its attempt to connect to the Picobrew Server with a few flashes of its error light. Maybe it's time for another factory reset on it.

For the update each time you reboot or power on, the server updates.
When I try and connect my second PF I get the same issue in that it cycles through it's LED's seems to hesitate on the Green then flashed Red a few times and "shuts down". However it seems that it has actually attached to the Pi server... I am now running a fermentation on both PF's to see if they are both actually working and sending data.

For the update each time you reboot or power on, the server updates.
When I try and connect my second PF I get the same issue in that it cycles through it's LED's seems to hesitate on the Green then flashed Red a few times and "shuts down". However it seems that it has actually attached to the Pi server... I am now running a fermentation on both PF's to see if they are both actually working and sending data.

Does this message in "/var/log/nginx/picobrew.error.log" mean anything of import?
2021/01/29 13:10:53 [error] 702#702: *7 upstream timed out (110: Connection timed out) while reading response header from upstream, client: <IP_ADDRESS>, server: www.picobrew.com, request: "GET /socket.io/?EIO=3&transport=polling&t=NTF-nsx&sid=0d1db2a590b1468dbaa97b3639905866 HTTP/1.1", upstream: "http://<IP_ADDRESS>:8080/socket.io/?EIO=3&transport=polling&t=NTF-nsx&sid=0d1db2a590b1468dbaa97b3639905866", host: "<IP_ADDRESS>", referrer: "http://<IP_ADDRESS>/"

Does this message in "/var/log/nginx/picobrew.error.log" mean anything of import?
2021/01/29 13:10:53 [error] 702#702: *7 upstream timed out (110: Connection timed out) while reading response header from upstream, client: <IP_ADDRESS>, server: www.picobrew.com, request: "GET /socket.io/?EIO=3&transport=polling&t=NTF-nsx&sid=0d1db2a590b1468dbaa97b3639905866 HTTP/1.1", upstream: "http://<IP_ADDRESS>:8080/socket.io/?EIO=3&transport=polling&t=NTF-nsx&sid=0d1db2a590b1468dbaa97b3639905866", host: "<IP_ADDRESS>", referrer: "http://<IP_ADDRESS>/"

We use socket.io to broadcast brew events/graph updates to any attached web browsers.. you can ignore those errors

We use socket.io to broadcast brew events/graph updates to any attached web browsers.. you can ignore those errors

Hmm, ok I found the code changes on GitHub that were made yesterday and ssh'd in and looked at routes_frontend.py and I'm definitely running the latest code.
I'm able to connect the PicoFerm, I think. I can see the Picoferm's blank graph in the UI and can hit 'start fermentation' on the picobrew server web interface, and it responds with "success".
When I push the button on top of the PicoFerm it scans through its lights a couple of times, does a solid red for a second, and then blinks yellow. Blinking yellow apparently means 'fermentation in progress' according to the little info card that came with the Picoferm. So far so good.
It's been a few minutes, and the Picobrew server interface seems to show a completely blank graph for the PicoFerm data:

Should I be expecting to see something there? Or does that happen on a long timescale and I just need to be patient? I'm wondering if any data is getting passed around. If I open a new browser tab and point it at the picobrew server UI and then open up "Sessions > Firm History", the list is blank.

Hmm, ok I found the code changes on GitHub that were made yesterday and ssh'd in and looked at routes_frontend.py and I'm definitely running the latest code.
I'm able to connect the PicoFerm, I think. I can see the Picoferm's blank graph in the UI and can hit 'start fermentation' on the picobrew server web interface, and it responds with "success".
When I push the button on top of the PicoFerm it scans through its lights a couple of times, does a solid red for a second, and then blinks yellow. Blinking yellow apparently means 'fermentation in progress' according to the little info card that came with the Picoferm. So far so good.
It's been a few minutes, and the Picobrew server interface seems to show a completely blank graph for the PicoFerm data:

Should I be expecting to see something there? Or does that happen on a long timescale and I just need to be patient? I'm wondering if any data is getting passed around. If I open a new browser tab and point it at the picobrew server UI and then open up "Sessions > Firm History", the list is blank.

Seems to take a while for data to report. Like the PicoFerm delivers in chunks or something, but I can't quite pin down the interval. Give it at least 15-30 minutes before giving up.

Seems to take a while for data to report. Like the PicoFerm delivers in chunks or something, but I can't quite pin down the interval. Give it at least 15-30 minutes before giving up.

Picoferms spit out API/PicoFerm/logDataSet?uid=5ccf7f5cc3cf&rate=5&voltage=3.19&data=[{"s1":69.90,"s2":1.69},{"s1":69.73,"s2":1.69},{"s1":69.55,"s2":1.69},{"s1":69.39,"s2":1.69},{"s1":69.24,"s2":1.70},{"s1":69.11,"s2":1.70},{"s1":68.97,"s2":1.70},{"s1":68.84,"s2":1.70},{"s1":68.72,"s2":1.70},{"s1":68.62,"s2":1.70},{"s1":69.02,"s2":1.70},{"s1":69.87,"s2":1.71}]
Rate tells you how long between data points, so for that update, there are 12 points, with a rate of 5 min between points, so it dumps every hour.

Picoferms spit out API/PicoFerm/logDataSet?uid=5ccf7f5cc3cf&rate=5&voltage=3.19&data=[{"s1":69.90,"s2":1.69},{"s1":69.73,"s2":1.69},{"s1":69.55,"s2":1.69},{"s1":69.39,"s2":1.69},{"s1":69.24,"s2":1.70},{"s1":69.11,"s2":1.70},{"s1":68.97,"s2":1.70},{"s1":68.84,"s2":1.70},{"s1":68.72,"s2":1.70},{"s1":68.62,"s2":1.70},{"s1":69.02,"s2":1.70},{"s1":69.87,"s2":1.71}]
Rate tells you how long between data points, so for that update, there are 12 points, with a rate of 5 min between points, so it dumps every hour.

Check for other errors in the "nginx error log" from /logs or ssh in and grab them from the relative nginx folders.
There are some users reporting internal nginx connect errors between nginx and flask. We are still trying to find the best way to squash these as both processes are always available.

Check for other errors in the "nginx error log" from /logs or ssh in and grab them from the relative nginx folders.
There are some users reporting internal nginx connect errors between nginx and flask. We are still trying to find the best way to squash these as both processes are always available.

Regarding the ip of the Picoferm. I have a branch where I'm tracking that for my debugging. I'm thinking of adding that "metadata" to the /devices experience for those interested.
There are some future "features" that could benefit from tracking this data: PicoStill and Z "unreleased firmware" 0.0.119 both have embedded web UIs that could be of benefit pulling.

Regarding the ip of the Picoferm. I have a branch where I'm tracking that for my debugging. I'm thinking of adding that "metadata" to the /devices experience for those interested.
There are some future "features" that could benefit from tracking this data: PicoStill and Z "unreleased firmware" 0.0.119 both have embedded web UIs that could be of benefit pulling.

Found some interesting messages in /var/log/nginx/picobrew.error.log
Attaching as text to try and not have it be formatted unreadably.
For what it's worth I only set the Raspberry Pi 4's time zone around 2:30pm today, so everything in the log before 14:57:32 has messed up dates/times.
picobrew.error.log.txt

Found some interesting messages in /var/log/nginx/picobrew.error.log
Attaching as text to try and not have it be formatted unreadably.
For what it's worth I only set the Raspberry Pi 4's time zone around 2:30pm today, so everything in the log before 14:57:32 has messed up dates/times.
picobrew.error.log.txt

My PF has the same sequence of LED's one is transmitting data the second one is quiet. I have reattached it to the Pi with the same attach results as the first PF but no data. I have initiated another session.
I think being able to see the PF IP would be useful here just simply pinging it from my laptop showing that it is actually attached to the network when I push the button....

My PF has the same sequence of LED's one is transmitting data the second one is quiet. I have reattached it to the Pi with the same attach results as the first PF but no data. I have initiated another session.
I think being able to see the PF IP would be useful here just simply pinging it from my laptop showing that it is actually attached to the network when I push the button....

I connected to the PICOBREW network and was able to ping <IP_ADDRESS>, my picoferm's IP address. Actually I set up a ping and got 'Host is down' messages repeatedly until I hit the power button on the PicoFerm, at which point I got 5 pings before the request timeouts returned.
`...
Request timeout for icmp_seq 10
64 bytes from <IP_ADDRESS>: icmp_seq=11 ttl=255 time=75.392 ms
64 bytes from <IP_ADDRESS>: icmp_seq=12 ttl=255 time=3.148 ms
64 bytes from <IP_ADDRESS>: icmp_seq=13 ttl=255 time=121.819 ms
64 bytes from <IP_ADDRESS>: icmp_seq=14 ttl=255 time=83.305 ms
64 bytes from <IP_ADDRESS>: icmp_seq=15 ttl=255 time=44.744 ms
Request timeout for icmp_seq 16
...`
This would be consistent with the Picoferm connecting momentarily to transmit data to the server.  Clearly it is connecting to the access point provided by the picobrew server. Unfortunately I don't know how to verify whether any data is received or used.
(btw sorry for double-spacing my console output, for whatever reason github's code section doesn't seem to like the newlines within it and just runs all the text together unless I do this)

I connected to the PICOBREW network and was able to ping <IP_ADDRESS>, my picoferm's IP address. Actually I set up a ping and got 'Host is down' messages repeatedly until I hit the power button on the PicoFerm, at which point I got 5 pings before the request timeouts returned.
`...
Request timeout for icmp_seq 10
64 bytes from <IP_ADDRESS>: icmp_seq=11 ttl=255 time=75.392 ms
64 bytes from <IP_ADDRESS>: icmp_seq=12 ttl=255 time=3.148 ms
64 bytes from <IP_ADDRESS>: icmp_seq=13 ttl=255 time=121.819 ms
64 bytes from <IP_ADDRESS>: icmp_seq=14 ttl=255 time=83.305 ms
64 bytes from <IP_ADDRESS>: icmp_seq=15 ttl=255 time=44.744 ms
Request timeout for icmp_seq 16
...`
This would be consistent with the Picoferm connecting momentarily to transmit data to the server.  Clearly it is connecting to the access point provided by the picobrew server. Unfortunately I don't know how to verify whether any data is received or used.
(btw sorry for double-spacing my console output, for whatever reason github's code section doesn't seem to like the newlines within it and just runs all the text together unless I do this)

Also -- when I was able to ping the PicoFerm I immediately tried to load it's IP in a browser, but nothing happened. So I guess maybe it only exposes a web interface is when it's in configuration mode on its own access point.

Also -- when I was able to ping the PicoFerm I immediately tried to load it's IP in a browser, but nothing happened. So I guess maybe it only exposes a web interface is when it's in configuration mode on its own access point.

Yes the AP mode is the only way I've seen to get a web experience. I'll check out the logs and see if they align with other reported errors.

Yes the AP mode is the only way I've seen to get a web experience. I'll check out the logs and see if they align with other reported errors.

Quickly glancing through the error log there is only mentions of the socketio interface (that your browser is communicating to realtime update graphs) and nothing that the firm would be communicating to.
Hrm...
Where is the one PF in relationship to the one that is reporting data?

Quickly glancing through the error log there is only mentions of the socketio interface (that your browser is communicating to realtime update graphs) and nothing that the firm would be communicating to.
Hrm...
Where is the one PF in relationship to the one that is reporting data?

For the test run with both PF's, well lets just say it went strange... I let it run for a few hours with no data to the graphs for either PF and both PF's were periodically cycling through all the LED's for a few minutes, stop and a short time later start again, this wasn't the "normal" cycling when they are sending data during a "good" fermentation session they just cycled continuously for a few minutes.
I have attached the log file, hopefully this will give some light on what was happening.
picobrew_pico.log

For the test run with both PF's, well lets just say it went strange... I let it run for a few hours with no data to the graphs for either PF and both PF's were periodically cycling through all the LED's for a few minutes, stop and a short time later start again, this wasn't the "normal" cycling when they are sending data during a "good" fermentation session they just cycled continuously for a few minutes.
I have attached the log file, hopefully this will give some light on what was happening.
picobrew_pico.log

Here's a full set of logs from my picobrew server. I've still got a blank PicoFerm graph with no indication of voltage or any data. The PicoFerm lights up and cycles its LEDs for 20 seconds or so on its own schedule, ending with 5 flashes of the red 'error' LED. I'm pretty sure as I verified before through pings that it is indeed connecting to the PICOBREW access point, but I guess it's not succeeding at getting its data into picobrew server. Happy to run any further diagnostics that might be of use.
nginx.error.log
picobrew_pico.log
nginx.access.log

Here's a full set of logs from my picobrew server. I've still got a blank PicoFerm graph with no indication of voltage or any data. The PicoFerm lights up and cycles its LEDs for 20 seconds or so on its own schedule, ending with 5 flashes of the red 'error' LED. I'm pretty sure as I verified before through pings that it is indeed connecting to the PICOBREW access point, but I guess it's not succeeding at getting its data into picobrew server. Happy to run any further diagnostics that might be of use.
nginx.error.log
picobrew_pico.log
nginx.access.log

Here's a full set of logs from my picobrew server. I've still got a blank PicoFerm graph with no indication of voltage or any data. The PicoFerm lights up and cycles its LEDs for 20 seconds or so on its own schedule, ending with 5 flashes of the red 'error' LED. I'm pretty sure as I verified before through pings that it is indeed connecting to the PICOBREW access point, but I guess it's not succeeding at getting its data into picobrew server. Happy to run any further diagnostics that might be of use.
nginx.error.log
picobrew_pico.log
nginx.access.log

Here's a full set of logs from my picobrew server. I've still got a blank PicoFerm graph with no indication of voltage or any data. The PicoFerm lights up and cycles its LEDs for 20 seconds or so on its own schedule, ending with 5 flashes of the red 'error' LED. I'm pretty sure as I verified before through pings that it is indeed connecting to the PICOBREW access point, but I guess it's not succeeding at getting its data into picobrew server. Happy to run any further diagnostics that might be of use.
nginx.error.log
picobrew_pico.log
nginx.access.log

I see that the PF with uid of 2c3ae83ac1fd is sending requests and is even able to log the data to the Pi successfully from the flask logs you uploaded. From those same logs there is another PF with uid of 60019458eac6 which seems to only go through the startup sequence. There are no errors or exceptions, but we also don't have the greatest logging to make it obvious what the response is to the Picoferm all conditions still end with a 200 - Ok response with details within the body of the request. It probably wouldn't be a bad idea to return addition data as to the meaning of the response body we send. That said I saw you did use the UI to click the start/stop buttons (again we should likely log the purpose of the requests and not just the 204 applied response status).

I see that the PF with uid of 2c3ae83ac1fd is sending requests and is even able to log the data to the Pi successfully from the flask logs you uploaded. From those same logs there is another PF with uid of 60019458eac6 which seems to only go through the startup sequence. There are no errors or exceptions, but we also don't have the greatest logging to make it obvious what the response is to the Picoferm all conditions still end with a 200 - Ok response with details within the body of the request. It probably wouldn't be a bad idea to return addition data as to the meaning of the response body we send. That said I saw you did use the UI to click the start/stop buttons (again we should likely log the purpose of the requests and not just the 204 applied response status).

At this point I'm not sure why your PF is failing to send the data.
From the access logs these are the 3 log lines that would say that the server simply "requested data to be sent".
<IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"

The PF is successfully on network and sending the start up sequence to the Pi multiple times (2 complete times) each time getting a successful response (though missing explicit understanding of response data which is how the PF is told to do things).

At this point I'm not sure why your PF is failing to send the data.
From the access logs these are the 3 log lines that would say that the server simply "requested data to be sent".
<IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=121b0618 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-" <IP_ADDRESS> - - [28/Jan/2021:18:02:51 -0500] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 4 "-" "-"

The PF is successfully on network and sending the start up sequence to the Pi multiple times (2 complete times) each time getting a successful response (though missing explicit understanding of response data which is how the PF is told to do things).

Though right now I'm on my mobile so could be that I quickly scrolled past it, will have to take a look at my computer when I get a chance this weekend.

The real strange part is I can find the related access logs for the successful data log posts.
Though right now I'm on my mobile so could be that I quickly scrolled past it, will have to take a look at my computer when I get a chance this weekend.

If I'm reading this correctly, @LEFsher has two picoferms and the one with uid 2c3ae83ac1fd is fully functioning and the one with pid 60019458eac6 is exhibiting possibly the same issue as my PicoFerm with pid 600194556b08. Could it be that the picoferms with uids starting with 6001945 are different somehow even though they're running the same firmware as 2c3ae83ac1fd?

If I'm reading this correctly, @LEFsher has two picoferms and the one with uid 2c3ae83ac1fd is fully functioning and the one with pid 60019458eac6 is exhibiting possibly the same issue as my PicoFerm with pid 600194556b08. Could it be that the picoferms with uids starting with 6001945 are different somehow even though they're running the same firmware as 2c3ae83ac1fd?

I have a<PHONE_NUMBER>5b and a 5ccf7f5ecffe. Both have worked flawlessly ever since I hooked them up to the Pi about 2 months ago.

I have a<PHONE_NUMBER>5b and a 5ccf7f5ecffe. Both have worked flawlessly ever since I hooked them up to the Pi about 2 months ago.

I think that data point rules out my speculation.

I think that data point rules out my speculation.

@sickchilly can I ask which version of picobrew server are you running? Maybe I can downgrade to that version (if different) and see if the PicoFerm data starts getting logged?

@sickchilly can I ask which version of picobrew server are you running? Maybe I can downgrade to that version (if different) and see if the PicoFerm data starts getting logged?

That won’t help you. I’m always on the latest which is 47ca104 at the moment.

That won’t help you. I’m always on the latest which is 47ca104 at the moment.

I did have someone have issues with a uid that python parsed as a scientific notation 12345678e123 (something like that all numbers and an e/exponent somewhere). That isn't happening here though so not sure what might be happening.
What we can do is take the access logs you have given and replay them to our local servers to see if the getState request returns the correct response after starting fermentation... But the content length shows this is likely returning the correct "send us data" response.

I did have someone have issues with a uid that python parsed as a scientific notation 12345678e123 (something like that all numbers and an e/exponent somewhere). That isn't happening here though so not sure what might be happening.
What we can do is take the access logs you have given and replay them to our local servers to see if the getState request returns the correct response after starting fermentation... But the content length shows this is likely returning the correct "send us data" response.

On a whim I reconnected my PicoFerm to my home network so it'd connect to the official picobrew.com servers. Since I'm in the process of doing secondary fermentation of some kombucha in the keg with white wine yeast to try and make hard kombucha, I tried to create a recipe that'd involve the pico C doing no mashing or boiling or anything at all and would skip ahead to fermentation -- I failed to figure it out. Reconnected the PicoFerm to Picobrew server, loaded up the Picobrew Server's UI, and saw actual data points:

Those times across the bottom are not the current time, my raspberry pi has been set to Pacific Standard Time since yesterday afternoon. So maybe those data points were logged last night? I didn't look at the Picobrew server's UI before trying my attempt at seeing if the picobrew.com official server could read data from the PicoFerm - so I don't know if this was all there before my most recent reconnection to the picobrew server or not.
There is still nothing listed under "Sessions > Firm History".

On a whim I reconnected my PicoFerm to my home network so it'd connect to the official picobrew.com servers. Since I'm in the process of doing secondary fermentation of some kombucha in the keg with white wine yeast to try and make hard kombucha, I tried to create a recipe that'd involve the pico C doing no mashing or boiling or anything at all and would skip ahead to fermentation -- I failed to figure it out. Reconnected the PicoFerm to Picobrew server, loaded up the Picobrew Server's UI, and saw actual data points:

Those times across the bottom are not the current time, my raspberry pi has been set to Pacific Standard Time since yesterday afternoon. So maybe those data points were logged last night? I didn't look at the Picobrew server's UI before trying my attempt at seeing if the picobrew.com official server could read data from the PicoFerm - so I don't know if this was all there before my most recent reconnection to the picobrew server or not.
There is still nothing listed under "Sessions > Firm History".

These are data points to a "active" session. Since the Picoferm flushes data once an hour it is likely.
To verify you can download the nginx and python/flask logs again and I'll see what was reported and when to verify if both have been able to connect.

These are data points to a "active" session. Since the Picoferm flushes data once an hour it is likely.
To verify you can download the nginx and python/flask logs again and I'll see what was reported and when to verify if both have been able to connect.

OK, that data must have been there already -- as it turns out the PicoFerm did not successfully reconnect to the PICOBREW SSID at all just now.  It was waiting for me in access point mode. I connected to it and tried reconnecting it to the picobrew server again and watched its LEDs cycle for a bit before they all lit up solid as it popped back to access point mode. Then I tried again and got it to connect. Guess sometimes it takes a few tries -- I guess using the single radio on the Raspberry Pi 4 for both connecting to the home network and providing an access point is working for everyone else just fine but if it would reduce the complexity and were possible to do so I'd happily connect the Raspberry Pi to the home network via ethernet - it's about 5 feet from a switch with plenty of available ports.
Here's a new set of logs. Github understandably wouldn't let me attach the nginx_error.log because it's 0 bytes for some reason - maybe it turned over and hasn't accrued any errors since?
picobrew_pico.log
nginx.access.log

OK, that data must have been there already -- as it turns out the PicoFerm did not successfully reconnect to the PICOBREW SSID at all just now.  It was waiting for me in access point mode. I connected to it and tried reconnecting it to the picobrew server again and watched its LEDs cycle for a bit before they all lit up solid as it popped back to access point mode. Then I tried again and got it to connect. Guess sometimes it takes a few tries -- I guess using the single radio on the Raspberry Pi 4 for both connecting to the home network and providing an access point is working for everyone else just fine but if it would reduce the complexity and were possible to do so I'd happily connect the Raspberry Pi to the home network via ethernet - it's about 5 feet from a switch with plenty of available ports.
Here's a new set of logs. Github understandably wouldn't let me attach the nginx_error.log because it's 0 bytes for some reason - maybe it turned over and hasn't accrued any errors since?
picobrew_pico.log
nginx.access.log

If you have another machine on your network on which you can run your own DNS, you can enter a local DNS entry to redirect *.picobrew.com to the Pi server’s local IP. I do this with PiHole on my Ubuntu server. Blocks ads network-wide too.

If you have another machine on your network on which you can run your own DNS, you can enter a local DNS entry to redirect *.picobrew.com to the Pi server’s local IP. I do this with PiHole on my Ubuntu server. Blocks ads network-wide too.

Just to document the process by which I connected my picobrew server to ethernet and disabled the bridge, because I'm likely to forget all of it and maybe it'll help someone else:
My router's an Asus running Asuswrt-merlin firmware, so I configured its dns server to redirect picobrew.com as follows:

I made sure the raspberry pi's ethernet would always be manually assigned the local IP address <IP_ADDRESS> by the router's dhcp server.
In the router's Administration>System page, I toggled on to "Enable JFFS custom scripts and configs". Also enabled local ssh connections.
ssh'd into the router, and ran these commands: 'echo "<IP_ADDRESS> picobrew.com" >> /jffs/configs/hosts.add', ' echo "address=/picobrew.com/<IP_ADDRESS>" >> /jffs/configs/dnsmasq.conf.add', 'echo "cname=www.picobrew.com,picobrew.com" >> >> /jffs/configs/hosts.add' Followed by "service restart_dnsmasq".
ssh'd into the picobrew server, and ran the following commands: 'sudo systemctl stop dnsmasq.service', 'sudo systemctl disable dnsmasq.service' (these to make sure the picobrew server was no longer running a dhcp server). 'sudo ifconfig br0 down' (take down the bridge).
on the picobrew server, ran the command "sudo emacs 04-eth0.network" and edited the 04-eth0.network file to the following:
[Match] Name=eth0 [Network] #Bridge=br0 #ConfigureWithoutCarrier=yes LLMNR=no #LinkLocalAddressing=no MulticastDNS=yes DHCP=yes

And I think that was it. I rebooted the picobrew server and it now connects via ethernet and gets assigned <IP_ADDRESS> on its ethernet port. My router is redirecting www.picobrew.com and picobrew.com to <IP_ADDRESS>.
Todo:

Connect the picoferm and pico C to my normal wifi access point on the local network and see if they connect to picobrew server.
pop into the raspberry pi and configure the wifi interface to stop connecting to my local network (doesn't seem super important at the moment). Also make sure the bridge stays down (important?).

Just to document the process by which I connected my picobrew server to ethernet and disabled the bridge, because I'm likely to forget all of it and maybe it'll help someone else:
My router's an Asus running Asuswrt-merlin firmware, so I configured its dns server to redirect picobrew.com as follows:

I made sure the raspberry pi's ethernet would always be manually assigned the local IP address <IP_ADDRESS> by the router's dhcp server.
In the router's Administration>System page, I toggled on to "Enable JFFS custom scripts and configs". Also enabled local ssh connections.
ssh'd into the router, and ran these commands: 'echo "<IP_ADDRESS> picobrew.com" >> /jffs/configs/hosts.add', ' echo "address=/picobrew.com/<IP_ADDRESS>" >> /jffs/configs/dnsmasq.conf.add', 'echo "cname=www.picobrew.com,picobrew.com" >> >> /jffs/configs/hosts.add' Followed by "service restart_dnsmasq".
ssh'd into the picobrew server, and ran the following commands: 'sudo systemctl stop dnsmasq.service', 'sudo systemctl disable dnsmasq.service' (these to make sure the picobrew server was no longer running a dhcp server). 'sudo ifconfig br0 down' (take down the bridge).
on the picobrew server, ran the command "sudo emacs 04-eth0.network" and edited the 04-eth0.network file to the following:
[Match] Name=eth0 [Network] #Bridge=br0 #ConfigureWithoutCarrier=yes LLMNR=no #LinkLocalAddressing=no MulticastDNS=yes DHCP=yes

And I think that was it. I rebooted the picobrew server and it now connects via ethernet and gets assigned <IP_ADDRESS> on its ethernet port. My router is redirecting www.picobrew.com and picobrew.com to <IP_ADDRESS>.
Todo:

Connect the picoferm and pico C to my normal wifi access point on the local network and see if they connect to picobrew server.
pop into the raspberry pi and configure the wifi interface to stop connecting to my local network (doesn't seem super important at the moment). Also make sure the bridge stays down (important?).

Good sign:

Which corresponds to this entry from picobrew.access.log:
`<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=3e601766 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 6 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/logDataSet?uid=600194556b08&rate=5&voltage=3.22&data=[{\x22s1\x22:66.70,\x22s2\x22:0.00},{\x22s1\x22:66.54,\x22s2\x22:0.00},{\x22s1\x22:66.40,\x22s2\x22:0.00},{\x22s1\x22:66.27,\x22s2\x22:0.00},{\x22s1\x22:66.19,\x22s2\x22:0.00},{\x22s1\x22:66.25,\x22s2\x22:0.00},{\x22s1\x22:66.25,\x22s2\x22:0.00},{\x22s1\x22:66.20,\x22s2\x22:0.00},{\x22s1\x22:66.44,\x22s2\x22:0.00},{\x22s1\x22:66.57,\x22s2\x22:0.00},{\x22s1\x22:66.65,\x22s2\x22:0.00},{\x22s1\x22:70.99,\x22s2\x22:0.28}] HTTP/1.0" 200 6 "-" "-"
`
Note the <IP_ADDRESS> IP address -- The picoferm is on my real LAN but is logging info to the picobrew server - and this is the first time I've witnessed a "logDataSet", though obviously some did make it through in the previous configuration due to the fact that there were some sporadic data points.
It bodes well that it logged a data point so soon after the network reconfiguration (I think), and also when I hit the status/power button on the picoferm it doesn't end in the red error LED after cycling but instead blinks yellow (which means 'in progress'). I'm feeling some positivity. I stopped the fermentation in the UI and started again to get a fresh graph as my data recorded was so sporadic before. And now I've got the previous session in 'ferm History'.

Good sign:

Which corresponds to this entry from picobrew.access.log:
`<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/isRegistered?uid=600194556b08&token=3e601766 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/checkFirmware?uid=600194556b08&version=0.2.6 HTTP/1.0" 200 3 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/getState?uid=600194556b08 HTTP/1.0" 200 6 "-" "-"
<IP_ADDRESS> - - [30/Jan/2021:16:53:06 -0800] "GET /API/PicoFerm/logDataSet?uid=600194556b08&rate=5&voltage=3.22&data=[{\x22s1\x22:66.70,\x22s2\x22:0.00},{\x22s1\x22:66.54,\x22s2\x22:0.00},{\x22s1\x22:66.40,\x22s2\x22:0.00},{\x22s1\x22:66.27,\x22s2\x22:0.00},{\x22s1\x22:66.19,\x22s2\x22:0.00},{\x22s1\x22:66.25,\x22s2\x22:0.00},{\x22s1\x22:66.25,\x22s2\x22:0.00},{\x22s1\x22:66.20,\x22s2\x22:0.00},{\x22s1\x22:66.44,\x22s2\x22:0.00},{\x22s1\x22:66.57,\x22s2\x22:0.00},{\x22s1\x22:66.65,\x22s2\x22:0.00},{\x22s1\x22:70.99,\x22s2\x22:0.28}] HTTP/1.0" 200 6 "-" "-"
`
Note the <IP_ADDRESS> IP address -- The picoferm is on my real LAN but is logging info to the picobrew server - and this is the first time I've witnessed a "logDataSet", though obviously some did make it through in the previous configuration due to the fact that there were some sporadic data points.
It bodes well that it logged a data point so soon after the network reconfiguration (I think), and also when I hit the status/power button on the picoferm it doesn't end in the red error LED after cycling but instead blinks yellow (which means 'in progress'). I'm feeling some positivity. I stopped the fermentation in the UI and started again to get a fresh graph as my data recorded was so sporadic before. And now I've got the previous session in 'ferm History'.

Sooo.. if you can redirect off your router.. I HIGHLY recommend just running the server off your PC and connecting any pico device to your main wifi and ditch the pi.. you won't have any drop outs.

Sooo.. if you can redirect off your router.. I HIGHLY recommend just running the server off your PC and connecting any pico device to your main wifi and ditch the pi.. you won't have any drop outs.

Even if I'm not using the Raspberry to provide a wifi access point I still like it as a low-wattage server.
I seem to be getting reliable data logs from the pico ferm now:

This is probably not news to anyone, but it looks like the Picoferm is based on an Espressif chip.
$ arp -a
ESP_556B08 (<IP_ADDRESS>) at 60:01:94:55:6b:08 [ether] on wlan0

Even if I'm not using the Raspberry to provide a wifi access point I still like it as a low-wattage server.
I seem to be getting reliable data logs from the pico ferm now:

This is probably not news to anyone, but it looks like the Picoferm is based on an Espressif chip.
$ arp -a
ESP_556B08 (<IP_ADDRESS>) at 60:01:94:55:6b:08 [ether] on wlan0

If you're hooked on using a pi, I'd just flash a canned raspios image without any of our network modification and then just manually install it that way, so that the pi doesn't do ap + client... But whatever

If you're hooked on using a pi, I'd just flash a canned raspios image without any of our network modification and then just manually install it that way, so that the pi doesn't do ap + client... But whatever

@czyz when you had your pi connected WiFi to your network did you make sure it was "locked" to a 2.4ghz network cause if it ever switched to 5.0ghz even just briefly that would cause lots of problems with your Pico devices for connectivity.
Redirecting network traffic from a router is definitely an easier and more reliable setup than from within the Pi reusing the single band wifi chipset for sure.
We setup the default image to have eth0 available for the hardwired Z and Zy machines.  Several users report that these routers force the Pi over to a 5.0ghz network all the time regardless of what you do client side to prevent it 🤷♂.
Glad you have something working for you.

@czyz when you had your pi connected WiFi to your network did you make sure it was "locked" to a 2.4ghz network cause if it ever switched to 5.0ghz even just briefly that would cause lots of problems with your Pico devices for connectivity.
Redirecting network traffic from a router is definitely an easier and more reliable setup than from within the Pi reusing the single band wifi chipset for sure.
We setup the default image to have eth0 available for the hardwired Z and Zy machines.  Several users report that these routers force the Pi over to a 5.0ghz network all the time regardless of what you do client side to prevent it 🤷♂.
Glad you have something working for you.

Success both PF's connected and loading data for the fermentation session, I started one then the other about 2 minutes after. The second one took about twice as long to start showing data on the chart but I ended up with two fermentation sessions working and then being able to terminate see attached log file. Cheers and thanks for all of the help :)
Data 31 Jan both PF's running.log

@czyz when you had your pi connected WiFi to your network did you make sure it was "locked" to a 2.4ghz network

It was definitely connecting to only a 2.4GHz network. I have my 5GHz network set to a different SSID. However I do have a mesh system in place, so it's possible that it was handed off from one 2.4GHz access point to another with the same SSID, though I'd expect that wouldn't happen with the kind of frequency that would keep the picoferm from connecting to it for days. Also the Picobrew C seemed to connect just fine, or at least didn't complain about it.

Glad you have something working for you.

Thanks. At the moment I wanted to make sure my never-before-used picoferm was even functional, and wanted to monitor a batch that was in progress. So Connectivity was more important than testing. But I'll be trying the original wifi-only setup again in the future.


chore: init repo

Haskell IP routing table
Issue: https://github.com/linuxdeepin/developer-center/issues/5731
Log: init repo

/check obs

/approve


fix: actually apply found material.

A line of code went missing when adding a feature.

Oups, my bad, txs!


Resources page changes

closing #1629
Resources page:
@smellems   can you please add to each link that is only ESDC network ‘ESDC network’ label.
and if a link is only in English add ‘english only’ and ‘anglais seulement’ to the french page just like you did with strategies and initiatives pages.

Oh, that's a lot of changes :thinking: Will get started in between other tasks


Gh pages translation chinese

cc @bkeepers to provide input on how this fits into https://github.com/github/open-source-guide/pull/295

cross-linking https://github.com/github/open-source-guide/issues/328 for reference

Hey @lijiangsheng1, I'm going to close this for now. Let's keep track of progress in #328 and and re-open this later when the translation is done.


Song length display

Total length(time) of song

Hi !
I would like to work on this issue, if is still open.
Could you please assign it to me ?

Sure, go ahead.

revoking because of inactivity.


Does the css/shadow transformer need to be adjusted for w3c spec?

W3C spec shows using "offset" in the x and y keys.
{
  "shadow-token": {
    "$type": "shadow",
    "$value": {
      "color": "#00000080",
      "offsetX": "0.5rem",
      "offsetY": "0.5rem",
      "blur": "1.5rem",
      "spread": "0rem"
    }
  }
}

SDU uses this:
{
  shadow: {
    small: {
      value: {
        "color": "#00000066",
        "x": "0px",
        "y": "1px",
        "blur": "2px",
        "spread": "0px"
      },
      $type: "shadow"
    }
  }
}

sorry. I did a search but didn't find the other issue. Thanks!

Ahh, there is no other issue. I just pushed a PR yesterday to fix this after I saw your issue. 😄


Error loading and compiling book yuushya:yuushya_guidebook, using empty contents

Looking into log i found this issue:
https://gist.github.com/Colluttorio/d0da247ade856ff60ce3a01be02a92e1

will remove it in newer version


Setting the quality of the video playback depending on network speed

Is your feature request related to a problem? Please describe.
Hi, This library is great. Thanks!
Many parts of the world, the network speed is very slow, and there is no option to set the quality of the video played
Describe the solution you'd like
Set the quality of the video playback depending on network speed/ option to change the quality.

Hi @niftykurian , are you using tracks to switch them? You might need to provide the proper tracks in each bitrate.

I have the same issue here. it's will be helpful if we have control of quality and auto-switch when we have a slow internet connection.
this example video has multi quality: https://content.jwplatform.com/manifests/yp34SRmf.m3u8
you can see it from here: https://www.jwplayer.com/developers/stream-tester/


Calcite Javascript issue with v1.0.0-beta.24

Calcite-web js is not working with version v1.0.0-beta.24. It is throwing following error.
"GlobalTypeError: global is undefined".

Note: This issue is reproducible if calcite is installed through NPM. It's working fine when I copy the javascript manually from zip folder (https://github.com/Esri/calcite-web/releases/download/v1.0.0-beta.24/calcite-web.zip)

@sanjibpanda Can you provide more context of how your including the library in your application from the node modules folder? I have this version running fine in an app, and cannot repro.

Ah ok.. bit weird then. I installed calcite through npm as instructed. When I runs Grunt, it push a copy of calcite-web.js from node modules to my build/... folder from where I see the pages on browser. I was comparing the calcite-web.js (using node modules) from my app with the one I gets from the downloadable version and found that there is an extra block of javascript. Not sure how it's getting appended in calcite-web.js. Here is how it looks like:
/* living-atlas-next - v1.0.0-beta.24 - 2016-07-11
*  https://github.com/ArcGIS/living-atlas-next
*  Copyright (c) 2016 Environmental Systems Research Institute, Inc.
*  Apache 2.0 License */
(function (global, factory) {
  typeof exports === 'object' && typeof module !== 'undefined' ? factory() :
  typeof define === 'function' && define.amd ? define(factory) :
  (factory());
}(this, function () { 'use strict';

  /* calcite-web - v1.0.0-beta.24 - 2016-06-01
  *  https://github.com/esri/calcite-web
  *  Copyright (c) 2016 Environmental Systems Research Institute, Inc.
  *  Apache 2.0 License */
  (function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
    typeof define === 'function' && define.amd ? define(factory) :
    (global.calcite = factory());
  }(undefined, function () { 'use strict';

    // ┌────────────────────┐
    // │ Class Manipulation │
    // └────────────────────┘

Not sure, whether something from my Gruntfile is causing this issue. If you want I can send you the gruntfile we are using , if that will help us to narrow down the issue.

Yes please! E-mail or private gist or link to the repo or whatever would work for you.

Tooling trubs!


WIP: Test secretless authentication on GKE

This modified script will create a GKE cluster and set up: venafi-enhanced-issuer, approver-policy-enterprise, and venafi-kubernetes-agent to authenticate to Venafi Control Plane using a Kubernetes ServiceAccount Token.
$ ./hack/e2e/test.sh
...
2024/08/23 16:35:02 Venafi Connection mode was specified, using Venafi Connection authentication.
2024/08/23 16:35:02 ignoring venafi-cloud.upload_path. In Venafi Connection mode, this field is not needed.
2024/08/23 16:35:02 ignoring venafi-cloud.uploader_id. In Venafi Connection mode, this field is not needed.
2024/08/23 16:35:02 Prometheus was enabled.
Running prometheus server on port :8081
2024/08/23 16:36:13 Posting data to: https://api.venafi.cloud/
2024/08/23 16:36:13 retrying in 20.592925933s after error: post to server failed: while loading the VenafiConnection venafi/venafi-components: VenafiConnection.jetstack.io "venafi-components" not found
2024/08/23 16:36:34 Posting data to: https://api.venafi.cloud/
2024/08/23 16:36:34 retrying in 55.382780171s after error: post to server failed: while loading the VenafiConnection venafi/venafi-components: VenafiConnection.jetstack.io "venafi-components" not found
2024/08/23 16:37:29 Posting data to: https://api.venafi.cloud/
2024/08/23 16:37:31 Data sent successfully.

$ kubectl get venaficonnection -n venafi -o yaml
...
  status:
    conditions:
    - lastTransitionTime: "2024-08-27T16:52:14Z"
      lastUpdateTime: "2024-08-28T16:28:22Z"
      message: d97b3a02ea4dbd895aa730df409d9a15011aab855d710d59822e852cb84fae64
      observedGeneration: 3
      reason: Generated a token
      status: "True"
      tokenValidUntil: "2024-08-28T16:43:22Z"
      type: VenafiKubernetesAgentReady
    - lastTransitionTime: "2024-08-28T11:14:55Z"
      lastUpdateTime: "2024-08-28T16:41:11Z"
      message: 9822840ae10e13e9a0a7f6a0d74c8e70a201892a0e1aef8268f4e9527945eb2e
      observedGeneration: 3
      reason: Generated a token
      status: "True"
      tokenValidUntil: "2024-08-28T16:56:11Z"
      type: VenafiEnhancedIssuerReady
    - lastTransitionTime: "2024-08-28T14:36:22Z"
      lastUpdateTime: "2024-08-28T16:27:34Z"
      message: 51f7b1e16e7a5ac9255d019e1cf50857ebe04f2eb78892d45e1cdc96e01aa87c
      observedGeneration: 3
      reason: Generated a token
      status: "True"
      tokenValidUntil: "2024-08-28T16:42:34Z"
      type: ApproverPolicyVenafiReady

Here are the corresponding events from the Venafi Control Plane event log

Ref: VC-35374

I've run the script with the US https://ven-tlspk.venafi.cloud/ using the following settings:
export VEN_API_KEY=$(lpass show -p ven-tlspk.venafi.cloud)
export \
 VEN_OWNING_TEAM=$(curl --fail-with-body -sS https://api.venafi.cloud/v1/teams -H "tppl-api-key: $VEN_API_KEY" | jq '.teams[0].id' -r) \
 OCI_BASE=ttl.sh/maelvls \
 VEN_API_KEY_PULL=$(lpass show -p glow-in-the-dark.venafi.cloud) \
 VEN_API_HOST=api.venafi.cloud \
 VEN_ZONE='tlspk-bench\Default' \
 CLOUDSDK_CORE_PROJECT=jetstack-mael-valais \
 CLOUDSDK_COMPUTE_ZONE=europe-west1-b \
 CLUSTER_NAME=test-secretless

Unfortunately, it stopped with some 400:
+ jq -n '{
      "name": "venafi-kubernetes-agent-e2e-agent-\($random)",
      "authenticationType": "rsaKeyFederated",
      "scopes": ["kubernetes-discovery-federated", "certificate-issuance"],
      "subject": $subject,
      "audience": $audience,
      "issuerURL": $issuerURL,
      "jwksURI": $jwksURI,
      "applications": [$applications.applications[].id],
      "owner": $teams.teams[] | select(.name==$teamName) | .id
    }' --arg random 21821 --arg teamName 8c8f7450-6159-11ef-80cf-cb480ca9e3bf --arg subject system:serviceaccount:venafi:venafi-components --arg audience https://api.venafi.cloud --arg issuerURL https://container.googleapis.com/v1/projects/jetstack-mael-valais/locations/europe-west1-b/clusters/test-secretless --arg jwksURI https://container.googleapis.com/v1/projects/jetstack-mael-valais/locations/europe-west1-b/clusters/test-secretless/jwks --argjson teams '{"teams":[{"id":"8c8f7450-6159-11ef-80cf-cb480ca9e3bf","name":"RichardW","systemRoles":["SYSTEM_ADMIN"],"productRoles":{},"role":"SYSTEM_ADMIN","members":["d6175270-6526-11ef-a333-43042b807b68","a643a0e0-6525-11ef-a333-43042b807b68"],"owners":["76a126f0-280e-11ee-84fb-991f3177e2d0"],"companyId":"756db001-280e-11ee-84fb-991f3177e2d0","userMatchingRules":[],"modificationDate":"2024-08-28T11:18:01.932+00:00"},{"id":"d2508300-3705-11ee-a17b-69a77fb429d7","name":"test team anuar","systemRoles":["SYSTEM_ADMIN"],"productRoles":{},"role":"SYSTEM_ADMIN","members":[],"owners":["8833bf90-280e-11ee-84fb-991f3177e2d0","85836ca0-280e-11ee-8261-4748584228c9","7820e920-280e-11ee-84fb-991f3177e2d0","8034ef30-280e-11ee-8261-4748584228c9","7ac07330-280e-11ee-850d-2d2b2126b237","7ec559a0-280e-11ee-8261-4748584228c9","82d93430-280e-11ee-84fb-991f3177e2d0","843d3100-280e-11ee-850d-2d2b2126b237","7977c690-280e-11ee-850d-2d2b2126b237","76a126f0-280e-11ee-84fb-991f3177e2d0","7d6ad2b0-280e-11ee-8261-4748584228c9","86e98c50-280e-11ee-84fb-991f3177e2d0","7c0eec30-280e-11ee-84fb-991f3177e2d0","817d26a0-280e-11ee-8261-4748584228c9"],"companyId":"756db001-280e-11ee-84fb-991f3177e2d0","userMatchingRules":[],"modificationDate":"2023-08-09T22:41:03.910+00:00"}]}' --argjson applications '{"applications":[{"id":"d4eed080-0c5c-11ef-bb93-97de0c09752f","companyId":"756db001-280e-11ee-84fb-991f3177e2d0","name":"admin","description":"","ownerIdsAndTypes":[{"ownerId":"85836ca0-280e-11ee-8261-4748584228c9","ownerType":"USER"},{"ownerId":"817d26a0-280e-11ee-8261-4748584228c9","ownerType":"USER"}],"fullyQualifiedDomainNames":[],"ipRanges":[],"ports":[],"certificateIssuingTemplateAliasIdMap":{"Default":"7665cba2-280e-11ee-abfe-69743765b4a4"},"modificationDate":"2024-05-07T10:30:32.072+00:00","creationDate":"2024-05-07T10:30:32.072+00:00","ownership":{"owningUsers":["85836ca0-280e-11ee-8261-4748584228c9","817d26a0-280e-11ee-8261-4748584228c9"]}},{"id":"7eaf1c90-0c5a-11ef-8710-4f78e0e5228b","companyId":"756db001-280e-11ee-84fb-991f3177e2d0","name":"test","description":"","ownerIdsAndTypes":[{"ownerId":"7d6ad2b0-280e-11ee-8261-4748584228c9","ownerType":"USER"},{"ownerId":"7c0eec30-280e-11ee-84fb-991f3177e2d0","ownerType":"USER"}],"fullyQualifiedDomainNames":[],"ipRanges":[],"ports":[],"certificateIssuingTemplateAliasIdMap":{"Default":"7665cba2-280e-11ee-abfe-69743765b4a4"},"modificationDate":"2024-05-07T10:13:48.377+00:00","creationDate":"2024-05-07T10:13:48.377+00:00","ownership":{"owningUsers":["7d6ad2b0-280e-11ee-8261-4748584228c9","7c0eec30-280e-11ee-84fb-991f3177e2d0"]}},{"id":"b2d36e20-0c5c-11ef-aa2e-f3a8a6dc81e8","companyId":"756db001-280e-11ee-84fb-991f3177e2d0","name":"test1","description":"","ownerIdsAndTypes":[{"ownerId":"843d3100-280e-11ee-850d-2d2b2126b237","ownerType":"USER"},{"ownerId":"7d6ad2b0-280e-11ee-8261-4748584228c9","ownerType":"USER"}],"fullyQualifiedDomainNames":[],"ipRanges":[],"ports":[],"certificateIssuingTemplateAliasIdMap":{},"modificationDate":"2024-05-07T10:29:34.850+00:00","creationDate":"2024-05-07T10:29:34.850+00:00","ownership":{"owningUsers":["7d6ad2b0-280e-11ee-8261-4748584228c9","843d3100-280e-11ee-850d-2d2b2126b237"]}},{"id":"303ce460-652f-11ef-a63d-e32bbc0dac9e","companyId":"756db001-280e-11ee-84fb-991f3177e2d0","name":"tlspk-bench","description":"For benchmarking with tlspk-bench","ownerIdsAndTypes":[{"ownerId":"8c8f7450-6159-11ef-80cf-cb480ca9e3bf","ownerType":"TEAM"}],"fullyQualifiedDomainNames":[],"ipRanges":[],"ports":[],"certificateIssuingTemplateAliasIdMap":{"Default":"7665cba2-280e-11ee-abfe-69743765b4a4"},"modificationDate":"2024-08-28T11:18:01.894+00:00","creationDate":"2024-08-28T11:18:01.894+00:00","ownership":{"owningTeams":["8c8f7450-6159-11ef-80cf-cb480ca9e3bf"]}}]}'

curl: (56) The requested URL returned error: 400

I admit I wasn't able to debug the issue... I trust that you have tested the script.
Thanks for testing with an EU tenant too!

@maelvls Thanks for reviewing. The script does indeed work for me, but I know there are some rough edges. Since you've approved it now, I'll make it better in followup PRs.


Improve error message on failure to create function

Details
I tried creating the following function which fails.  The error message returned is not helpful to figuring out why this did not work.  Can this error message be improved?
CREATE FUNCTION spi_srf()
    RETURNS TABLE(id BIGINT)
    LANGUAGE plrust
AS
$$
    let query = "SELECT id::BIGINT FROM generate_series(1, 3) id;";

    Spi::connect(|client| {
        let mut results = Vec::new();
        let mut tup_table = client.select(query, None, None)?;

        while let Some(row) = tup_table.next() {
            let id = row["id"].value::<i64>();

            results.push((id));
        }
        Ok(TableIterator::new(results.into_iter()))
    })

$$
;

Using /errverbose returns:
ERROR:  XX000: assertion failed: `(left == right)`
  left: `1`,
 right: `0`
LOCATION:  crating.rs:73

...Yes indeed, the error message can be improved. However, it is probably not your fault. The assertion that you just hit was never expected to be hit and suggests a bug in PL/Rust occurred.


[AutoPR vmwarecloudsimple/resource-manager] typo: vmwarecloudsimple

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/6415

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/6003


verify SHA of all downloaded test files

something like this:
https://github.com/LCSB-BioCore/SBML.jl/blob/9a674d010b36336cc843040c388693d0302f5c4d/test/loaddynamicmodels.jl#L66-L73
except throwing outright error on hash mismatch

(also, do not pre-load models)


Diff files after clicking on them

When I am staging files, I am going one by one to review to changes before staging them. I would like to see diff of file after clicking on them in right panel.

Same process for me, this feature will be great !

Opening files from the compare panel now works ( version 0.2.0 ) , however the diff isn't shown in the file.

:+1:

this is such an important enhancement and keeps me from using git-control entirely.
would you be open for PR for this?


Update grafana dashboards

Remove some unused dashboards, see commit.
Add link to the cloudwatch metrics to application dashboards instead of machine dashboards.

https://trello.com/c/ewzHAr6A/56-remove-postgresql-primary-and-postgresql-standby-infrastructure-and-configuration

I've deployed this to integration to try it out and I think there's a few issues to resolve (and various problems with our Grafana integration set-up :( )

Remove AWS link from machine - works
Cloudwatch metric links - doesn't seem to work for me. I can't see the postgres links and I think non postgres boards are raising an error as they're to show a panel with a height of 0 (there's also Elasticsearch query issues unreleated to these changes only present in integration)
Email Alert API link - this works to a staging or prod destination, it doesn't look like the cloudwatch metric source is working in integration (do we want to shave that yak)
Removed dashboards - this works

Hey @kevindew 👋 I've fixed the issues you've outlined and added config to Puppet to ensure we have the correct datasources and values if they're wiped from the machine (think this is what happened with CloudWatch in Integration).
The datasource values listed in the datasources manifest can still fall out sync with the actual datasources in Grafana though, as changes in the manifest will not be reflected unless the datasource is deleted from the Grafana UI first. Similarly, any datasources updated in the UI will not be overwritten by Puppet.
We probably want Puppet to overwrite existing datasources, but I think that would be a separate piece of work.
Let me know if you have Q's