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.
- 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"
- Can often take a really long time to switch from the
spark-one dashboard to my home dashboard, or vice versa.
- 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.
- 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
- Metrics/data from my Tilt seem to have gone AWOL
- 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)
brewblox-ctl up is below:
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
Tue Nov 12 2019 15:47:45 GMT+0000 (Coordinated Universal Time)
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:
- temporarily turn off BitDefender. Note: creating an exclusion in BitDefender doesn’t seem to be a permanent solution to this problem
- refresh BrewBlox UI, thank Chrome for its warning but indicate that I want to continue on to the site
- 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.
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!
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.
I had this problem today, black screen and yellow blicking light. What I did is just re-install update, re-flash the Spark and reset the wifi. I get everything back in working conditions.
Yellow flashing means it is in DFU/bootloader mode to receive new binaries over USB.