BrewPi Remix – What’s Old is New Again

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Excuse me, I got lost with the translations. I don't know if I should wait for a performance or just with the change of assignment to a "chamber device" I should find a change.
Besides not working, I am concerned to see that the system does not detect devices often.
 
I don't know if I should wait for a performance or just with the change of assignment to a "chamber device" I should find a change.
You should upgrade again as you did previously, and you will be able to see your available devices. The change to chamber device is just a general thing you will want to use after you are upgraded.

Besides not working, I am concerned to see that the system does not detect devices often.
The system does not really detect available devices. They are a function of the board type detected. A given board will have a set number and type of devices, subject to assignment.

After you upgrade the devices will detect, and assign correctly.
 
Hello,
"No installed devices found" :-( I feel like I'm doing something wrong. Can I do a check for you?
conf2.jpg
 
Hello,
"No installed devices found" :-( I feel like I'm doing something wrong. Can I do a check for you?View attachment 723686
1616871167325.png

See how on mine the devices are assigned to what function they perform? You need to make those assignments. If your not sure what is what, put one temp probe in ice, select the read values box. Then when you see the one that reads around 0 deg C assign it, then label that wire with a piece of tape.

your relays would look like this
1616871930269.png

On mine Device 3 is assigned to a relay for cooling.
Device 4 is a switch monitoring the door
device 5 unassigned.



I noticed only one temp probe is registering tho. how many have you installed?
 
Last edited:
Hello,
first of all, thank you all for the follow-up.
I agree that at least the probes (I have added a second probe to check that the system also registers it) the system finds them and it seems to be all right. If you look at the terminal data, I have configured the three devices as you indicate me, and I have applied the configuration of the three, but, the result is "no installed devices found", after refreshing the list of devices, the devices return to show unconfigured.
My conclusion is that, although it detects them, it does not install them.
By the way, the system recognizes the probes by offering an address on Wire. Should it show something similar when detecting the SSR?
Thanks again
conf3.jpg
 
Well, that's very strange, because that problem was a bug, but is now fixed. Let's check the proper version. Please enter the following command in the root of your BrewPi installation/chamber:

Bash:
git log -n 1 --simplify-by-decoration --decorate --pretty=oneline

You should see something like this:

pi@brewpi:/home/brewpi $ git log -n 1 --simplify-by-decoration --decorate --pretty=oneline
504c445ea64c745a5a1524f3927b6a172ee53836 (HEAD -> master, tag: 0.7.3, origin/master, origin/HEAD) 0.7.3 Bugfix (#170)


If the commit and tag are not the same, it's not picking up the proper code.
 
eeprom not being cleared will cause that "forgetful" behavior.

Back to the "Detected Devices" thing, there is no way to "detect" a relay control input, nor an SSR control input, so neither BrewPi nor any of its spawn actually do anything more than look for ds18b20 devices on the One-Wire "bus". All other "devices" were static constructs that simply required association with a GPIO and function-specific settings to suddenly work...

Cheers!
 
Hello,
I've done half the work. LBussy, I have tested the code and the result is correct. I receive the same message that you indicate.
Now I have to abandon the keyboard, I have a visit at home, when I get them to leave ;-) I will try other equipment that I have for the other cameras, one already programmed and others still clean. I will report the results.
Day_ trippr I understand this is what you mean by your eeprom suggestion, right?
Thanks
 
Day_ trippr I understand this is what you mean by your eeprom suggestion, right?
There is a portion of the memory that is nonvolatile, called EEPROM. Sometimes it can become corrupt and result in not being able to save the configuration. Try to flash the controller again with BrewFlasher, selecting the "Erase Flash" option:

1616933287986.png
 
Good morning,
Sorry for the delay, I've been trying everything that crossed my mind.
I have tested 4 Mini D1 devices (ESP8266EX chip, according to brewflaser, in case it was an interesting information). All with the same result. (Well I have to say that one of them seems to be dead, after flashing)
I have tested with Firmware wifi rev 0.11 and 0.10, to see if other Firmware reacts differently, but not.
Despite its price and its origin, I am not sure if the problem is the mini D1, all fail? although it is also true that I already believe anything ... and I begin to not trust them.
Any ideas to get me out of my despair? 😤
P.S. my purchase was: https: //es.aliexpress.com/item/1005001621784437.html? spm = a2g0s.9042311.0.0.431f63c0D1IsKD
Model: D1mini V: 3.0.0
 
Last edited:
Sorry for the delay, I've been trying everything that crossed my mind.
Remind me: Do you have an LCD? If so, flash and run this sketch:
1617103300250.png

It will check the sensors, relays, and LCD of course. That will tell us if you are wired up correctly, and it will clear the flash. Then you can load the BrewPi firmware again when that passes.

P.S. my purchase was: https: //es.aliexpress.com/item/1005001621784437.html? spm = a2g0s.9042311.0.0.431f63c0D1IsKD
Model: D1mini V: 3.0.0
That's not a Lolin, but I think I have several of those and they work fine. I generally try to buy from the Lolin store.

All with the same result. (Well I have to say that one of them seems to be dead, after flashing)
Would you post the output from the device window please? Or maybe a screenshot of how you have it set?
 
Last edited:
Hello,
Remind me: Do you have an LCD? If so, flash and run this sketch:
If I have bought LCD, although I have not connected them yet. Can you tell me where the SDA and SDL pins are connected? In this way I already send you my tests also with the LCD.
That's not a Lolin, but I think I have several of those and they work fine. I generally try to buy from the Lolin store.
I take note of the store, thank you.
Would you post the output from the device window please? Or maybe a screenshot of how you have it set?
After your answer about the lcd connection I send you screenshots of all my processes.
Thanks
 
Well, I begin to understand that it is possible that I am missing that board.
I only have, rasperry pi, mini d1 and lcd + IIC I2C LCD1602 serial interface board module. That is why I did not understand message # 132.
LCD_back.jpg
D1mini.jpg

flashing project "other"
Step1_Project Other.jpg

After this, I try to access the settings but I can't. It does not access automatically. Neither through the gateway 192.168.4.1
Project Brewpi Flash.jpg

when I flash again with the project: Brewpi ESP8266, then if I can access it automatically and through a gateway. These are the details of the connection:
Project Brewpi ESP8266_1.jpg
Project Brewpi ESP8266_2.jpg
Project Brewpi ESP8266_3.jpg
At this point I can configure the ip in config.cfg and continue. I leave the images of that for the following messages if we are doing well so far.
 

Attachments

  • Project Brewpi ESP8266_1.jpg
    Project Brewpi ESP8266_1.jpg
    57.6 KB · Views: 3
Well, I begin to understand that it is possible that I am missing that board.
Oh! That makes more sense now. You will not be able to use the LCD without a level-shifter, since the level shifter is on the board shown. This one from SparkFun would work, I'm sure there are others.

flashing project "other"
After this, I try to access the settings but I can't. It does not access automatically. Neither through the gateway 192.168.4.1
Right - what that test sketch does is find and display on the LCD, then checks for attached sensors and shows the temperature, finally it cycles the relays. It's for testing your controller and wiring only. It will not do any WiFi.

Please show your log results as well as the device configuration screen now.
 
Ok, we are getting closer. Google translate is not perfect and I am alternating it with my insufficient English. Sorry if this becomes insufferable.
Oh! That makes more sense now. You will not be able to use the LCD without a level-shifter, since the level shifter is on the board shown. This one from SparkFun would work, I'm sure there are others.
Does this mean that we need any of these plates to follow or just to read the checks? I could buy one through amazon, faster than aliexpress, the price difference is not important.
Please show your log results as well as the device configuration screen now.
Here I do not understand. Do you need the lcd results after adding the board we talked about before, or is this data also reported in another way? Brewflasher does not return more than the console that I sent you in the previous message.
 
Does this mean that we need any of these plates to follow or just to read the checks?
You would need that to use an LCD. Without the LCD there is no reason to use the Test sketch.

Here I do not understand.
Connect your device after flashing BrewPi and try to configure your devices. I would like to see the contents of the entire screen after you configure a point, including the log text which appears at the top.
 
Ok, for now I forget the lcd, we will come back later.
I think what you ask me is the following.
I have set up only two probes so you can see it all.
1-pre configuration screen
2- pre Apply configuration screen
3- screen post App configuration.
Preconfiguration.jpg
Pre-Apply.jpg


Post-Apply.jpg
 
I think a thread had come loose. I have left only the 3v8e probe. same result
1sense.jpg
 
I just noticed (maybe you told me this earlier) that you were using a multi-chamber install. I can't imagine that would do it, but give me a few to replicate that on my bench.
 
No problem, work slowly. I take the opportunity to do other pending issues.
Thanks again
 
I am unable to reproduce this. I mean on occasion it fails (I assume because this is over Telnet) but it's rare. Just on the off chance we are talking past each other, here's me setting up a device:



Have you tried it as a serial device? It's a separate firmware, and you will need to change the port back (auto works), but it will let you know if your hardware is capable of saving the devices.
 
0.7.4 Bug Fix Release

This release merges in several fixes to bugs discovered by @day_trippr during an overhaul of his Pi garden.

The most notable work here was to further abstract the real /dev ports from the udev mapped ports and allow translation via the serial number. This was required because the PySerial people apparently hate symlinks and have refused by inaction, since 2016, to fix that state of affairs. I'm sure "I'm doing it wrong" but at least I know I'm not the only one.
I've added a new tool, utils/doFlash.sh to further abstract the venv environment required by BrewPi Remix now. I've also added a complete description in the readme of all of the command line tools which I shall include here for reference:

FilenameDescription
doBrewPi.shThis is the script called by the BrewPi Remix daemon which does all of the work of keeping BrewPi Remix running. You should not need to execute this script in normal operation. The daemon runs as brewpi, or the name of the chamber when used in multi-chamber mode.
doCleanup.shThis is a script which is called by the upgrade process, intended to help clean up remnants of the previous version before restarting.
doDaemon.shThis script checks and/or creates the system daemons used by BrewPi Remix: the BrewPi Remix Daemon (named for the chamber in multi-chamber mode) and the WiFIChecker.
doDepends.shThis script checks and enforces the apt and pip dependencies for BrewPi Remix.
doFlash.shThis script will set up and execute the updateFirmware.py code to flash firmware from the command line.
doIndex.shThis script is called by the install process to generate the root web index files as symlinks.
doMenu.shThis script is not yet used.
doPerms.shThis script may be the most used for BrewPi Remix users. It will check all file and system permissions. After any manual manipulation of files, this script should be called in order to ensure BrewPi Remix can operate. It is often the first troubleshooting step when a user asks for help.
doUpdate.shThis is the update script used to bring BrewPi Remix up to the current version.
doWiFi.shThis script is the compliment to the doBrewPi.sh script. Historically, the Raspberry Pi has had challenges remaining connected to WiFi. This script is run by a daemon process called wificheck and will periodically ping the gateway. When it is unable to reach the gateway it will restart the network stack as first aid.

All of these tools will create the proper conditions in which they need to work, to include using sudo and venv to enforce the environment. That's no problem if you have no idea what I am talking about. For those who do, you are bright enough to figure out your own way around that if it creates friction for you.

Upgrading

Existing users of BrewPi Remix 0.5.3 and above may upgrade with:
sudo /home/brewpi/utils/doUpdate.sh

If you are not on version 0.5.3 or above (or if you have no idea what version you are on,) use the following command to upgrade to the latest version:
curl -L upgrade.brewpiremix.com | sudo bash

This must be run from within your /home/brewpi directory, or from each chamber directory in multi-chamber mode.

Details

As this is a project in several parts, below are the changes in the individual repositories

Note: Some of these files were changed in the last release and because of my horrible git skills, were re-included here. I believe I've learned the error of my ways. The commit summary is only this release however.

Tools

Commit Summary
File Changes
  • M bootstrap.sh (5)
  • M install.sh (124)
  • M uninstall.sh (45)
Patch Links
Scripts

Commit Summary
  • d83f05b Fix error when setting devices
  • aff8fdd Use proper Python env
  • 74c6b0c New file
  • e1466b1 Bail on error
  • ddf80fb Add additional definition
  • 2131590 Handle null ports
  • 49f017c Add port conversion
  • 77eb8b6 Change examples
  • 60b7611 Use real ports for flash
  • f48c0df Change choice flow
  • 1e1124f Move updateFirmware to gitroot
  • fc3cf31 Describe files in directory
  • 5dd1a68 Move to main directory
  • e804d4f Add downloads/ to ignore
  • a2809cf Translate udev port
  • 0b81f98 Fix aliases
  • 5032800 Formatting for legibility
  • 5991741 Avoid poorly named ports
  • dfde1f4 Move from distutils to packaging
  • 6d090b2 Address formatting
  • 2366def Revert choice to restore settings
  • 440e675 Make sure asroot passes all args
  • 55b0096 Update copyright
  • 8db8cd8 Do not allow restore from newer
  • 011e010 Pass through proper args
  • f57a866 Update copyright
  • 7e4168e Fix aliases for both users
  • c4d4fb9 Hard code brewpi home path
  • 544442f Hard code brewpi home path
File Changes
  • M .gitignore (1)
  • M BrewPiProcess.py (4)
  • A ConvertBrewPiDevice.py (104)
  • M MigrateSettings.py (6)
  • M Tilt.py (30)
  • M autoSerial.py (12)
  • M backgroundserial.py (3)
  • M brewpi.py (246)
  • M brewpiVersion.py (10)
  • R gitHubReleases.py (1)
  • M inc/asroot.inc (6)
  • M inc/help.inc (2)
  • M programController.py (36)
  • M requirements.txt (1)
  • R terminal.py (0)
  • M tests/versionTest.py (9)
  • R updateFirmware.py (20)
  • R updater.py (0)
  • M utils/README.md (18)
  • M utils/doDepends.sh (11)
  • A utils/doFlash.sh (164)
  • M utils/doUpdate.sh (2)
Patch Links:
Web UI

Commit Summary
  • Truncate commit info
File Changes
  • A css/multi-index.css (17)
  • M css/style.css (19)
  • A get-bjprompt.php (49)
  • A get-gitinfo.php (47)
  • A get-logo.php (158)
  • A get-tiltinfo.php (53)
  • M index.php (56)
  • M js/beer-chart.js (39)
  • M js/main.js (8)
  • M lcd.php (113)
  • M multi-index.php (204)
  • M top-bar.php (136)
Patch Links:
 
Hi,
As for the video, it is a very good idea. My procedure is the same as yours, although it does not work.
Have you tried it as a serial device? It's a separate firmware, and you will need to change the port back (auto works), but it will let you know if your hardware is capable of saving the devices.
You mean to flash the devices with firmware rev 0.11 - Serial? I have not tried it. That being the case, I suppose I should connect the device via cable to the raspberrypi, right? What connections should I use then? As I said on some occasion, I trust a cable more than a Wi-Fi connection. It is possible that the final cable connection was a possibility for me, although I would like to see the system work via wifi to decide.
While you can see this, I am going to start by updating to the new version.
Thanks
 
You mean to flash the devices with firmware rev 0.11 - Serial? I have not tried it. That being the case, I suppose I should connect the device via cable to the raspberrypi, right? What connections should I use then?
Yes, you would want to remove external power from the controller, at least for now.

If you connect as a serial, and it is the only one (for now let us keep it simple) then you use "port = auto" in the config.cfg.
 
ok this is what i have done:
- update 0.7.4
- configuration line in config.cfg: port = auto (the old one removed by #)
-flashing firmware 0.11 - Serial (sorry, I didn't think to try the old version)
- connection between mini d1- Raspberrypi: micro usb-USB
- connections on mini D1 pin D-5 ---> -5VSSR; D6 yellow probe cable (2)
- Food + 5v from SSR and + -5v probes (2) with an external power supply.
The result in this case is that the maintenance panel does not automatically find the probe. Via wifi if it did.
Either I am missing something to connect or raspberrypi and miniD1 do not speak.
NosenseSerial.jpg
 
That's ok for now - see if you can assign the actuators (heat and cool) and if they will then show up in assigned devices.

Remember to "Refresh Device List" after you assign them.
 
I only have one SSR connected, but it doesn't install.
NosenseSerial2.jpg

I have remembered that in the old brewpi I used the command "dmesg" to recognize the serial port (towards this by recommendation, my knowledge does not understand this). I do not know if it helps you, but I have captured the end of that command after restarting the mini D1.
dmesg image.jpg
 

Attachments

  • NosenseSerial2.jpg
    NosenseSerial2.jpg
    138 KB · Views: 4
I have remembered that in the old brewpi I used the command "dmesg" to recognize the serial port (towards this by recommendation, my knowledge does not understand this). I do not know if it helps you, but I have captured the end of that command after restarting the mini D1.
This tells us that the script has connected to the controller, so there's no need to worry about dmesg logging:
1617294323484.png

I am honestly scratching my head on this one. I cannot make it happen here, I have what should be the same setup. I did manage to break my mule again (I blame @day_trippr so it will be a couple of hours before I can test that specific workflow and see if the messages are the same.
 
Ok, I hope, no problem. The only thing I can think of to try to make the job easier is a mini d1 change. I received some I have several purchased at the same time. As I received some damaged I bought some more to replace the damaged one and for future projects. They are still in the unopened package. I'm going to try to install one of the new ones in case my whole first game had problems.
 
just updated due to your last post. Now the script wont start.

doPerms.sh returns command not found.

Refreshing device list returns. Error while receiving device configuration: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
 
Last edited:
Back
Top