I actually had a very similar issue after the most recent update. It appeared to try to flash the Spark, but something went wrong and I ended up with the same Firmware not compatible error.
What worked for me was to connect the Spark by USB, then log into the Raspberry Pi using ssh, cd into /home/pi/brewblox then run:
brewblox-ctl flash
This then recovered the Spark. I am not sure what went wrong in the earlier flash, but this sorted it!
Jerry
Seeing odd behaviour. Both if my Tilts are in the same beer,. The Tilt service appears to not be using the calibration file. Both in the graph, and in a metrics tile I have on the dashboard, the values shown are the uncalibrated values, not the calibrated ones.
I have added the same calibration points into both the Tilt app, and the SGCal.csv. It does appear that it is found on load, but not sure why it is not being used.
pi@fridgepi:~/brewblox $ brewblox-ctl follow tilt
Attaching to brewblox_tilt_1
tilt_1 | 2020/05/03 03:05:12 INFO brewblox_service.service Creating [tilt] application
tilt_1 | 2020/05/03 03:05:12 INFO brewblox_tilt Calibration file /share/SGCal.csv loaded for colours: Black, Red
tilt_1 | 2020/05/03 03:05:12 WARNING brewblox_tilt Calibration file not found: /share/tempCal.csv . Calibrated values won’t be provided.
tilt_1 | 2020/05/03 03:05:12 INFO brewblox_service.service Service info: v1.0.2-47-gfe397ed @ Sun Mar 29 17:36:24 UTC 2020
tilt_1 | 2020/05/03 03:05:12 INFO brewblox_tilt Started TiltScanner
tilt_1 | 2020/05/03 03:05:13 INFO brewblox_tilt Found Tilt: Black
tilt_1 | 2020/05/03 03:05:13 ERROR brewblox_tilt Error when publishing data AmqpClosedConnection()
tilt_1 | 2020/05/03 03:05:13 INFO brewblox_tilt Found Tilt: Red
tilt_1 | 2020/05/03 03:05:13 ERROR brewblox_tilt Error when publishing data AmqpClosedConnection()
[…]
pi@fridgepi:~/brewblox $ cat tilt/SGCal.csv
black, 1.002, 1.000
black, 1.089, 1.095
black, 1.073, 1.077
black, 1.063, 1.066
black, 1.047, 1.053
black, 1.036, 1.043
black, 1.029, 1.034
red, 0.997, 1.000
red, 1.098, 1.095
red, 1.071, 1.077
red, 1.059, 1.066
red, 1.047, 1.053
red, 1.037, 1.042
red, 1.027, 1.034
Any ideas?
Thanks,
Jerry
Have you selected the calibrated values for your metrics widget or just the uncalibrated ones? The service has definitely picked up your calibration file, looking at your logs.
I’ve just pushed an update. This includes a fix for the issue @frizzo noticed with the units of the signal strength along with @Bob_Steers’s fix for extreme outliers. Unfortunately, I haven’t been able to test this properly as I’ve run out of batteries. Got some on order. But let me know if you spot any issues.
That is really odd. Is that a new addition? I do not recall changing that or selecting that previously, but I am sure it used to read the correct values. Either way, all good now! 
Updated to include this. I still see historical outlying values. I assume this will only prevent any new ones?
Thanks for the updates!
Nope. Been there almost from the start
Yep. This is only for new data.
I must have done something stupid on a recent update then. Would not be the first time! 
After a second reboot and running the UI updating service twice it simply worked. So thanks again for your support, now the setup looks very good.
Thank you Jerry - USB also failed on my system, but reboot and a two more tryes in the UI over WLAN did the trick.
Brewblox losing TILT data every few days right around midnight. Didn’t catch it today until noon and I’m on day 3 of a primary ferment so not a huge deal, but did lose data for about ~30 points drop in SG. “brewblox-ctl restart” restored the connectivity, though I didn’t think to snag the tilt container logs first. Should mention I have an iPhone right next to the brewblox pi. The iphone has the Tilt app logging data to brewstat.us as a backup. That logging remained continuous, so pretty sure the outage occurred on the pi running brewblox.
Anything I can do to triage this after-the-fact?
Note: I did not apply the latest tilt code yet.
Thanks,
-Frank
Huh. That’s odd. Can’t think of anything after the fact. But if you do get logs of it in the future, I’d be interested.
Thanks. I was afraid of that. Would be nice to have startup+error messages also written to a persistent fileystem on the host. Without having to balance the desire for debugging and triage against runtime concerns on a “production” system.
Are the logs not managed by docker for this?
docker-compose logs --follow tilt_container_name
Did you disable ipv6 on the pi? We added a tool to do this.
brewblox-ctl disable-ipv6
@elco
IPv6 disabled? No, if the veth* network devices are any indication, they all still have inet6 addresses… so IPv6 still enabled.
As far as the" docker-compose logs tilt" command are concerned, they seem to get truncated/reset after every restart. Same output as “docker logs brewblox_tilt_1 -f”
Thank you, for doing the update, I did the update and during the time my raspi was receiving data, I did not see any peaks. Unfortunately my raspi usually stops receiving data from tilt after 12-14 hours (Also with the original TIltpi image). So I scheduled a regular reboot, which unfortunately is not working reliable, I guess it is more a Raspi than a Brewblox issue. Since sometimes he doas not come up again. But all data I have received so far are looking good.
Thanks for this. It’s useful that you said you’ve had the same issue with the Tilt Pi image. I’m suspecting issues in the bluetooth drivers in linux. We had issues with them early on in this implementation. I’ve seen people saying that the new Ubuntu 20.04 image is far better on the whole than the raspian images. I might experiment and see if its better with bluetooth, too.
@j616s or @Bob_Steers, Am I correct in thinking that the default upper and lower are 2 and 0.5? where can I change these defaults.
As you can see from the attached still getting some strange highs. Would like to set the upper bound to 1.066 and lower the 1.002.
