Spark 3 Availability

[Fabrice_Dewasmes]

OK Thank you @Bob_Steers for the update. Looking forward to getting my hands on the hardware to start experimenting.

[Fabrice_Dewasmes]

@Bob_Steers

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.

that makes perfect sense.

@Bob_Steers

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.

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).

@Bob_Steers

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).

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.

@Bob_Steers

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.

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.

@Bob_Steers

We make extensive use of MQTT for publishing data, so listening in and forwarding status to Brewfather is relatively simple.

For this, yes this is fairly easy. Nothing fancy.

[Bob_Steers]

@Fabrice_Dewasmes

but I have no clue what will be the hardware specs of V4

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.

@Fabrice_Dewasmes

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.

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.

@Fabrice_Dewasmes

to understand what service-level means in brewblox

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.

[Fabrice_Dewasmes]

@Bob_Steers

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.

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.

@Bob_Steers

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.

OK crystal clear now.

@Bob_Steers

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.

Thank you for being so patient with me. It’s very clear for me now. I’m going to start investigating Brewfather integration possibilities.

[Studder]

Hello,

Can’t find specs on V4. I’m interested in buying one. Beta tester slots full already?

[Bob_Steers]

@Studder

Beta tester slots full already?

I think so, but @Elco is in charge of that.

[Fabrice_Dewasmes]

would be interested as well @Elco

[DanCook]

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!

[Marco]

Hello,
is it possible to pre-order Spark 4 before 1st of July?

Kind regards,
Marco

[Bob_Steers]

We stocked enough controllers to have no worries about availability issues on launch, and consequently have no plans for a pre-order scheme.

[mcinnes01]

Is there a date, specs or price yet?

[Bob_Steers]

The release date is still set for the 1st of july, with the detailed announcement (specs, description, price, etc etc) going up tomorrow.

[Marco]

I am very excited

[pkofod]

Today is 29th June… F5… F5… F5

[Elco]

I’m still processing photos and writing a bit of text to go with the photos.

Here is a teaser of the Spark 4 with 1 expansion module attached:

[Marco]

Very nice. I am looking forward to see the specs

[pkofod]

I know information will follow, but does that mean you can attach another extension module to the first? Would it also be possible to place the second one further a way connecting the two with a cable? Or is it module directly to module only?

[Bob_Steers]

You can stack modules up to a maximum of four. After that you run out of addresses on the connecting pins.
We have no cable for connecting IO modules, but I suspect it’d work just fine for reasonably short cables.

[Elco]

Info on the Spark 4 is published, please use this new topic to discuss:

This is the Spark 4

You can read the full announcement of the Spark 4 here: https://www.brewblox.com/blog/2021-06-30-this-is-the-brewblox-spark-4/ Information on pricing and ordering will follow soon.

[Marco]

Who wants to sell a Spark 3? Please send me a private message. Otherwise I will switch by end of this week to an other system.