I’ve got the start of working firmware to add in support for the items that I need. Basically this adds support for how my glycol system is setup, using wifi instead of serial link and adding a more flexible way to connect inputs to outputs. Also included is a simple json library. This code only works on photon as thats what I have. I’m sure it’ll be too big for spark. Some info is on the wiki on github. Hopefully though some of it will be useful and back portable into the base firmware.
I’ve attached a compiled version for anyone who wishes to try it out. There is just enough functionality to play with and control a simple fermentation (single set point, no profile support). The interface is all via telnet to the BrewPi (see github documentation on the protocol).
Note that since this is based on the particle 0.4.6.1 firmware, you will need to upgrade your base firmware (system-part1 and system-part2 images). Instructions for that are on the particle github site (linked from my github or from the brewpi github). Note as well that to go back to the standard BrewPi firmware, you’ll need to move back to the older 0.4.4 firmware.
(fyi, the most direct reason for this is that the BrewPi firmware instantiates the OneWire bus in global scope outside any function in Board.cpp. The OneWire (DS248x) constructor calls Wire.begin(). The 0.4.6.1 firmware does not like Wire.begin() to be called prior to setup().)
brewpi2.bin (31.4 KB)
This sounds great! And would be awesome if you could submit PRs to the brewpi repo for the parts that would benefit everyone, such as wifi connectivity.
Cheers! 
This is great work and there are certainly a few parts that could be used in the official firmware. I like the JSON class and the WiFi connectivity.
I understand why you decided to start fresh instead of modifying TempControl.cpp. It was a large monolithic implementation that was hard to make modular. That is however, what I have been doing in the past months.
The flexibility of having multiple PIDs that you coded largely overlaps with what I have coded myself.
Please see the new PID class here:
https://github.com/BrewPi/firmware/blob/feature/actuatormutex/app/controller/Pid.h
I have not refactored the main control loop yet, but you can see how the new class is used (in combination with new actuator classes) in this simulation unit test:
https://github.com/BrewPi/firmware/blob/feature/actuatormutex/boost_test/SimulationTest.cpp#L325
My PID class uses a new fixed point class, which is better for filtering and uses less code size than floating point data types.
We use Slack to chat among developers, I have sent you an invite. Would be nice to have to on board working on the latest firmware code, instead of rolling your own in parallel. 
Thanks. Invite accepted.
I had seen on a thread that you were working on a new PID class. It looks good. I see though that the PID still drives the state GPIO outputs directly. In my use case, I have a pump that is required to go on when any fermenter calls for cooling. By decoupling the PID from the GPIO and using the Connection class, I can account for that (PumpOutput = Cooling1 or Cooling2). Because there are no predefined relationships, the code is flexible for use in other situations too such as mashing.
The new Actuator classes look nice too. I like the PWM class. I wouldn’t be too hard to insert a Connection class between them, though device config does need a unique identifier for it to work (I used a device name field in my device manager for that).
Wifi support is all in the BrewLink.* files. Getting to the 0.4.6.1 firmware was key to that as they fixed a bug in TCPClient that was causing stability issues for me. The weird thing is that photon wifi appears to only support DCHP, not static IPs. Thankfully though its easy enough to put a static DHCP lease in pretty much any home router to get around that. I’ve detailed wifi setup here: https://github.com/etk29321/BrewPi2-firmware/wiki/Wifi-Setup
Thanks for accepting our invite! Welcome to the dev team! 
I think there must be a misunderstanding about driving GPIOs directly - the PID class doesn’t drive GPIO’s directly but instead drive an Actuator, with the error output of the PID. This is an interface - the Actuator may do what it likes with that value. Sure, some actuators may drive a GPIO based on the value of the interface, but others may do other things, such as feed into the PWM actuator.
In essence, it’s a pipeline, values flowing from one stage to another, and I think in future we might see these process-specific interfaces generalized even further to allow even greater flexibility.
Wifi is exactly what I’m looking for but I’m running into some issues getting this up and running with the instructions.
When I flash brewpi2.bin, I get the “breathing” green or cyan led. I can see the device attached in my router, but it isn’t assigned an IP address. Trying to set the wifi up from here (particle setup wifi) fails.
So if I get it into “safe” mode I can forget the wifi settings, and “particle setup wifi” works. When I do this I get the “breathing” magenta led. In this mode I can see it get assigned an IP, however trying to telnet in is refused.
True, I mean that there is a 1:1 relationship between PID and actuator. I need a more complex relationship between inputs and outputs. “If any beer temp PID output is negative (cooling), set glycol pump Actuator to high”.
Did you upgrade to the 0.4.6.1 particle firmware? This is very limited firmware compared to the standard brewpi firmware and it is not a drop-in replacement. It’s a technology preview that works for my specific situation basically. I would not recommend it to anyone not able to compile it themselves. Now that I have it working for me, my next step is to figure out how to move it into the stock brewpi firmware.
You’d have to recompile to reconfigure for your setup. I realized after I posted it that since I have my OneWire devices hardcoded in setup() right now, if you do get it to “work”, it should go straight to flashing red after boot since your devices won’t live at those addresses and I’m not checking for null pointers in that bit of code as I should.
Did you upgrade to the 0.4.6.1 particle firmware?
I did. Installed node.js, particle-cli - the whole bit.
It’s a technology preview that works for my specific situation basically. I would not recommend it to anyone not able to compile it themselves.
If that’s the case, there’s kind of a conflicting message in your second post.
I’ve attached a compiled version for anyone who wishes to try it out.
I wanted folks to try it out, but it is not really for the casual user. I’ve re-uploaded the bin file with the setup() lines for my specific config commented out. That should be loadable and useable by others now. Personally, I have my connections hardcoded into setup() and would recommend anyone with a similar setup who wanted to use this firmware until the brewpi trunk has similar capabilities to do the same. There is no way to save configs, so all connection configurations will be lost on reboot unless you put them in setup() and recompile.
Note that this firmware is not compatible with brewpi-scripts or brewpi-website nor does the local lcd display work. The only interface is via serial or telnet to port 8080.
Now that I have something that works for me for now, I’m pivoting my efforts to merging the wifi and JSON code into the official brewpi firmware. I think thats the path to making this more generally useful for the larger population.
1 Like