Deployment issues with BrewPiRemix getting the scripts to run after fresh install

[Whozat]

Hello!

I am attempting to deploy a single chamber installation. Using Raspberry Pi 4b with a fresh install of Raspberry Pi OS (have tried Debian Bookworm 64-bit, 32-bit, as well as Debian Bullseye legacy) using an Arduino controller. The installation will complete, the website will load, but no scripts will run. I believe it has something to do with the virtual environment requirements for python that was pushed October of last year, but I don't know if that is the only issue. I will add pictures and can upload logs (as long as I can find the ones we need to review..), but I'm stuck with a website that will load, and nothing will deploy on the arduino, nor run on the website. I've tried manually loading the hex image onto the arduino thinking the script would run once loaded, but it doesn't change my outcome. I've reloaded RPi multiple times, I've ran through the installation steps multiple times, and I keep getting back to the same spot.

I've thought about adding the venv activate variable into the scripts, but that doesn't seem to get the whole script to run either. Is there something that I'm missing here? Do I need a different version of RasberryPi OS? Any guidance would be greatly appreciated!

[lbussy]

The contents of /home/brewpi/logs (I think that's right) will help.

[Whozat]

Sorry for the delay, all of the logs in that directory are blank. I'm going to also attach the bootstrap log, that's the only log that I've found with any actual information in it. You will see that I've attempted running things different ways, but still run into errors.
stderr.txt
stdout.txt
bootstrap.log

[Whozat]

I'm also attaching /home/brewpi/primary/LogMessages.h (renamed to .txt extension for attachment to here)
LogMessages.txt

[lbussy]

Yes, bootstrap.log is what I needed. I need some unbroken time to look at this. I suspect someone in Python world pointed out a "non-Pythonic design" and "fixed" it. :)

[lbussy]

This MAY brick your installation, so be aware burning another card may be needed.

Try this on a clean SD image:

sudo apt-get install libopenblas-dev

Then try the installer.

Warranty void where prohibited, may cause hair loss, halitosis, and bad feelings. Use only as directed, do not use internally. Read the directions, consult your doctor for any questions .... and so on. :)

[Whozat]

Thanks for your help Lee! I just performed that on a fresh install, ran the installer again, and the script appears to be running properly this time around! Was that something I missed in the instructions or something that is new?

[lbussy]

No, that's what I thought it was. It's Python people being Pythonic and just changing things that were working so they can make changes and call themselves DevOps.

I'll need to change the scripts, but I am glad you got it going. There's no reason you should need to make any changes when I patch it.

[lbussy]

By the way - which image did you use? Buster or Bookworm?

[Whozat]

I did it on a fresh Bookworm 64-bit image and the installers all ran as expected. Now I'm on to the next step of adding my temp probes and the like.

[Whozat]

Hey Lee, I know I'm coming back two weeks later, but is the above supposed to work for the additional chamber /home/pi/brewpi-tools-rmx/install.sh as well? I'm getting virtually the same scenario as before I had run that libopenblas-dev line.. any thoughts?

[lbussy]

You cannot go from a single to a multi-chamber setup. You have to do a clean install, select multi, and name your first chamber. After that you can re-run the install to add chambers.

I have not yet added the libopenblas-dev to the apt list. You should only ever have to install that once as it it an apt package at the OS level and not part of the Python venv,

Had some surgery I am recovering from. When I can stand to be at the keyboard I'll merge the change for that lib.

[lbussy]

Ah, what the hell; you only live once. I committed the change directly to the main branch, so here, in an hour or so, it should work.

I re-opened this for testing. Let me know how it goes.

[Whozat]

Thanks Lee, I hope everything went well with surgery and you get the rest you need on it!

I indeed started with the multi chamber the whole time. I wasn't converting from single chamber to multi.

I went back through the clean install and the change in doDepends.sh didn't seem to help the second chamber. Primary chamber can refresh device list and start the script, but secondary chamber still won't start the script or refresh the hardware list.

[Whozat]

BrewPiRemix_Secondary_install.log

[lbussy]

This is the issue:

2024-05-28 08:26:16 Could not read /home/brewpi/secondary/boards.txt.

Now I am not sure why, exactly, but it is not recognized as an Uno or I have a path issue.

[Whozat]

It was an issue with the arduino being recognized for some reason. It is a brand new board, not sure why that would be the case. I manually loaded one of the brewpi hex images onto it using Arduino IDE and it was able to program it. I then ran the installer all of the way through again and both chambers are reporting that the script is running and I can get devices in the maintenance panel. Thanks for helping guide me to the underlying issue after your update!

[lbussy]

Hmm, strange, but glad you got it. There are some gyrations to recognize the boards, and there may be a variant that's not detected correctly. Gonna leave this open so that when my brain is working again, I might ask you for some data to review.

[Whozat]

So just like most folks, I had a busy streak and hadn't come back to this. I actually still haven't been able to get this to work consistently enough to trust a brew with it. The script will run and then eventually fail and sit in a "not running" status. I am also unable to see my temp probes.. I was able to get all 4 of them set up at one point, but subsequent connections doesn't see the full MAC address. At this point, I was planning on trying to reinstall again but wasn't sure if you were able to come back to this and fix all of the broken python security holes.

[lbussy]

I heard a rumor the lazy bastard maintaining this got himself a new Pi 5 for testing. :)

[lbussy]

Are you using the same Arduino every time? It's entirely possible that the EEPROM on your Arduino is bad.

Try an "erase" and see if they will set up again.

[Whozat]

I am indeed using the primary arduino every time for that chamber. They are both brand new boards and I remember having issues pushing the script over to the second board when I initially was setting them all up. I can do another setup for a single chamber only and see where it lands me. If it works, I’ll try to add an additional chamber with the second script. I’ll give it a shot this week (maybe next week with the holiday this week), and I’ll let you know how it goes! Thanks!

…

On Sun, Nov 24, 2024 at 8:22 PM Lee Bussy ***@***.***> wrote: Are you using the same Arduino every time? It's entirely possible that the EEPROM on your Arduino is bad. Try an "erase" and see if they will set up again. — Reply to this email directly, view it on GitHub <#212 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIGWVQZQ3L7XCV7PL555J5D2CJ3TTAVCNFSM6AAAAABROGDGFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJWGQ4DSOJQHE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[lbussy]

Losing the probes sounds like a problem with probes or EEPROM, but if the script stops working, the answer may be in the logs.