Edge release 2019/11/12

Relevant links:

Edge release 2019/11/12

Firmware release date: 2019/11/12

Firmware stability and calendar time

Multiple users were suffering from crashes and hangups most likely caused by bugs in the Wifi system layer.
This release includes a system layer update from particle that that should fix many of these issues.

The Spark now also receives the current time if it connects to the Spark cloud. So if the brewblox service on the pi down, it can still track profiles.
If no cloud connection is used or the Sprak does not have WiFi, it will be able to restore the last system time it recieved from the service from backup memory.
This means that the system time will only be lost on a power cycle. When using only USB, the service swill still set the time.

These changes also mean that the time cannot overflow anymore and long running profiles are not a problem.

Graph configuration

We reworked yet another configuration screen. This time it’s selection of history fields (Graph, Metrics, Session View).

The Graph configuration suffered from being overly detailed.
The history service has no notion of blocks, and allows every individual field to be selected. This requires users to make very fine-grained decisions when selecting data to show.
Settings were also very spread out: adding a single field might require using 3 out of 4 tabs in the settings.

To improve visibility we removed the tabbed layout, and merged the settings in the field tree.
You can now click on nodes to edit their display settings.

New Widget: Session Log

We added a new widget: the Session Log. The goal of this widget is to write down things during a brew day: when did things happen? What was the start SG?
You can export this to printable HTML. It is also the easiest place to keep graphs of sessions, because it has a start and stop button.

The Session Log allows creating a template for your brew day / batch notes.
In the basic view, you can click on a note to edit its value without changing the template settings.
When starting a new session, it will automatically copy the template from the current opened session.

The session consists of a number of notes. You can edit the title and display width for each note in the Full view of the Session log widget.

  • Text notes are multiline editable fields. There’s a button for adding a timestamp, to make it easy to use for logging purposes.
  • Graph notes have two sets of configuration.
    • You configure the graph fields while creating the template.
    • You can import fields from Graph widgets, or other graph notes.
    • During the brew day you click on the note to show the graph, or start and stop the period.

You can export sessions to a simple HTML file. Any markdown syntax in text notes will be rendered.

We think that Session Log is a sufficiently big improvement over the Session View widget that it can completely replace it. If feedback is positive, we’ll likely deprecate and eventually remove the Session View widget.

Changes

  • Updated Spark system software.
    • This fixes multiple bugs that caused crashes or boot loops.
  • Reworked the settings component for selecting history data (used in Graph, Metrics, Session View, Session Log)
  • Add Session Log widget and builder part.
  • Tweaked the sidebar layout to remove visual clutter.
  • Renamed the Step View widget to Quick Actions.
  • Remove prompt to locally preview brewblox-ctl log.
  • Fixed a bug where invalid pin assignment would crash generation of the link file when clearing Spark blocks.
  • Setpoints now show the enable/disable toggle in the basic display.
  • Import graph settings when starting a new session in Session View
  • Improved Dashboard wizard.
    • ID/URL is now automatically suggested based on chosen title.
  • Block dialogs opened by clicking a relation diagram will now initially show the basic display.

A bug in the UI required an immediate hotfix.

If you already downloaded the update, you can pull just the UI by running these commands:

docker-compose stop ui
docker-compose pull
docker-compose up -d

I’ve flashed the firmware and taken the software updates. As partial proof I now see Quick Actions instead of Step View, and Session Log is among my choices for a widget.

Known issues:

  1. Having a hard time actually adding widgets. I get no immediate reaction from the “CREATE” button, and if I eventually cancel out of the dialog I get an on-screen message "Unexpected token < in JSON at position 0"
  2. Can often take a really long time to switch from the spark-one dashboard to my home dashboard, or vice versa.
  3. Very occasionally the creation of a widget succeeds, but for example if I create a Metrics widget and try to add some metrics, when I tick a checkbox it doesn’t actually get ticked. Or the widget claims there are no metrics to show because none have updated in the past 24 hours.
  4. If I try to F5 (refresh) my primary dashboard, Chrome spins the page loading icon seemingly forever. It may eventually refresh after 4 minutes, but more commonly I’ll duplicate the Chrome tab and the new one gets the expected reaction
  5. Metrics/data from my Tilt seem to have gone AWOL
  6. And truly strange: the front panel of my Spark shows temps in C rather than F, even though all other places where temps appear show them in F (screenshot shows the UI version)

Output from brewblox-ctl up is below:

Running command:
         docker-compose up -d --remove-orphans

Creating network "brewblox_default" with the default driver
Creating brewblox_mdns_1      ... done
Creating brewblox_traefik_1   ... done
Creating brewblox_ui_1        ... done
Creating brewblox_datastore_1 ... done
Creating brewblox_influx_1    ... done
Creating brewblox_eventbus_1  ... done
Creating brewblox_history_1   ... done
Creating brewblox_spark-one_1 ... done
Creating brewblox_tilt_1      ... done
Version
0.2.2+1245.gc619fe6e

Build date
Tue Nov 12 2019 15:47:45 GMT+0000 (Coordinated Universal Time)

image
Picture of front panel

That’s very much not supposed to happen (and a new bug). It sounds like it’s having network problems accessing the datastore and history services.

Could you please open your developer console (ctrl + shift + i), and go to the network tab?
When that’s open, refresh the page, and re-run the wizard, until you see the on-screen error message.

Then download the error log (bottom of the sidebar, the bug icon), and right-click on the network tab to download requests as HAR file.

You can see the general page loading problem in this link. At 20s I duplicated the tab, and at 30s I closed the original tab. Once the original tab was closed the page load succeeds as expected:

Here is an example of an errors file from an earlier set of attempts:
brewblox-errors (1).json (2.9 KB)

I think that I may have a partial explanation: once I disable BitDefender (AV software) things seem to work more reliably. I will try to reproduce a widget error and then send the related error log.

And if I want truly dysfunctional behavior I can turn BitDefender back on, and use Microsoft’s Edge browser.

So I guess the question I need to work on is how to get the AV software to be happy with the self-signed cert.

Better error reporting for parse errors is on my to-do list, but the initial < suggests an HTML response where we expect a JSON payload. Bitdefender injecting some HTML error page does sound plausible.

To disable web page scanning, Bitdefender documentation suggests https://www.bitdefender.com/consumer/support/answer/1519/
If you whitelist the base URL (the part before /ui/, it will cover everything: we let Traefik reverse proxy all service APIs to subdomains under the shared host.

Question after perusing this thread: Net::err_cert_invalid

What are the triggers which cause a new cert to get created? Reason I ask: it seems that the overly eager anti-phishing protection from [ BitDefender + Chrome ] conspires to make me go through a cert re-acceptance process whenever the BrewBlox services/containers are spun down and up again. In that case my current steps are:

  1. temporarily turn off BitDefender. Note: creating an exclusion in BitDefender doesn’t seem to be a permanent solution to this problem
  2. refresh BrewBlox UI, thank Chrome for its warning but indicate that I want to continue on to the site
  3. turn BitDefender back on

The fact that the microservices are portable / containerized is cool, but on the other hand failure of the webUI to communicate with the services ends up looking like other types of problem, e.g. that the Spark or Tilt have gone offline.

It’s not a new cert, it’s your browser only creating a temporary exception for the same cert. The BrewBlox installation creates a self-signed cert valid for a year.

As a historic aside: we use https because we need the higher number of simultaneous connections allowed by http2. These are used for block graph, and widget updates.

We can’t automatically use a service like LetsEncrypt because we can’t offer a public-facing URL LetsEncrypt can use to verify the installation residing on your Pi.

You could generate your own externally signed SSL cert, and use it to replace one in brewblox/traefik/. This does require having a public DNS name for validation. After verification you can reroute that name to your Pi.

This approach is certainly not hassle-free, and will likely involve you learning more about SSL certs than you really wanted to know.

Can you not install the self-signed cert in your browser? Note: I haven’t tried this yet. https://www.attachmate.com/documentation/gateway-1-1/gateway-admin-guide/data/fxg_add_untrusted_cert.htm

It’s an option. You can also add the cert as root certificate in your OS, or generate your own (separate) root certificate, and use that to sign a cert used by brewblox.

An alternative is to disable BitDefender page scanning. It comes down to how valuable the feature is, in terms of effort required to circumvent this false positive.

Hi, I did what seemed like a successful upgrade, but I’m stuck at " Your Spark service is waiting for the controller handshake.
This status is usually temporary"

Where do I find more clues?

Does your Spark have a Wifi connection? If not, you’ll want to let it connect to Wifi, so it can download the latest bootloader.

If for some reason that’s not feasible, you can also manually flash the bootloader, but that does carry some risk.

No I never set it up for wifi, I just left it hooked up via USB since I power it that way anyway. What’s the risk?

Some users ended up with a bricked Spark after flashing the bootloader. We can fix that, but it requires a hardware debugger - you’d need to mail the controller to us.

It’s a rare bug, but one we never managed to reproduce.

Ok, sounds less than ideal. Can the spark still be powered via usb from the pi when set up for wifi or will that redundancy mess with the system?

You can use USB for power/data just fine while the Spark has a Wifi connection. It’s also fine for the Spark to have Wifi, USB and the 12V power cable connected at the same time.

The Spark service on the Pi prefers USB connections by default, and will only start scanning for Wifi devices if it can’t find any USB devices.

Solved by enabling wifi. This is outstanding user support Bob, super fast and spot on. Thank you so much!

2 Likes

why not add a button to export the self signed certificate in the settings section to make it easier to get and import into our local root cert store. Maybe an update to the next release?

Browsers already support this: https://www.shellhacks.com/get-ssl-certificate-from-server-site-url-export-download/

Adding a cert to your trust store does carry risks. So far we’ve been reluctant to make it an installation step, but improvements to cert creation are on the backlog anyway (autofilling the prompts). We’ll likely then re-evaluate whether to update the guide with instructions on how to trust the cert.