You do that, then you reset via the button or a power cycle, then you should be able to re-scan for devices.Clicking on the "Reset the Controller to Factory Defaults" doesn't seem to do anything.
You do that, then you reset via the button or a power cycle, then you should be able to re-scan for devices.Clicking on the "Reset the Controller to Factory Defaults" doesn't seem to do anything.
Okay - I can telnet into the NodeMCU but I can't seem to get Brewpi to talk to it. I used the following in the config file:
wifiHost = 'myIPaddress'
wifiPort = 23
Is this correct?
Okay - I can telnet into the NodeMCU but I can't seem to get Brewpi to talk to it. I used the following in the config file:
wifiHost = 'myIPaddress'
wifiPort = 23
Is this correct?
wwwPath = /var/www/html
wifiHost = ESP[I]XXXXXXX[/I].local
wifiPort = 23
wifiHost = 192.168.0.100
That is exactly what I have and still not working. Does it work this way on your system?
wwwPath = /var/www/html
profileName = Test%20Profile%20-%202%20min%20start
beerName = ESP8266%20Test
dataLogging = active
wifiHost = 192.168.5.200
wifiPort = 23
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'
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.
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.
I approve of this message.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.
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 RAM
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
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 ?
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;
}
void * memcpy ( void * destination, const void * source, size_t num );
The prototype of memcpy: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.
And progress keeps marching on.
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.
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
Did some testing.
Verified that when set as "not inverted," D7 shows the door closed when the pin is grounded, and open when the pin is not grounded.
- 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
Everything worked swimmingly!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.
Yer right. RFC 1123 allows hyphens but not underscores. I was thinking NetBIOS.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.
looks like you flipped that D1
I'm sure someone in China would be happy to put that stamp back on there.That said, it doesn't have the FCC stamp
@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.
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
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?[/QUOTE
The example code that came with the OneWire library called DS18x20_Temperature.
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...
Enter your email address to join: