bLazem
Active Member
- Joined
- Jan 19, 2015
- Messages
- 26
- Reaction score
- 8
Native ESP8266 BrewPi Firmware - WiFi BrewPi, no Arduino needed!
- Thread starter Thorrak
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
Sure thing. First - a warning to all who may come along and see this - Do not print this! It is a work in progress, and is based on an earlier enclosure design. I can't guarantee anything will actually fit inside -- or even that the lid will fit on the enclosure.
That said, the files are located on Thingiverse. The idea is that the LCD mounts in the lid to the enclosure, with the other stuff inside. This is a pic of last weekend's failed print with the boards overlaid on top:
A 5V power supply is on the left, the relay in the center, and my SMD PCB on the right. The idea is that you use snap in power jacks (I haven't shopped those - you can get them way cheaper than that link) in the front of the box, and IEC-320 (again - haven't shopped) for AC in. You can see what I'm talking about in the rendering on Thingiverse.
As an alternative, you could replace the panel mount power jacks with a standard outlet - I haven't thought too much about this, but it might be easier.
There are snap-in RJ-11 jacks as well which might save some space ... or are you intending to have a hole there?
ETA: Is your card upside-down? Or is that a different one?
ETA: Is your card upside-down? Or is that a different one?
There's a hole in the back that allows you to connect the MicroUSB (if you want to power that way instead of internally) and the RJ-11 jack that is snapped down onto the PCB.
This is the WeMos D1 Mini Pro, which is their new board. I don't remember what is different about it if anything, I just figured I'd get one to test if it worked with the firmware.
It does.
Oh now I see it. I missed the Thingiverse link the first time. Looks like there will be plenty of room in there for wire nuts and whatnot.
I added the new pinout, but I'll need to come back and update the schematic. Do you happen to remember what the command line differences are?
Got it -- Updated.
No sooner do I update the documentation, and it's time to update it once more.
v0.5 is now released and on GitHub!
Changes:
- New option when setting up WiFi to change the mDNS name to something custom
- The EEPROM data will automatically be cleared when WiFi is configured
When using the WiFi firmware, this means you should no longer need to hit the "Factory Reset" button before setting up devices.
Some notes on the mDNS name change functionality:
The script verifies that the mDNS name chosen is entirely alphanumeric before saving it. THAT SAID - There is no functionality available to provide feedback to the user if the chosen mDNS name is invalid. To prevent issues, when presented with an invalid mDNS name the script will just refuse to set up the WiFi and will restart itself after 2 seconds. If it looks like your device is refusing to connect to WiFi, try choosing a different mDNS name.
I'm working on some documentation for the Arduino BrewPi on Windows (PITA!). When I get done I'll get back and try this.
mschrock
Active Member
I gave this a go on a brand new setup following the instructions:
https://github.com/thorrak/brewpi-esp8266/blob/master/docs/INSTALL.md
Using the V0.5 esp8266 firmware.
I still couldn't get the Device list to save until I reset controller to factory defaults.
Even then I think something is still wonky as it is not maintaining temps. I think I need to adjust the PID, but I am not having success overriding and of the PiD settings on the "Advance Settings" page.
The result in the log when I try to change "Beer-to-Fridge proportional gain (Kp)" (tried -10 and 10, wasn't sure how it is should be formatted, but same result)
And here is the result on the log when I reset controller:
What am I doing wrong?
https://github.com/thorrak/brewpi-esp8266/blob/master/docs/INSTALL.md
Using the V0.5 esp8266 firmware.
I still couldn't get the Device list to save until I reset controller to factory defaults.
Even then I think something is still wonky as it is not maintaining temps. I think I need to adjust the PID, but I am not having success overriding and of the PiD settings on the "Advance Settings" page.
The result in the log when I try to change "Beer-to-Fridge proportional gain (Kp)" (tried -10 and 10, wasn't sure how it is should be formatted, but same result)
Code:
Oct 17 2016 17:48:11 Controller debug message: INFO MESSAGE 12: Received new setting: beer2fridge_kp = -10
Oct 17 2016 17:48:11 Controller debug message: WARNING 0: Could not process setting
Oct 17 2016 17:49:00 Controller debug message: INFO MESSAGE 12: Received new setting: beer2fridge_kp = 10
Oct 17 2016 17:49:00 Controller debug message: WARNING 0: Could not process settingAnd here is the result on the log when I reset controller:
Code:
Oct 17 2016 17:30:39 Resetting controller to factory defaults
Oct 17 2016 17:30:41 Controller debug message: INFO MESSAGE 15: EEPROM initialized
Oct 17 2016 17:30:41 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:41 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:41 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:41 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:41 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:41 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:42 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:42 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:42 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:42 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:42 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:42 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:42 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:43 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:43 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:43 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:43 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:43 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:43 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:43 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:43 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:44 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:44 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:44 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:44 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:44 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:44 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:44 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:44 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:45 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']
Oct 17 2016 17:30:45 Controller debug message: ERROR 4: Invalid chamber id 255
Oct 17 2016 17:30:45 Controller debug message: WARNING 0: Could not process setting | Number of arguments mismatch!, expected 0arguments, received [28, 'writeDeviceDefinition called']What am I doing wrong?
I'm out at the moment - I'll have to take a look at the kp thing later tonight when I get home. With regards to the eeprom reset thing, did you set up wifi using the v0.5 firmware or using a previous version?
Last edited:
mschrock
Active Member
Yes, I used the 0.5 Version.
.Welp, time to look for a plan B then, I guess. Honestly I should just do a wholesale rewrite of the device management code to take advantage of SPIFFS rather than EEPROM. One of the downsides to a direct port I suppose - you miss out on some of the features that make the new platform great.
I doubt too many people are concerned with this, but as part of debugging the Kp issue I went through and compared the legacy brewpi-script code with the brewpi-script develop branch (which we are using for this project). Here are the differences, listed out mostly so I can fin them later:
All said - Nothing really here that would cause incompatibility between the "legacy" brewpi-script and "develop" version. Possibly parts of the firmware flashing routine, but thats it.
Now to trace through the messages...
- Conversion from serial to "background serial" class
- Addition of 'E' function to clear EEPROM
- Removal of debug message expansion (hence the "Finding a log message here should not be possible, report to the devs!" messages)
- Changes to the controller programming functions (Arduino setup, etc.) -- Not reviewing these in detail at this time
- Tweaks to GitHub integration to better handle updates
- Tweaks to process detection to better allow the script to detect potential duplicate processes
- Minor tweaks to the WiFi checker
All said - Nothing really here that would cause incompatibility between the "legacy" brewpi-script and "develop" version. Possibly parts of the firmware flashing routine, but thats it.
Now to trace through the messages...
I spent a bit of time staring at this, and the answer appears to be that it's a version thing. The version of the BrewPi code that I based this on is an older version than the version that renamed that option (added the option?) beer2fridge_kp.
Put simply: I'm not a fan of running on old code -- especially as it relates to the temperature control functions. I've got a lead on how to go about updating this, and will attempt to get it built over the next few days/this coming weekend. The fix is coming, it's just unfortunately going to take a few days. Sorry about that.
Well, unfortunately it looks like the changes came sometime between 0.2.4 of the Legacy branch and 0.4.x of the Develop branch which is to say they're not part of the Arduino codebase. Regardless - I'd love to get the ESP8266 running basically the same firmware as the Spark, so I'm going to press ahead with attempting the conversion until I hit my head against a brick wall, but I have no idea how long it could take.
In the mean time, I'm going to try to tweak the instructions to load the legacy branch of BrewPi-www to enable editing the old version control settings to correct the issue @mschrock identified. That I can get done by the end of this weekend at the latest.
In other news, Prusa accidentally left the main part I needed to fix my 3D printer out of my order with them, so I'm still stuck waiting to print the enclosure for my relay. Fingers crossed I can get it soon!
In the mean time, I'm going to try to tweak the instructions to load the legacy branch of BrewPi-www to enable editing the old version control settings to correct the issue @mschrock identified. That I can get done by the end of this weekend at the latest.
In other news, Prusa accidentally left the main part I needed to fix my 3D printer out of my order with them, so I'm still stuck waiting to print the enclosure for my relay. Fingers crossed I can get it soon!
Oh that sucks! I was going to ask if your printer was running.
One of these days I really would like to get a printer. I just have a hard time justifying it to the spousal unit.
I was able to justify one by printing leg extensions for our coffee table. It was about 3" shorter than we wanted, but now it's the perfect height.
How bought that I don't know, but hey - not complaining!
Sure enough the probe shipped today. I can't speak highly enough of the Prusa support team -- after missing the probe in the initial order they effectively overnighted a new one to NYC from the Czech Republic. UPS has it being delivered tomorrow and I hope to get it installed this coming weekend (if not sooner). Fingers crossed!
Every time I sock a little money away in my slush fund, something happens. This past weekend the front-loading washing machine decided to eat itself from the inside-out. There goes the 3-D printer money again.
Eek, that sucks. The one bright spot if you are interested in eventually picking up a 3D printer is the fact that good printers keep getting cheaper. The first printer I got was a used Makerbot Mini which cost ~700 at the time. I can get a (mostly) assembled Prusa clone from Monoprice now for ~300 which has substantially higher quality & bigger build volume -- and this is just a year and a half of improvements. It's insane how quickly the technology adapts.
Just to provide an update on the firmware -- right now the latest version is v0.5, which is based on the 0.2.4 Arduino (Legacy) firmware. It should work perfectly (it works for me!) and be compatible with the Legacy version of brewpi-www and modified version of brewpi-script.
As noted, I've been working to try to convert the latest version of the BrewPi firmware (0.4.9) to work with the ESP8266/ESP8266EX - the branch as currently exists is here:
https://github.com/thorrak/brewpi-esp8266/tree/update-0.4.x
So far, everything compiles, and the image will flash, but the ESP enters a restart loop when attempting to boot the firmware. I don't know of a good method for debugging this, so I'm taking the old-school "comment everything out using preprocessor directives and see if I can get it to boot" approach.
My concern is that the problem lies with the implementation of Boost which is fairly deeply integrated with the temperature control algorithm. Worst case I have to rewrite that part of the code, but I'm hoping I can narrow down the issue somewhere else. Alternatively, it may end up being that there simply isn't enough instruction ram on the ESP8266 to support the 0.4.x line -- but that's a reality I'm not yet ready to accept.
As noted, I've been working to try to convert the latest version of the BrewPi firmware (0.4.9) to work with the ESP8266/ESP8266EX - the branch as currently exists is here:
https://github.com/thorrak/brewpi-esp8266/tree/update-0.4.x
So far, everything compiles, and the image will flash, but the ESP enters a restart loop when attempting to boot the firmware. I don't know of a good method for debugging this, so I'm taking the old-school "comment everything out using preprocessor directives and see if I can get it to boot" approach.
My concern is that the problem lies with the implementation of Boost which is fairly deeply integrated with the temperature control algorithm. Worst case I have to rewrite that part of the code, but I'm hoping I can narrow down the issue somewhere else. Alternatively, it may end up being that there simply isn't enough instruction ram on the ESP8266 to support the 0.4.x line -- but that's a reality I'm not yet ready to accept.
What's the benefit if using the more current line?
It appears to be a substantially different PWM/PID algorithm, with a different setup for control variables/constants.
Does that make it better? I have no idea.
Had my wemos mini running for 5 weeks now. Seems very stable. Got my screen and set it up today. Now to put it on a board and clean it up. Thanks for your time on this thorrak[emoji106][emoji106][emoji481][emoji481]
View attachment ImageUploadedByHome Brew1477558164.573157.jpgView attachment ImageUploadedByHome Brew1477558196.403729.jpg
View attachment ImageUploadedByHome Brew1477558164.573157.jpgView attachment ImageUploadedByHome Brew1477558196.403729.jpg
I wanted to see if I could help, but I failed to compile the code due to the "boost library". Roughly checked the source, I found that BrewPi use the library for fixed point. I am guessing that it might have something to do with endian.
Ooooh boy, boost. So there is a version of boost that supposedly works with Arduino -- and it runs about 150MB. When you attempt to compile for ESP8266 it fills up the iram. Fun times. Anyways, I made a pared down version here using the boost tools:
https://github.com/thorrak/brewpi-esp8266/tree/update-0.4.x/brewpi-esp-platformio/lib/brewpi_boost
This doesn't contain the assert libraries. Best I can tell all they are used for is enforcing type safety at compile time, so I just went ahead and disabled everything associated with them:
https://github.com/thorrak/brewpi-esp8266/blob/update-0.4.x/brewpi-esp-platformio/src/fixed_point.h
On a side note, I updated Visual Micro & Visual Studio, and now nothing will compile. When faced with having to choose between debugging VS/VM and just saying "to hell with it" and switching IDEs, I chose the latter. I'm now using CLion & Platformio with ESP8266 support. Honestly, I should have done this on day 1. Whereas I would only recommend VS/VM to masochists, CLion + Platformio is almost pleasant to use.
Bigdaddyale
Well-Known Member
I assume at some point Leonard and Sheldon will break it down so Penny understands what's going on.
Unfortunately, I have never been one to pass up an opportunity for an unnecessarily long winded post!
So right now, the ESP8266, Arduino, and @ame 's Python versions of the BrewPi firmware all are based on the older ("legacy" or v0.2) of the BrewPi code. Only the official shields and DIY devices based on Spark Photon hardware support the new ("develop" or v0.4) code. The majority of the firmware was rewritten between the versions with the most substantial change being to the temperature control algorithm.
One reason that change is so substantial has to do with how computers handle numbers with a decimal point. Most of the time programmers want their code to handle numbers of varying precision before and after the decimal point (I.e. 3.04 and 82.1858) so they use a variable with a "floating" point (get it? The decimal point floats around? Har har!). This is great for programmers, but computers -hate- it. As in, often-require-specialized-hardware-to-handle-it hate it. Microprocessors like the ESP8266 don't have this specialized hardware, and so they have to approximate -- at the cost of both speed (10x-100x slower than math with whole numbers) and precision.
One of the changes between v0.2.x and v0.4.x is that Elco & Team switched from "floating" point numbers to "fixed" point numbers. By knowing exactly where in the number the decimal place goes, they can replace the slow "floating point" math with fast and precise integer math. To do this they leveraged a bunch of code that other people created - what @pocketmon and I were referring to as "boost" above.
Right now, my hamfisted attempt to convert v0.4.x of the official firmware to run on the ESP8266 is refusing to boot. @pocketmon thinks it may be due to a specific nuance in the way things are stored/interpreted by microprocessors which might be exacerbated by the conversion to fixed point math. I hadn't even considered this, so I hope he's right.
In the mean time, I'm doing the programmer equivalent of ripping out all the drywall in a house to find a leak. I'm disabling massive chunks of functionality until I can get the code to run, and then I'll reenable until I find the bug.
We're still a ways off from having the new firmware implemented (or determining that it is/isn't possible!) but we're making progress!
So its been awhile since I attempted to get brewpi running with my ESP8266. Thought I would check back in here and try it again. Still can't get the devices to install. Have 2 temp sensors and 3 digital pins that are detected but can't install them. Same problem I had a few months back.
You need to reset the firmware to "Factory Settings". It's a button at the bottom of the "advanced settings" tab in the BrewPi website.
I thought I had that bug fixed, but apparently my fix didn't work. After you reset to factory settings once, however, the device should work going forward.
I wonder if I can get some help out there .
I have set up a NAS server running Brewpi and it seems to be working fine but I'm having problems with my ESP8266 setup. I'm using one of the recommended NodeMCU boards (E-12) and have tested it using WIFI example code. I'm running without an LCD display. After I flash the 0.5 version of the code using esptools.py in Windows I can configure WIFI -then it just goes away. I have tried different boards with the same result. Am I missing something?
.I have set up a NAS server running Brewpi and it seems to be working fine but I'm having problems with my ESP8266 setup. I'm using one of the recommended NodeMCU boards (E-12) and have tested it using WIFI example code. I'm running without an LCD display. After I flash the 0.5 version of the code using esptools.py in Windows I can configure WIFI -then it just goes away. I have tried different boards with the same result. Am I missing something?
I wonder if I can get some help out there
I have set up a NAS server running Brewpi and it seems to be working fine but I'm having problems with my ESP8266 setup. I'm using one of the recommended NodeMCU boards (E-12) and have tested it using WIFI example code. I'm running without an LCD display. After I flash the 0.5 version of the code using esptools.py in Windows I can configure WIFI -then it just goes away. I have tried different boards with the same result. Am I missing something?
Hey there!
What I would expect to happen under v0.5 is this:
1. You flash the board
2. It shows up as a WiFi network. You connect to it.
3. You open a web browser & see the login page - You provide your WiFi credentials
4. Underneath where you provide the credentials is a third form box - It will be prepopulated with something like "ESP1234568". This box is where you set the mDNS name
5. You click save & the WiFi network disappears
6. The ESP8266 device connects to your WiFi network & registers with the mDNS name you noted in step 4.
It sounds like this is what you are seeing happen. If so (and I'm not misinterpreting something) then awesome - so far so good.
The next step is going to be to actually get your brewpi-www installation to connect to the mDNS name. If you used my installation instructions for setting up BrewPi on your NAS device (awesome idea, BTW instead of a RasPi) then you should be able to pick up from step 5 of the installation instructions. If you used a different install of brewpi-script then you will not be able to connect.
Now -- All this aside, assuming you know the mDNS name you can actually test your install using a telnet client. Just telnet to the mDNS name (with .local appended - so using the above example you would "telnet ESP1234568.local") from a computer with mDNS support. If it connects, then awesome - you've confirmed that it's working. If it doesn't connect, there may be an issue with the board, mDNS name, or your computer may not have mDNS support.
If I remember (maybe I should start using the GitHub issue tracker??) I can create a python script that will run this test for you and confirm that your flashed board is working properly. I'd like to pull together an mDNS browser anyways for a different project - no reason not to use this as a test case.
Thanks for the quick response!
OK. After I powered the ESP back up it appeared in my router list. I tried to putty in using the host name and said it was not found. I tried using the IP address and it worked fine. Can I configure brewpi to use the IP address rather than the host name?
OK. After I powered the ESP back up it appeared in my router list. I tried to putty in using the host name and said it was not found. I tried using the IP address and it worked fine. Can I configure brewpi to use the IP address rather than the host name?
Yep!
It sounds like your computer may not support mDNS -- which makes sense if you're running windows. Your NAS might, but everything will support the IP address.
fwiw, if you're running Windows you should be able to exploit NetBIOS over TCP/IP (NetBT) by entering an ip address and name pair in C:\Windows\System32\drivers\etc\lmhosts.
All of our devices here are named in that fashion, including deskside systems, laptops, phones, tablets, RPis, Arduinos, esp8266s, networked AV components, routers and WAPs, and probably somethings I'm forgetting.
Much easier poking at a named device than trying to remember 30-something IP addresses...
Cheers!
If you install Bonjour either by installing iTunes, or using this stand-alone installer (it says ist is a print server, it comtains a print browser which includes mDNS/Bonjour), your installation will be accessible by using {name}.local via the web browser or PuTTY.
My first thought was pointer: 2 bytes for AVR and 4 bytes for ESP8266. When I skimmed code, I thought endian might be a problem. Later on, I am thinking about data alignment, but I don't know what would happen for xtensa to access misaligned data.
Endian could be an issue, but unless there are some kind of ASSERTs that check errors and reset the processor, it should not cause reset.
just my .002, don't think it seriously.
Clicking on the "Reset the Controller to Factory Defaults" doesn't seem to do anything.
Similar threads
