Closed CodeFinder2 closed 1 year ago
Same problem here (after update)
Same problem here. I’m using MISCALE_VERSION: 1
Same problem here:
Configuration (redacted => ***** or
HCI_DEV: hci0
BLUEPY_PASSIVE_SCAN: true
MISCALE_MAC: <MISCALE_MAC>
MISCALE_VERSION: 2
MQTT_PREFIX: miscale
MQTT_HOST: 192.168.1.2
MQTT_USERNAME: *****
MQTT_PASSWORD: "*****"
MQTT_PORT: 1883
MQTT_RETAIN: true
MQTT_DISCOVERY: true
MQTT_DISCOVERY_PREFIX: homeassistant
MQTT_TLS_CACERTS: Path to CA Cert File
MQTT_TLS_INSECURE: false
TIME_INTERVAL: 5
USERS:
- NAME: *****
SEX: *****
GT: *****
LT: *****
HEIGHT: *****
DOB: "*****"
Scale:
Device running Home Assistant:
AddOn Log:
-------------------------------------
2022-10-03 10:51:51 - Starting Xiaomi mi Scale...
2022-10-03 10:51:51 - Loading Config From Add-On Options...
2022-10-03 10:51:51 - Config Loaded...
-------------------------------------
2022-10-03 10:51:51 - Initialization Completed, Waiting for Scale...
Hassio Log:
2022-10-03 10:51:00.302 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /addons/79ff755f_xiaomi_mi_scale/stats - Can't read stats from addon_79ff755f_xiaomi_mi_scale: Expecting value: line 1 column 1 (char 0)
or:
2022-10-03 11:03:21.792 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /addons/79ff755f_xiaomi_mi_scale/stats - Container addon_79ff755f_xiaomi_mi_scale is not running
HCI:
10:56:52 › hcitool dev
Devices:
hci0 <HCI0_MAC>
HCI lescan:
11:02:41 › sudo hcitool lescan | grep "<MISCALE_MAC>"
<MISCALE_MAC> (unknown)
<MISCALE_MAC> MI SCALE2
<MISCALE_MAC> (unknown)
<MISCALE_MAC> MI SCALE2
Maybe related problems:
hcitool lescan
sometimes does not work with the new adapter, workaround: hci0 down, hci0 up, restart bluetooth serviceSame problem here. I’m using MISCALE_VERSION: 2
Scale:
Name: Mi Body Composition Scale 2 Model: XMTZC04HM Device running Home Assistant:
Linux (debian 10) Server with Hassio Docker USB Bluetooth Adapter Dongle Addon Version: 0.3.1
There are issues with the add-on specifically unfortunately (working fine on the stand-alone container). Investigating...
There are issues with the add-on specifically unfortunately (working fine on the stand-alone container). Investigating...
If you need any help to investigate or debug, please do not hesitate to reach out!
If you need any help to investigate or debug, please do not hesitate to reach out!
Think I've just figured out why. Combination of github sync fail and missing option for the add-on. About to publish latest revision which should fix the issue
Can't install lolouk44/xiaomi-mi-scale-ha-add-on:0.3.2: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=0.3.2&fromImage=lolouk44%2Fxiaomi-mi-scale-ha-add-on&platform=linux%2Farm64: Not Found ("manifest for lolouk44/xiaomi-mi-scale-ha-add-on:0.3.2 not found: manifest unknown: manifest unknown")
Can't install lolouk44/xiaomi-mi-scale-ha-add-on:0.3.2
it's being built (see here), give it 10-15 min
0.3.2 is now ready. Please let me know if you have issues. The only thing I could not implement following the move away from bluepy to bleak was passive scanning. I'm hoping it's not an issue since bleak is way more stable.
I'm receiving this error.
2022-10-03 14:01:51 - Initialization Completed, Waiting for Scale... ERROR:root:A message handler raised an exception: '0000181b-0000-1000-8000-00805f9b34fb'. Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/dbus_fast/message_bus.py", line 745, in _process_message result = handler(msg) File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/manager.py", line 798, in _parse_msg self._run_advertisement_callbacks( File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/manager.py", line 843, in _run_advertisement_callbacks callback(device_path, device.copy()) File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/scanner.py", line 260, in _handle_advertising_data self._callback(device, advertisement_data) File "/opt/miscale/Xiaomi_Scale.py", line 284, in callback data = binascii.b2a_hex(advertising_data.service_data['0000181b-0000-1000-8000-00805f9b34fb']).decode('ascii') KeyError: '0000181b-0000-1000-8000-00805f9b34fb' ERROR:root:A message handler raised an exception: '0000181b-0000-1000-8000-00805f9b34fb'.
It's a RPi 4 8GB, Mi Scale model is XMTZC01HM. Any idea?
config:
HCI_DEV: hci0 BLUEPY_PASSIVE_SCAN: false MISCALE_MAC: 00:00:00:00:00:00 MISCALE_VERSION: 1 MQTT_PREFIX: miScale MQTT_HOST: 192.168.0.1 MQTT_USERNAME: MQTT_PASSWORD: "" MQTT_PORT: 1883 MQTT_RETAIN: true MQTT_DISCOVERY: true MQTT_DISCOVERY_PREFIX: homeassistant MQTT_TLS_CACERTS: Path to CA Cert File MQTT_TLS_INSECURE: false TIME_INTERVAL: 30 USERS:
2022-10-03 14:01:51 - Initialization Completed, Waiting for Scale... ERROR:root:A message handler raised an exception: '0000181b-0000-1000-8000-00805f9b34fb'.
I'm getting the exact same error.
@jgalerap @MariusHerget do you both have a V1 scale?
@jgalerap @MariusHerget do you both have a V1 scale?
I have a v1, YES.
@MariusHerget seems to have a V2. See this comment https://github.com/lolouk44/hassio-addons/issues/63#issuecomment-1265165058
Do me a favour, create a new issue asking for V1 support. Bleak works differently than bluepy used to and not sure what data is actually sent and under what service on a V1 scale, so I'll need your help toubleshooting this....
Thanks for taking a look at this so quickly!
Unfortunately, it still doesn't work. It remains started now ( :-) ) but it does not seem to be able to read from my scale. At least, HA does not show any updates once I step on my scale. Should the log contain entries if it reads successfully?
My log still contains the same output (also restarted the Addon, BLUEPY_PASSIVE_SCAN
was always disabled):
-------------------------------------
2022-10-03 14:19:58 - Starting Xiaomi mi Scale...
2022-10-03 14:19:58 - Loading Config From Add-On Options...
2022-10-03 14:19:58 - Config Loaded...
-------------------------------------
2022-10-03 14:19:58 - Initialization Completed, Waiting for Scale...
Edit: I am not sure if the addon successfully connected to my MQTT broker (altthough it should since I haven't changed anything and it worked previously). Maybe it is a good idea to emit a log entry once connected successfully?
@MariusHerget are you running the script on a RPi? If so are you ableto try and use the built-in bluetooth?
@MariusHerget are you running the script on a RPi? If so are you ableto try and use the built-in bluetooth?
I am running on a hassio docker on a 22.04 ubuntu server on an old thinkpad. My built-in bluetooth is not reliable anymore but I can reactivate it to check if this helps.
EDIT: my log from the addon docker container:
ERROR:root:A message handler raised an exception: '0000181b-0000-1000-8000-00805f9b34fb'.
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/dbus_fast/message_bus.py", line 745, in _process_message
result = handler(msg)
File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/manager.py", line 798, in _parse_msg
self._run_advertisement_callbacks(
File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/manager.py", line 843, in _run_advertisement_callbacks
callback(device_path, device.copy())
File "/usr/local/lib/python3.9/site-packages/bleak/backends/bluezdbus/scanner.py", line 260, in _handle_advertising_data
self._callback(device, advertisement_data)
File "/opt/miscale/Xiaomi_Scale.py", line 284, in callback
data = binascii.b2a_hex(advertising_data.service_data['0000181b-0000-1000-8000-00805f9b34fb']).decode('ascii')
KeyError: '0000181b-0000-1000-8000-00805f9b34fb'
``
@CodeFinder2 The issue was the missing dbus sharing from HA to the add-on (required for bleak to work) MQTT is only connected to when sending a new measure, it's not connected otherwise. So you should see a log entry before and after trying to connect to the MQTT Broken when weight is received. Can you try and get the batteries out and back in to reset the scale, then steo on the scale to see if you get anything?
I am running on a hassio docker on a 22.04 ubuntu server on an old thinkpad. My built-in bluetooth is not reliable anymore but I can reactivate it to check if this helps.
Make sure your container has the dbus shared else it won't work. Typically with this in a docker-compose file:
volumes:
- /var/run/dbus/:/var/run/dbus/:ro
@jgalerap what's your setup? This may be useful for you too,
@CodeFinder2 The issue was the missing dbus sharing from HA to the add-on (required for bleak to work) MQTT is only connected to when sending a new measure, it's not connected otherwise. So you should see a log entry before and after trying to connect to the MQTT Broken when weight is received. Can you try and get the batteries out and back in to reset the scale, then steo on the scale to see if you get anything?
Did that, no success. Removed and re-inserted batteries (scale "rebooted"). Restarted the addon, just to be sure. No new entries in the log, no new measurements in MQTT (also used MQTT Explorer to avoid issues related to HA).
On my RPi, I am also able to scan and see the device (even did a sudo systemctl restart bluetooth.service
):
$ sudo hcitool lescan
LE Scan ...
5C:XX:XX:XX:XX:XX MIBFS
...
Edit: I am using the supervised installation, so messing around with docker-compose files shouldn't be necessary for me, correct? :-D
I am using the supervised installation, so messing around with docker-compose files shouldn't be necessary for me, correct?
what's your setup? if you're running a supervisor installation from a docker container (e.g. not running HA OS on a SD in a RPi), you will need to mount the dbus volume on your main container so it's accessible in HA, the supervisor will then share it automatically with the add-on
volumes:
- /var/run/dbus/:/var/run/dbus/:ro
I am running on a hassio docker on a 22.04 ubuntu server on an old thinkpad. My built-in bluetooth is not reliable anymore but I can reactivate it to check if this helps.
Make sure your container has the dbus shared else it won't work. Typically with this in a docker-compose file:
volumes: - /var/run/dbus/:/var/run/dbus/:ro
@jgalerap what's your setup? This may be useful for you too,
I'm using HA SO running in a Raspberry PI4 on a SD Card.
I'm running it like the official guides suggests: https://www.home-assistant.io/installation/linux
Hence never had a docker-compose file or added the dbus to the volumes. Never had a problem so far. I will look into it!
I am using the supervised installation, so messing around with docker-compose files shouldn't be necessary for me, correct?
what's your setup? if you're running a supervisor installation from a docker container (e.g. not running HA OS on a SD in a RPi), you will need to mount the dbus volume on your main container so it's accessible in HA, the supervisor will then share it automatically with the add-on
I am running Debian 10 on a Raspberry Pi 4B from an SSD and installed "Home Assistant Supervised" according to this repo: https://github.com/home-assistant/supervised-installer
So no HA OS. Let me know if you need more information. I was also never writing/configuring any docker files so far.
Thanks for your support again! :-)
PS: Problem occurred after the recent update to 0.3.0 (IIRC).
I'm running it like the official guides suggests: https://www.home-assistant.io/installation/linux
Hence never had a docker-compose file or added the dbus to the volumes. Never had a problem so far. I will look into it!
You don't need docker-compose, but youl'll need to add a parameter to your docker run command:
-v /var/run/dbus/:/var/run/dbus/:ro
volumes:
- /var/run/dbus/:/var/run/dbus/:ro
I am running on a hassio docker on a 22.04 ubuntu server on an old thinkpad. My built-in bluetooth is not reliable anymore but I can reactivate it to check if this helps.
Make sure your container has the dbus shared else it won't work. Typically with this in a docker-compose file:
volumes: - /var/run/dbus/:/var/run/dbus/:ro
@jgalerap what's your setup? This may be useful for you too,
I'm using HA SO running in a Raspberry PI4 on a SD Card.
Do me a favour please and create a new issue please as I want to track V1 separately. I very much doubt your issue is dbus related since you're using HA OS on a Pi. It'll also help me ensure I don't get mixed up with the other comment already here 😉
volumes:
- /var/run/dbus/:/var/run/dbus/:ro
I am running on a hassio docker on a 22.04 ubuntu server on an old thinkpad. My built-in bluetooth is not reliable anymore but I can reactivate it to check if this helps.
Make sure your container has the dbus shared else it won't work. Typically with this in a docker-compose file:
volumes: - /var/run/dbus/:/var/run/dbus/:ro
@jgalerap what's your setup? This may be useful for you too,
I'm using HA SO running in a Raspberry PI4 on a SD Card.
Do me a favour please and create a new issue please as I want to track V1 separately. I very much doubt your issue is dbus related since you're using HA OS on a Pi. It'll also help me ensure I don't get mixed up with the other comment already here 😉
Done, bug for v1 is already created, but @MariusHerget and I, both have the same stack trace, with the exact same error on different setups and we own different models, I'm on a V1 and @MariusHerget is on a v2
@CodeFinder2 Are you sure your BT Dongle is on HCI0? On a Pi HCI0 is normally the built in bluetooth... Just trying to make sure I'm not overseeing anything
Done, bug for v1 is already created, but @MariusHerget and I, both have the same stack trace, with the exact same error on different setups and we own different models, I'm on a V1 and @MariusHerget is on a v2
Thanks, appreciated. I know you and @MariusHerget have the same error message, but it may not be related, it just means the data I'm after is not available, which could be linked to message with specific service number not there, or no BT at all 😉
@CodeFinder2 Are you sure your BT Dongle is on HCI0? On a Pi HCI0 is normally the built in bluetooth... Just trying to make sure I'm not overseeing anything
Yeah, yeah, good question! I disabled the internal bluetooth (some for WiFi) via dtoverlay=disable-bt
in /boot/config.txt
because it had weak reception.
There's just one device on hci0
and that must be my BT dongle:
$ hciconfig -a
hci0: Type: Primary Bus: UART
BD Address: DC:XX:XX:XX:XX:XX ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:12961555 acl:0 sco:0 events:1066544 errors:0
TX bytes:10770033 acl:0 sco:0 commands:966791 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: 'home'
Class: 0x0c0000
Service Classes: Rendering, Capturing
Device Class: Miscellaneous,
HCI Version: 5.0 (0x9) Revision: 0x156
LMP Version: 5.0 (0x9) Subversion: 0x6119
Manufacturer: Cypress Semiconductor Corporation (305)
I'm running it like the official guides suggests: https://www.home-assistant.io/installation/linux Hence never had a docker-compose file or added the dbus to the volumes. Never had a problem so far. I will look into it!
You don't need docker-compose, but youl'll need to add a parameter to your docker run command:
-v /var/run/dbus/:/var/run/dbus/:ro
@lolouk44 okay after destroying and recovering my hassio installation I found the following:
root@79ff755f-xiaomi-mi-scale:/var/run/dbus# dbus-monitor --system
signal time=1664812852.364811 sender=org.freedesktop.DBus -> destination=:1.200 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.200" signal time=1664812852.364844 sender=org.freedesktop.DBus -> destination=:1.200 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.200" signal time=1664812852.384643 sender=:1.6 -> destination=(null destination) serial=XX path=/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged string "org.bluez.Device1" array [ dict entry( string "RSSI" variant int16 -96 ) ] array [ ]
[...]
- I receive still the same error message
- Here are some bluetotth logs when I stepped on my scale with my hands (~30kg):
"/org/bluez/hci0/dev_
and
{
"name": "MI SCALE2",
"address": "<MISCALE_MAC>",
"rssi": -64,
"manufacturer_data": {
"343": {
"__type": "<class 'bytes'>",
"repr": "b'\\xc8G\\x8c\\xaaiJ'"
}
},
"service_data": {
"0000181d-0000-1000-8000-00805f9b34fb": {
"__type": "<class 'bytes'>",
"repr": "b'\\xa2\\x94\\x16\\xe6\\x07\\n\\x03\\x10\\r\\x08'"
}
},
"service_uuids": [
"0000181d-0000-1000-8000-00805f9b34fb"
],
"source": "hci0",
"device": {
"__type": "<class 'bleak.backends.device.BLEDevice'>",
"repr": "<MISCALE_MAC>: MI SCALE2"
},
"advertisement": {
"__type": "<class 'bleak.backends.scanner.AdvertisementData'>",
"repr": "AdvertisementData(local_name='MI SCALE2', manufacturer_data={343: b'\\xc8G\\x8c\\xaaiJ'}, service_data={'0000181d-0000-1000-8000-00805f9b34fb': b'\\xa2\\x94\\x16\\xe6\\x07\\n\\x03\\x10\\r\\x08'}, service_uuids=['0000181d-0000-1000-8000-00805f9b34fb'])"
},
"connectable": true,
"time": 6362.046859985
},
Thanks @MariusHerget and @jgalerap. I know what the issue is and you'll be glad to know it's not your fault 😄 I'll try and fix it later tonight.
Thanks @MariusHerget and @jgalerap. I know what the issue is and you'll be glad to know it's not your fault 😄 I'll try and fix it later tonight.
You are a hero! Thanks :)
(And thanks for indirectly forcing me to test my backup and recovery structure. Found some flaws 😅)
@MariusHerget your issue is the same as @jgalerap, You actually have a V1 scale. I've just pushed an update (0.3.3) which is being built and should be ready in about 10-15 min.
@lolouk44 please elaborate - Everywhere I look (e.g. Zepp Life App) or search the model number it says "Mi Smart Scale 2". Is it just a dumb naming schema or am I missing something?
and btw: thanks for helping us out so quickly!
@MariusHerget Xiaomi have a weird way of naming their scales. They have ( to my knowledge) released 4 scales, 2 x V1, 2 x V2. What's generally considered a V2 scale is the Body Composition Scale (the one that reads impedance via metal pads). You have the 2nd model of the V1 range.
v0.3.3 is working fine for me, thank you SO MUCH! :-)
Closing this now. :-)
Hi
I still have this issue.
Tried both HC0 and HC1 (I have raspberry pi and one external dongle)
My Log :
Xiaomi Mi Scale
2022-10-09 08:13:44 - Initialization Completed, Waiting for Scale...
Describe the bug Add-on starts but terminates immediately. Does not seem to detect my scale (not sure if it does, see log below). Also tried with
BLUEPY_PASSIVE_SCAN
set totrue
without success. I've set theMISCALE_VERSION
to2
.This is my config:
To Reproduce Reproducible by (re-)starting the addon. Unfortunately, there are no errors and there seems to be no logging scheme that prints more (no "verbose" option). If I refresh the addon page in HA, it says "Start" again (indicating that it has terminated).
Expected behaviour I expect that it remains started and "searches" for the scale.
Scale:
Device running Home Assistant:
Additional context Here's the log:
Please let me know if you need more information or if there's something where I can help you with. :-)
Edit: My bluetooth device seems to be detected fine: