Проблемы с Lite. #7
Comments
|
Версия 1.0.0, как понимаю. Про функцию понял, проверю и поправлю. Про стабильность: как далеко у вас то что опрашивает бризер от самого бризера? Многие жалуются на стабильность связи, если расстояние "большое". Хотя первый лог довольно странный: последний пакет он все же получил. Видимо это было не очень быстро. |
|
Первая часть исправлена в v1.0.1,
Компонент использует этот модуль и все что обсуждалось там применимо и к использованию модуля без HomeAssistant. |
|
Про pair еще вопрос: для Lite использовать pair.py? У меня 2 Lite бризера, для одного использовал, но он завершается с ошибкой (видимо, потому что код для s3), и с ним худо бедно удается связаться (на логах выше), для второго не вызывал, с ним только: |
|
Протестировал, максимально поднеся raspberry к тиону (50 сантиметров), при этом убив приложение на смартфоне и немного подождав: результаты те же. |
|
Нет, для lite специальный tion-pair не нужен, но нужен обычный BT pairing. На малине можно параллельно запустиь bluetoothctl -- будет видно как модуль подключается/отключается к/от бризера. У меня пока нет идей, на тему того что происходит, кроме как проблем с радиоканалом. Но ваш эксперимент, с поднесением малины близко к бризеру, эту догадку опровергает. Можно попробовать добавить вот такую конструкцию logging.basicConfig(
format='%(asctime)s %(levelname)-8s %(message)s',
level=logging.DEBUG,
datefmt='%Y-%m-%d %H:%M:%S')вместо |
|
|
|
Повторил все в "чистых" условиях со вторым Lite: запейрил через bluetoothctl, все успешно, положил в метре - скрипт валится точно так же, и ни разу инфу до конца получить не удалось. Причем в bluetoothctl все хорошо - пейрится, коннектится и т.д. без проблем. |
|
Немного покопался в коде: |
|
_btle.waitForNotifications(1.0) -- штука которая секунду ждет, когда бризер пришлет данные по каналу уведомлений. Ваш вариант не корректен, поскольку обращение к self._data, без успешного завершения _collect_message некорректен: в _data будет или предыдущий запрос или непойми что. Я сейчас в dev залью альтернативный вариант работы с Notification, по аналогии с тем, как это было сделано для bleak. |
|
Но я как раз добавил _collect_message в случай когда "Waiting too long for data" после notify.read(). |
In #7 we faced up with bug: we have real data in notification channel, but waitForNotifications don't returns True.
|
Готово. С ps. Извиняться не нужно: вы помогаете сделать модуль лучше, за что вам спасибо. |
|
|
|
Тут что-то не так пошло с новым алгоритмом: |
|
Обновил dev. Код не обрабатывал callback'и пока находился в цикле. |
|
|
|
|
|
Решил заодно потестировать set() функцию, добавил `device.set({'fan_speed':2}) в тест. Похоже, что опечатка и должно быть |
|
В общем, с двумя этими фиксами, все работает замечательно. Я написал маленькую mqtt обвязку и счастлив, что могу наконец управлять этим добром из node-red. |
It should prevent situation when breezer don't send new data and waiting for something like in #7
|
Выложите mqtt на git, в соседний репозиторий? Под TionAPI сделаем отдельный репозиторий, на подобии python-server'a. Касательно read -- поправил основной код более корректным образом. Можете проверить что все работает правильно? На моем S3 полет нормальный, но он умещает всю информацию в один пакет. |
|
Проверил обновление - теперь все работает правильно, без проблем. Про mqtt - я набросал максимально простой сервис с paho.mqtt и захадкожеными маками моих тионов. Нужно будет его допилить до удобоваримого состояния: неизвестные модели и кол-во устройств и т.д. import json
import logging
import paho.mqtt.client as mqtt
from tion_btle.lite import Lite
logging.basicConfig(level=logging.DEBUG)
_LOGGER = logging.getLogger(__name__)
_LOGGER.setLevel("DEBUG")
mac1 = 'YOUR_DEVICE_1_MAC'
mac2 = 'YOUR_DEVICE_2_MAC'
deviceTopic1 = 'tion/'+mac1
deviceTopic2 = 'tion/'+mac2
refreshTopic1 = deviceTopic1+'/refresh'
refreshTopic2 = deviceTopic2+'/refresh'
setTopic1 = deviceTopic1+'/set'
setTopic2 = deviceTopic2+'/set'
maxTries = 3
device1 = Lite(mac1)
device2 = Lite(mac2)
client = mqtt.Client()
def on_connect(client, userdata, flags, rc):
client.subscribe(refreshTopic1)
client.subscribe(refreshTopic2)
client.subscribe(setTopic1)
client.subscribe(setTopic2)
def on_message(client, userdata, msg):
success = False
tryCount = 0
while not success and tryCount < maxTries:
if msg.topic == refreshTopic1:
try:
client.publish(deviceTopic1, json.dumps(device1.get(True)))
success = True
except Exception as e:
print(e)
elif msg.topic == refreshTopic2:
try:
client.publish(deviceTopic2, json.dumps(device2.get(True)))
success = True
except Exception as e:
print(e)
elif msg.topic == setTopic1:
try:
device1.set(json.loads(msg.payload))
client.publish(deviceTopic1, json.dumps(device1.get(True)))
success = True
except Exception as e:
print(e)
elif msg.topic == setTopic2:
try:
device2.set(json.loads(msg.payload))
client.publish(deviceTopic2, json.dumps(device2.get(True)))
success = True
except Exception as e:
print(e)
tryCount += 1
client.on_connect = on_connect
client.on_message |
|
Можно это оформить хоть в каком-то читаемом виде и закинуть в репозиторий, чтобы люди не начинали с чистого листа. А это issue я закрываю. Релиз модуля будет в ближайшее время. |
In #7 we faced up with bug: we have real data in notification channel, but waitForNotifications don't returns True.
It should prevent situation when breezer don't send new data and waiting for something like in #7
Если руками добавить лишний аргумент, то начинает работать, но как-то нестабильно: инфу получается достать примерно один из пяти раз, в остальных получаю:
или
The text was updated successfully, but these errors were encountered: