You do that, then you reset via the button or a power cycle, then you should be able to re-scan for devices.
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:
That's really odd. Are you using the custom brewpi-script from my repo, or the official one?
I'll test this later this afternoon to see if it works on my end with the IP address. Sorry about that.
Which instructions are you following? It's looking like you are using a combination of "stock" BrewPi instructions along with the instructions for the ESP-8266. The ones here are up to date:
https://github.com/thorrak/brewpi-esp8266/blob/master/docs/INSTALL.md
Any semi-current version of Wheezy or Jessie will be able to use mDNS so you should be able to use the host name of the device:
Code:
wwwPath = /var/www/html
wifiHost = ESP[I]XXXXXXX[/I].local
wifiPort = 23You will want to make sure you have the wwwPath there too.
I used the custom brewpi-script in the Thorrak repo and followed the install.md instructions. I'm using a current version of Debian Jessie. I may have copied the name wrong but I am hesitant to reinstall the code since it took about 10 tries to get it to work. I can easily bind the ip address so if I can get that to work I'm good to go. The instructions and scripts worked great by the way!
Using the following format (no tic marks) should work:
Code:
wifiHost = 192.168.0.100I'm 75% sure I tried the IP address previously. Not home right now so I can't try it at the moment. I'll try to get to it this afternoon if nobody else can.
sandyeggoxj
Well-Known Member
Does anyone have a suggestion for an IDE for mac osx 10.7.5? Preferably something free. I'm still using a MBP from Feb of 2007 to get around online.
It's working for me when I test it. Here is what I see:
First, the config file:
brewpi@brewmaster:~/brewpi-script/settings$ cat config.cfg
Code:
wwwPath = /var/www/html
profileName = Test%20Profile%20-%202%20min%20start
beerName = ESP8266%20Test
dataLogging = active
wifiHost = 192.168.5.200
wifiPort = 23And the log from when I run brewpi-script manually:
brewpi@brewmaster:~/brewpi-script$ python -u brewpi.py
Code:
Oct 30 2016 16:39:56 Opening serial port
Oct 30 2016 16:40:06 No serial attached BrewPi found. Trying TCP serial (WiFi)
Oct 30 2016 16:40:06 Connecting to BrewPi 192.168.5.200 on port 23
Oct 30 2016 16:40:06 Notification: Script started for beer 'ESP8266 Test'HEH. So funny story - I actually much prefer developing from my MBP than from my Windows desktop. Originally I thought the only supported IDE was Visual Studio + Visual Micro or Atmel Studio, but as part of the 0.4.x conversion efforts found out that apparently Platformio (and all related, supported IDEs) works great. My current environment is Platformio + CLion (I love Jetbrains) but you could potentially also use Platformio's IDE.
Eventually I'll write documentation on how to start developing with Platformio + CLion, but for now if you want to tinker I can push the Platformio version to a new branch here shortly.
What features are you thinking of developing?
EDIT - Here is the link to the "platformio" branch. This will eventually replace the main branch, and the Visual Studio solution/files will be removed.
sandyeggoxj
Well-Known Member
Well I wasn't thinking about developing too much at this point. Not there technically. I haven't done any development since php4 was fresh on the scene. A little rusty...
I just need an interface to flash to this pile of d1 minis that I have sitting here soldered up to the boards for pcb.io.
EDIT: I just read the github fork and it looks like I'll be able to flash from the rpi.
I just need an interface to flash to this pile of d1 minis that I have sitting here soldered up to the boards for pcb.io.
EDIT: I just read the github fork and it looks like I'll be able to flash from the rpi.
Well I wasn't thinking about developing too much at this point. Not there technically. I haven't done any development since php4 was fresh on the scene. A little rusty...
I just need an interface to flash to this pile of d1 minis that I have sitting here soldered up to the boards for pcb.io.
Oh! Well that's a different story, then. You should be able to flash with the same software/instructions that work for flashing on the Raspberry Pi itself. If that doesn't work let me know and I'll finally draft those instructions.
I approve of this message.
I never did get the Visual Studio branch to compile. I'll give this a go and see if I have any better luck. VS felt like using a sledgehammer to turn in a screw.
My issue now is that I can't seem to get my device to flash on the Zero. This is not new, I had the same issues getting the Arduino to flash once before but damned if I remember what I did to fix it. I should really remember such things (or write them down.)
Code:
pi@raspberrypi:~ $ sudo esptool.py --port /dev/ttyUSB0 write_flash -fm=dio -fs=32m 0x00000 /home/brewpi/esp8266/bin/wifi-reset.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
A fatal error occurred: Invalid head of packet ('F')
pi@raspberrypi:~ $ sudo esptool.py --port /dev/ttyUSB0 write_flash -fm=dio -fs=32m 0x00000 /home/brewpi/esp8266/bin/brewpi-esp8266.v0.5.wifi.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
A fatal error occurred: Failed to write to target RAMI suspect it's something to do with the hub. I gave my "spare" Pi to a friend, I guess it's time to buy a new one.
Some updates from my end -- I managed to finally track down the bug that was causing the v0.4.x branch to not compile. After ripping out the temperature control code (nobody needs that, right?) it appears that the issue is either somewhere in that section of code or in the way I added EEPROM support.
As I mentioned in an earlier post, after giving up on Visual Micro I decided to switch to CLion/Platformio, and created a new branch for the conversion while I work on it. Honestly, I should have made this move weeks ago. After getting the libraries copied over the project compiled almost immediately. Added bonus - it compiles in ~15 seconds, as compared to the 2min+ that I was getting with Visual Micro.
One nice thing about porting over the "legacy" codebase is that it makes working on it much easier. Given that rewriting the EEPROM code to instead use SPIFFS was on my to-do list anyways, I figured I'd start working on that & port it to the v0.4.x line once done. Best case - Kill two birds with one stone: Fix the "zap settings" bug on the legacy firmware, and fix the EEPROM code on the v0.4.x line. Worst case, give up and realize I actually have to make EEPROM work after all.
And so that's what today's project has been. The initial code is out there, but for some reason I'm not getting back the data on read that I put there on write. I was thinking that I may have some kind of issue with either endianness or struct packing but it's hard to tell. If anyone has any thoughts on the proper method for writing or reading structs to files without serialization, the offending code is here:
https://github.com/thorrak/brewpi-e...o/legacy-platformio/src/ESPEepromAccess.h#L44
As I mentioned in an earlier post, after giving up on Visual Micro I decided to switch to CLion/Platformio, and created a new branch for the conversion while I work on it. Honestly, I should have made this move weeks ago. After getting the libraries copied over the project compiled almost immediately. Added bonus - it compiles in ~15 seconds, as compared to the 2min+ that I was getting with Visual Micro.
One nice thing about porting over the "legacy" codebase is that it makes working on it much easier. Given that rewriting the EEPROM code to instead use SPIFFS was on my to-do list anyways, I figured I'd start working on that & port it to the v0.4.x line once done. Best case - Kill two birds with one stone: Fix the "zap settings" bug on the legacy firmware, and fix the EEPROM code on the v0.4.x line. Worst case, give up and realize I actually have to make EEPROM work after all.
And so that's what today's project has been. The initial code is out there, but for some reason I'm not getting back the data on read that I put there on write. I was thinking that I may have some kind of issue with either endianness or struct packing but it's hard to tell. If anyone has any thoughts on the proper method for writing or reading structs to files without serialization, the offending code is here:
https://github.com/thorrak/brewpi-e...o/legacy-platformio/src/ESPEepromAccess.h#L44
my .002.
line 68 is dangerous. It might use too much stack.
uint8_t holding[sizeof(T)];
Have you check the maximum size of the structure ?
I'll have to check -- Size wasn't something I was really thinking about as I don't think there is anything dynamically sized in the structure, and it loads properly into RAM. Thinking about sizing (& struct padding) I'm wondering if it's a memory allocation thing more broadly... I should be getting temperatureFormat 'C', but instead I'm getting temperatureFormat 'null' (0x00). This is strange because SPIFFS starts with all the memory filled with 1s, and only flips bits to 0 when they're explicitly written as such. This would imply that some region that had been written is being read - just not the right region. Oh well. Going to try reordering the struct a bit and see if that helps.
Code:
template <class T> static bool readBlockFromFile(String target_name, T& data) {
if (SPIFFS.begin()) { // This may be an issue if called multiple times - going to assume it's not
File in_file = SPIFFS.open(target_name, "r");
if (in_file) {
uint8_t holding[sizeof(T)];
in_file.read(holding, sizeof(data));
memcpy(holding, &data, sizeof(data));
in_file.close();
}
}
// There's some kind of issue with SPIFFS or something.
// TODO - Log this
return false;
}
Code:
void * memcpy ( void * destination, const void * source, size_t num );Copying from "data" to "holding" doesn't seem right.
This was 100% the problem. You are amazing - thank you!
And progress keeps marching on.
v0.6 of the ESP8266 firmware has been released
Changes in this version:
That EEPROM to SPIFFS change is actually pretty massive if I do say so myself. Here's why.
Currently the WeMos D1 Mini (& related devices) have 4MB of flash memory, of which either 1MB or 3MB are reserved for SPIFFS, depending on how you flash it. By contrast, a maximum of 4kb of memory can be used for "EEPROM" of which only 1kb is actually used.
"But why do I care about extra space if I only need 1kb?"
Flash memory (including the EEPROM) has a finite lifespan of ~10,000-100,000 write cycles. Yes, that sounds like a lot, but on the ESP8266 every time you write to the EEPROM the entire 1kb gets overwritten. This includes every temperature setting change like, say, when doing a temperature ramp. By using the full flash space we add roughly 3 orders of magnitude to the longevity of the flash memory on the low end (and potentially another 1-2 orders of magnitude on the high end due to a nuance in the way this was implemented). In short - this change should help your controller to outlast you (or at least help the flash chip to).
In terms of user experience, will you notice anything? Hopefully, no. Your settings will need to be redone after flashing, but that should be it.
Special thanks to @pocketmon on this one - his catch resolved hours of frustration.
v0.6 of the ESP8266 firmware has been released
Changes in this version:
- EEPROM code completely rewritten to use SPIFFS
- (No seriously, that's a big change)
- Need to "reset" after initial installation should be fixed (for real this time)
- Extremely minor tweaks to memory usage nobody cares about
That EEPROM to SPIFFS change is actually pretty massive if I do say so myself. Here's why.
Currently the WeMos D1 Mini (& related devices) have 4MB of flash memory, of which either 1MB or 3MB are reserved for SPIFFS, depending on how you flash it. By contrast, a maximum of 4kb of memory can be used for "EEPROM" of which only 1kb is actually used.
"But why do I care about extra space if I only need 1kb?"
Flash memory (including the EEPROM) has a finite lifespan of ~10,000-100,000 write cycles. Yes, that sounds like a lot, but on the ESP8266 every time you write to the EEPROM the entire 1kb gets overwritten. This includes every temperature setting change like, say, when doing a temperature ramp. By using the full flash space we add roughly 3 orders of magnitude to the longevity of the flash memory on the low end (and potentially another 1-2 orders of magnitude on the high end due to a nuance in the way this was implemented). In short - this change should help your controller to outlast you (or at least help the flash chip to).
In terms of user experience, will you notice anything? Hopefully, no. Your settings will need to be redone after flashing, but that should be it.
Special thanks to @pocketmon on this one - his catch resolved hours of frustration.
Fare thee well v0.5, I hardly knew ye.
(I never got it to run, my Pi Zero would never flash it)
I did get my new Pi 3 yesterday so with any luck I'll have some time to kick the tires on this in a day or two.
(I never got it to run, my Pi Zero would never flash it)
I did get my new Pi 3 yesterday so with any luck I'll have some time to kick the tires on this in a day or two.
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
Got some Vmos D1 from ebay yesterday, exited to get started
Wonder if it`s possible and doable to get i up and running without nagging all of you guys with stupid questions Got some Vmos D1 from ebay yesterday, exited to get started
If it isn't, be sure to ask them here. My next project is rewriting the setup script & BrewPi web interface to let you set up everything graphically (rather than through the command line)
Did some testing.
- I verified that I did not need to reset after initial installation
- Tested renaming the AP (was unable to use an underscore in the name)
- Tested the door switch
Correct me if I'm missing something, but that sounds good! Glad to hear everything is working as intended.
If any of these aren't what you would expect, please let me know & I'll do what I can to correct.The underscore thing is as expected -- mDNS names should adhere to the same guidelines as domain names (which I believe exclude all punctuation). For the sake of simplicity I've limited it to alphanumeric rather than supporting unicode. Apologies, to those who use non-english keyboards.
Everything worked swimmingly!Correct me if I'm missing something, but that sounds good! Glad to hear everything is working as intended.
Yer right. RFC 1123 allows hyphens but not underscores. I was thinking NetBIOS.
About the only issue I seem to be having is an inability to pull up the device list on occasion. I'll just get the spinning clock thing and it never refreshes with the devices. It seems to happen when the system has run for a while (> a couple days).
Another (minor) feature, another (minor) update. v0.61 has been released -- for WiFi only.
In working on the v0.4.x conversion I was running into issues where I kept forgetting what the mDNS name/IP address was for my controller. I decided that I probably wasn't alone, so I went ahead and made the controller print this to the LCD when first powered on.
This doesn't impact functionality in any way, so feel free not to update unless this is a feature you want. Settings should be preserved between updates, if you choose to pull the trigger.
Separately, I also updated the wifi-reset script to zero out all settings (including mDNS name) when launched. When using wifi-reset, please wait ~30 seconds after flashing before reverting to the BrewPi firmware.
As always, let me know if you have any issues!
In working on the v0.4.x conversion I was running into issues where I kept forgetting what the mDNS name/IP address was for my controller. I decided that I probably wasn't alone, so I went ahead and made the controller print this to the LCD when first powered on.
This doesn't impact functionality in any way, so feel free not to update unless this is a feature you want. Settings should be preserved between updates, if you choose to pull the trigger.
Separately, I also updated the wifi-reset script to zero out all settings (including mDNS name) when launched. When using wifi-reset, please wait ~30 seconds after flashing before reverting to the BrewPi firmware.
As always, let me know if you have any issues!
Bigdaddyale
Well-Known Member
looks like you flipped that D1
Nice .... I was having the same issues but it never occurred to me to ask for that as a solution. I was using Fring and/or my router software to look for what was online.
That's actually the new D1 Mini Pro (as opposed to the v2). They removed the castellated ESP8266 module and moved everything to the PCB, flipping the side with the USB port in the process. They also added an external antenna connector, switched the PCB antenna for a ceramic one, and upped the flash to 16MB from 4MB. It's also lighter, and supposedly uses a different USB to UART chip.
That said, it doesn't have the FCC stamp, the ceramic antenna isn't necessarily better than the PCB one, and none of the software I've come across can use the full 16MB of flash, so yeah - no reason to update unless you want the external antenna connector. The main reason I got one was to test if it was a drop in replacement for the v2 for this project, and it turns out it is.
@Thorrak - what power supply did you end up using for this? If I am going to use your design for the box (no reason not to) I should make sure I have the same one.
I'm sure someone in China would be happy to put that stamp back on there.
Perfect timing! I finally managed to get my 3D printer back up and running this past weekend, and pulled the bottom part of the case off the printer this morning before heading to the train. Going to test if everything fits later tonight.
I'm sure someone in China would be happy to put that stamp back on there.
You mean the "Fabricated Central China" stamp? Oh, I'm sure they will!
I'm pulling my hair out guys - Brewpi does not see my temperature sensors. I have verified this on two different NodeMCU boards. I'm running the latest code - brewpi-esp8266.v0.61.wifi.bin. I loaded Onewire test code on the NodeMCU board and can see the sensors fine on D6. I have done numerous resets, power ups, and restore factory resets with no results. I have to be missing something. Is there a debug log I can look at?
Thanks
Thanks
Are you powering them in parasitic mode or powered mode?
Powered mode.
Well there goes my idea. Let me see what I can do when I get home.
Out of curiosity what demo code did you use which worked?
aknetman
Member
Subscribed. Thanks to all that put effort into this. I am going the glycol route rather than enclosed fridge... I am attempting to use two D1 minis to control two individual glycol loops using asco valves to control ferment temps. 5000 BTU AC unit will chill glycol tank of X gallons in a cooler with the AC unit condensor suspended in it. I have 2 coils of copper 25' long which the glycol will be pumped through to transfer BTUS from the beer (either glass carboys or SS 5 gallon kegs).
Instead of a Raspi, I am running the brewpi server on my freenas (which is always on, UPS protected, etc).
I have the "8 relay module" from sainsmart and some additional 30A dual pole single throw relays to control the valves and pump. This way, the pump will run when needed by either
a) the AC unit running, or
b) the asco valves opening.
but will not run otherwise.
I think I may use a regular old STC1000 to control glycol temp (AC Unit). I wonder if I should just use a single temp sensor per chamber or how this "beer temp" / "fridge temp" thing will work out since the glycol will be a static temp...
Instead of a Raspi, I am running the brewpi server on my freenas (which is always on, UPS protected, etc).
I have the "8 relay module" from sainsmart and some additional 30A dual pole single throw relays to control the valves and pump. This way, the pump will run when needed by either
a) the AC unit running, or
b) the asco valves opening.
but will not run otherwise.
I think I may use a regular old STC1000 to control glycol temp (AC Unit). I wonder if I should just use a single temp sensor per chamber or how this "beer temp" / "fridge temp" thing will work out since the glycol will be a static temp...
Thinking about how I might control the loops - understanding I've not done it.
I might use the "fridge" probe in the glycol tank and the beer probe in the glycol loop. Then leave the loop running at all times and the BrewPi in Beer mode. You would have to assume the beer was the same temp as the glycol jacket, but it's so efficient that's not much of a stretch - especially if the pump stays running.Another way would be to use a beer probe in the beer, the fridge probe in the glycol loop/jacket, and just use an STC to keep the reservoir at a set temp.
Third option: Combine the two. Have one control loop (BrewPi) controlling the coolant loop temp in beer mode with the fridge probe in the reservoir and the beer probe in the loop. The second control loop (BrewPi) in beer mode with the beer probe in the beer with the fridge probe in the jacket. This probably has the highest degree of control but of course has the highest degree of complexity.
Similar threads
