Not yet. We still have to set up the product page and sort out some details.
2 Likes
Do you have any details on the spec etc? Many thanks Andy
2 Likes
Hi Bob,
I’m currently setting up a micro brewery in Luxembourg and was expecting to use your system that I found very well thought and engineered.
I absolutely need to have a rough date of availability to have an idea of when I could be able to start the first batch. You were mentioning you were expecting to be ready on the 20th. Is it still the case? If not what could be your schedule?
As already mentioned in my emails, I could help on automation if you are interested as I’m de developer and engineer myself 
@mcinnes01 @Fabrice_Dewasmes The PCB production run referred to earlier is happening now, after the prototype passed CE tests.
We’ve kept release dates vague until we were sure we could source all components despite global shortages, but the major hardware hurdles are behind us.
With this done, we’re now preparing the store page, setting the retail price, collating the spec sheet, and scheduling software system tests.
We expect to pin a release date tomorrow, and will keep you updated.
@Fabrice_Dewasmes Contributions are always very welcome. Your email mentioned Brewfather. Did you have any specific features in mind?
2 Likes
Thank you @Bob_Steers for your reply. Excellent news 
About Brewfather I was thinking of the same kind of integration SmartPID does. Which means pushing the recipe from Brewfather to Spark and create automation process based on this recipe. It could also be interesting to update Brewfather on brewing process and fermentation. I have briefly looked at API for the moment but haven’t tested anything yet but recipe linking seems pretty straightforward.
see : SmartPID - Brewfather - docs
What I like is to have everything under one interface to drive temperature setpoints during mashing for instance
This sounds like it significantly overlaps with functionality @PlazzmiK was talking about in Brewblox / Automation.
It’s explained in more detail in that topic (and I’m currently busy writing a full doc), but do note that we are discontinuing our own automation service in favor of solutions compatible with third-party editors.
Brewfather recipes would be a good example of such integration, but it will either interact directly with controller blocks, or with a new process control layer.
Given the external interest, I can definitely reschedule some time to assist or develop required functionality. Would you prefer working from the recipe side down, or from process control up?
1 Like
I’ve read the thread but that’s not clear for me which way you decided to go.
As I understand it: you are about to abandon automation services as it is for the moment and are planning to implement it using Nodered (→ is it the third party you were mentioning?). Interesting move as it is reliable and user friendly even though made for experimented users. But do you plan to hide node red UI and use it as an engine and create a brewblox UI on top of it?
You seem to prefer to have code mostly running on the embedded side which is definitely the way I would have gone for reliability purpose but that seems a bit opposite to the nodered approach (unless you are planning to use nodered on the embedded side as well?)
Back to Brewfather integration, I have to see if the code source of SmartPID integration is available somewhere but I would say that brewfather and smartpid have a mutual agreement as SmartPID seems fully integrated in brewfather UI. I have to get a better grasp on communication and what SmartPID actually does when communicating. So I am not sure Brewfather can actually drive controller blocks. I was more thinking of grabbing the whole recipe from Brewfather and convert it to automated temperature management in brewblox. It’s a first approach. But the best would be to drive and monitor everything from Brewfather UI but this I’m not sure how to do it.
Our preferred solution is to let users use the Node-RED UI to build custom subroutines, and then start/stop/monitor them from the Brewblox (or Brewfather) UI.
That way, you have a user-friendly editor for non-trivial automation, and don’t need to switch UIs during brew days or when quickly checking up on active fermentations.
As to embedded/service-side code: the controller manages critical process control, and is fully independent by design. PID control will continue uninterrupted if the service exits or loses connection.
The drawbacks are that the Spark 2/3 are heavily memory-constrained, and that embedded C++ is about as unsuitable for user scripting as it gets.
Automation at service level (automation service or Node-RED) is best suited for custom user-defined subroutines, or process control that relies on network interaction (fetching recipes, sending alerts, or listening to a REST or MQTT API).
Any Brewblox integrations of Brewfather would live at the same level as SmartPID. Recipe integration would involve keeping track of timers and setpoint settings, not low-level actuator control.
Implementation would involve a Brewfather <-> Brewblox conversion service to handle data formatting, and some service-level automation for control routines not available in firmware.
We make extensive use of MQTT for publishing data, so listening in and forwarding status to Brewfather is relatively simple.
We’ve taken a look at the planning, and pinned some dates:
The release date for the Spark 4 is 1 july. This includes software support.
Closed beta release is 15 june. At this point the hardware and internal software tests are done, and we send out some Sparks to beta users to flush out the last few bugs.
We’ll keep you updated with more details on how the Spark 4 and its expansion boards work and look like.
Next week we’re releasing all non-Spark 4 software features I’ve been working on while Elco was preparing the hardware production run. This includes some significant improvements to the Builder editor.
3 Likes
OK 
Thank you @Bob_Steers for the update. Looking forward to getting my hands on the hardware to start experimenting.
that makes perfect sense.
This also makes sense. Having the whole nodered environment running on the embedded side is mot probably unfeasible (but I have no clue what will be the hardware specs of V4).
Yes I see. Nodered process runs on server and send commands to spark over MQTT. In this case, if the link between server and spark are stable this could be fine. But in case of failure, it can get tricky to recover state from spark to server and resync because as mentioned the spark device is built to be autonomous (thank god ) once commands are received.
I totally agree. Sending/receiving to/from Brewfather requires transformation from Brewfather format to automation in brewblox. This is where I still have to read all the documentation that is available (congrats for that!) to understand what service-level means in brewblox.
About ‘where smartPID lives’ this is also something I have to figure out. It seems that it is not open to anyone to have integration within Brewfather the way it is done for SmartPID. I will try to understand this from the way smartPID integration is configured to understand how it works because Brewfather documentation doesn’t say anything about his except API which is rather simple.
For this, yes this is fairly easy. Nothing fancy.
The v4 is built around the ESP32. This is a significant upgrade from the Particle photon/p1, but installing a Node.js runtime for Node-RED is indeed not an option.
We’ve designed pretty much everything with the requirement that after reboots/reconnects/errors it picks up exactly where it left off. For this reason, the Spark API is completely state-based. The service polls the Spark every 5s, and publishes the full state.
There’s three main “levels”:
- firmware on the Spark controller
- services on the server (typically a Pi, but most Linux-based machines will do)
- UI in the browser
“service-level” means it’s code running inside a Docker container on the server.
I’m also only vaguely familiar with the Brewfather / SmartPID API, so won’t be of much help there.
OK I already experimented with ESP32 so I see the kind of possibility. NodeJS runtime won’t fit on the chip that’s for sure.
OK crystal clear now.
Thank you for being so patient with me. It’s very clear for me now. I’m going to start investigating Brewfather integration possibilities.
1 Like
Hello,
Can’t find specs on V4. I’m interested in buying one. Beta tester slots full already?
I would also be interested in being a Beta tester for V4, especially as my V3 is effectively bricked and taken apart at the moment so I have nothing to control my fermentations!
1 Like
Hello,
is it possible to pre-order Spark 4 before 1st of July?
Kind regards,
Marco
We stocked enough controllers to have no worries about availability issues on launch, and consequently have no plans for a pre-order scheme.
4 Likes
Is there a date, specs or price yet?