Do the logs for the tilt service show anything new?
here is my termbin: https://termbin.com/g0fa
EDIT: A shot in the dark here, but does it matter that there’s no port for the Tilt?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++ Containers +++++++++++++++++++++++++++++++++++++++++++++++++++++++
Name Command State Ports
--------------------------------------------------------------------------------------------------------------------------------------
brewblox_eventbus_1 /docker-entrypoint.sh /usr ... Up 0.0.0.0:1883->1883/tcp,:::1883->1883/tcp
brewblox_history_1 python3 -m brewblox_history Up 5000/tcp
brewblox_redis_1 docker-entrypoint.sh --app ... Up 6379/tcp
brewblox_spark-one_1 python3 -m brewblox_devcon ... Up 5000/tcp
brewblox_tilt_1 python3 -m brewblox_tilt Up
brewblox_traefik_1 /entrypoint.sh --api.dashb ... Up 0.0.0.0:443->443/tcp,:::443->443/tcp, 0.0.0.0:80->80/tcp,:::80->80/tcp
brewblox_ui_1 /docker-entrypoint.sh ngin ... Up 80/tcp
brewblox_victoria_1 /victoria-metrics-prod --r ... Up 8428/tcp
The tilt service looks entirely normal, apart from nothing showing up.
This is intentional.
Maybe a stupid question, but did you restart the Pi after updating?
I can also prepare some more detailed tests, but that involves code, so will have to wait until tomorrow.
Yes I did restart the pi after updating. Strangely enough, I removed the official Tilt service and reinstalled the original 3rd party one, and now I can see tilt values in the metrics widget again. Here is the output from brewblox-ctl follow pi:
Attaching to brewblox_tilt_1
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_tilt Calibration file /share/SGCal.csv loaded for colours:
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_tilt Calibration file /share/tempCal.csv loaded for colours:
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_service.service Service name: tilt
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_service.service Service info: v1.0.2-66-g8f4be02 @ Mon Jan 11 19:31:43 UTC 2021
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_service.service Service config: {'host': '0.0.0.0', 'port': 5001, 'name': 'tilt', 'debug': False, 'mqtt_protocol': 'wss', 'mqtt_host': '172.17.0.1', 'mqtt_port': None, 'mqtt_path': '/eventbus', 'history_topic': 'brewcast/history', 'state_topic': 'brewcast/state', 'lower_bound': 0.5, 'upper_bound': 2}
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_service.mqtt Starting <EventHandler for wss://172.17.0.1:443/eventbus>
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_tilt Started TiltScanner
tilt_1 | 2021/12/01 23:43:41 INFO brewblox_tilt Found Tilt: Green
Good to know. That narrows down the list of potential causes. I’ll cook up something to verify tomorrow.
Final thing for today: I borrowed my neighbors Black tilt and repeated all these steps. It also is visible using James’ tilt service, but not with yours.
Thanks for your help on this!
There are some reports that Bluetooth versions impact things.
What is the output of these commands?
hciconfig -a
apt show bluez
I published a version of the tilt service to develop
that lets you override its internal setting for the used bluetooth version.
To set it, update image
to brewblox/brewblox-tilt:develop
, and add the HCI_VERSION
environment variable:
tilt:
image: brewblox/brewblox-tilt:develop
labels:
- traefik.enable=false
environment: ["HCI_VERSION=8"]
network_mode: host
privileged: true
restart: unless-stopped
volumes:
- ./tilt:/share
Relevant values for the HCI version can be found in https://btprodspecificationrefs.blob.core.windows.net/assigned-numbers/Assigned%20Number%20Types/Host%20Controller%20Interface.pdf, but you’ll want to try 6, 7, and 8 mostly.
There’s no need to stop the services while editing. Run brewblox-ctl up
again, and it will restart the tilt service to apply the changes.
Thanks Bob. Do I update my docker-compose.yml with that block you just updated?
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:00:B9:66 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:1562 acl:0 sco:0 events:96 errors:0
TX bytes:2574 acl:0 sco:0 commands:96 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'raspberrypi'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x156
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
Package: bluez
Version: 5.50-1.2~deb10u2+rpt1
Priority: optional
Section: admin
Maintainer: Debian Bluetooth Maintainers <team+pkg-bluetooth@tracker.debian.org>
Installed-Size: 3,771 kB
Depends: libasound2 (>= 1.0.17), libc6 (>= 2.28), libdbus-1-3 (>= 1.9.14), libdw1 (>= 0.127), libglib2.0-0 (>= 2.31.8), libreadline7 (>= 6.0), libudev1 (>= 196), kmod, udev, lsb-base, dbus
Suggests: pulseaudio-module-bluetooth
Conflicts: bluez-audio (<= 3.36-3), bluez-utils (<= 3.36-3)
Breaks: udev (<< 170-1)
Replaces: bluez-audio (<= 3.36-3), bluez-input, bluez-network, bluez-serial, bluez-utils (<= 3.36-3), udev (<< 170-1)
Homepage: http://www.bluez.org
Download-Size: 770 kB
APT-Manual-Installed: no
APT-Sources: http://archive.raspberrypi.org/debian buster/main armhf Packages
Description: Bluetooth tools and daemons
This package contains tools and system daemons for using Bluetooth devices.
.
BlueZ is the official Linux Bluetooth protocol stack. It is an Open Source
project distributed under GNU General Public License (GPL).
N: There is 1 additional record. Please use the '-a' switch to see it
Yes, you can replace your current tilt service with that block of config.
Yay!
The problem seems to be the combination of Bluez 5.50 and Bluetooth 5.0+ (HCI version). The environment variable overrides the adapter setting, and switches back to Bluetooth 4.2. I already added a Pi 4-specific patch, but a more extensive solution seems to be required.
Unrelated: your Pi is throwing up undervoltage errors. You may want to double check your power supply.
On the new Tilt Display in the Builder widget, it seems that it maybe isn’t supported on iOS screens? Have you noticed this before?
No, that’s new - but we don’t have Apple hardware at hand, so tests are sketchy.
Does this also happen on other browsers, or is it a Safari-specific problem?
Trying out the Tilt integration for the first time in a long, long time. Seems much improved so far vs last time.
At this point I think there’s there’s 2 important features it’d take to make my TiltPi redundant:
- A calibration UI
- Ability to log to Brewfather
I’ll make an issue for it, but it’s likely to be part of a minimalistic standalone UI for the tilt service.
For technical reasons, two-way communication between the tilt service and the main UI is somewhat limited.
This is in progress as part of a third-party integration at GitHub - astephon88/brewblox-brewfather-uploader
It works properly on Chrome for ios.
That is a bit odd, given that Chrome on iOS is forced to use the same rendering engine as Safari.
I’ve been tinkering with running MacOS in a VM lately, and will have a look at reproducing the issue.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.