Neues Modul: EQ3 Bluetooth Thermostat (10_EQ3BT)

Begonnen von dominik, 12 November 2016, 11:45:15

Vorheriges Thema - Nächstes Thema

dominik

Aktuell nicht. Da muss ich noch ziemlich viel umbauen damit das möglich ist.

Hintergrund: Es ist nicht sinnvoll, dass für jedes Device ein Scan läuft. Bin mir gar nicht sicher, ob mehrere Scans auf einem Hardware Device überhaupt unterstützt werden. Daher müsste ich einen zentralen Scanprozess bauen, der entweder immer läuft oder eben alle X Sekunden automatisch angestoßen wird. Dort können dann die einzelnen Devices die aktuellen rssi Werte abholen.
Das ist ein Thema was ich beim Umbau vom ble_presence Modul umsetzen werde. Das läuft nämlich aktuell noch auf bluepy und muss auch noch auf bleak migriert werden.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

F_Klee

RSSI funktioniert. Wie ich gesehen habe wird der Wert dann, wenn das Thermostat nicht "connected" ist, regelmäßig aktualisiert. Prima Sache für meine Tests. Dabei habe ich festgestellt, dass die Reichweite trotz externer Antenne alles andere als berauschend ist. Bei Werten um -70dB (schwankt um +-5dB) connected das Thermostat nicht. Da werden wohl eine Menge Peers fällig  :o

dominik

Wenn es nicht gleich connected, einfach ein paar Minuten warten....teilweise braucht es etwas Zeit für den 1. Aufbau.

Ich habe bei mir ein Thermostat mit rssi -89 problemlos verbunden (der dauert bei der 1. Verbindung manchmal 30min oder so). Es verliert zwar manchmal die Verbindung, die baut sich dann aber innerhalb weniger Sekunden gleich wieder auf. Alles mit RPi internen BT.
Die anderen Thermostate liegen bei mir zwischen -70 und -77 und sind über einen billigen USB BT Adapter (diese ganz kleinen) angebunden.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

F_Klee

Danke für die Info. Ich habe zwar länger gewartet, eine halbe Stunde war es aber nicht. Werde ich mal testen.

mayonezo

#724
Ich habe jetzt endlich alle Thermostate wieder verbinden können. Neustart des Raspi hatte nichts gebracht, aber die folgenden Befehle:

hciconfig hci0 down
rmmod btusb
modprobe btusb
hciconfig hci0 up

Quelle: https://unix.stackexchange.com/questions/602730/bluetooth-intermittently-disconnects/602739#602739

Scheint da wohl ab und zu Schluckauf zu geben. Ich schaue mal, wie lange das jetzt so läuft.

Hier auch noch die RSSI Werte:

Arbeitszimmer_Thermostat:rssi -80 2023-02-03 14:57:13
Kinderzimmer_Thermostat:rssi -75 2023-02-03 14:57:53
Wohnzimmer_Thermostat_Gross:rssi -64 2023-02-03 14:57:33
Wohnzimmer_Thermostat_Klein:rssi -127 2023-02-03 14:57:03

Bis auf Thermostat_Klein passt die Reihenfolge der Entfernungen zum USB-Dongle. Bei Thermostat_Klein habe ich schon länger die Vermutung, dass da ein Hardwarefehler vorliegt. Auch das werde ich nun beobachten.
@F_Klee Danke, dass du um die RSSI Werte gebeten hast und natürlich
@dominik vielen Dank für die gewohnt flotte Implementierung!

EDIT: Mit Thermostat_Klein ist alles in Ordnung, mittlerweile zeigt es mir bessere Werte an. Aber die Akkus waren schon fast leer, die habe ich jetzt noch getauscht.

mayonezo

So, ich habe mich gestern Nacht dazu entschieden BlueZ auf die neueste Version 5.66 zu bringen. Version 5.55 scheint ja nicht so der Bringer zu sein.

Die Debian Bookworm Version konnte ich nicht nehmen, weil es mir sonst alle möglichen Dependencies zerschossen hätte. Ich habe es dann nach einer Schritt für Schritt Anleitung selbst kompiliert, was recht einfach ging. Bisher läuft alles stabil, drückt mir die Daumen!  ;)

F_Klee

Wow, ich ziehe den Hut. Wenn ich so etwas lese komme ich mir mit meinen Kenntnissen richtig klein vor.

Ich habe meine Teststellung mittlerweile auf drei Thermostate über zwei Peers erweitert. Mit dem B+ mit Dongle komme ich bei einem Abstand von ca. 1m auf -64 (dient aber nur zu Experimenten). Mein RockPi Zero mit Stabantenne (+5dB) versorgt die beiden anderen jeweils durch eine Wand, einmal mit etwa 2m, das zweite mit etwa 6m Abstand. Beim zweiten ist die Antennenausrichtung äußerst wichtig. Den Stab flach gelegt und mit der Seite Richtung Thermostat steht die Verbindung (bei -67). Das ist bei mir aber die äußerste Grenze. Darüber hinaus geht es nicht. Über bluetoothctl sieht man regelmäßig ein "connected: yes" gefolgt von einem "connected: no". Vielleicht mache ich ja noch etwas falsch oder die Umgebung hier ist so verseucht, dass man etwas mehr Power für eine sichere Verbindung benötigt. Bei mir im Haus ist aber mit Sicherheit weniger los. Bin also noch optimistisch  ;)

denis.robel

#727
@Dominik

Eine Frage: wie ist das bei fhempy, wenn ich mehrere USB Dongles an einem Raspi betreibe, ist das Pairing abhängig vom USB-BT Device?

Beim alten EQ3B-Modul hat sich das Modul immer gekümmert und ein verfügbares USB-BT Device ausgewählt, aber da gabs noch kein Pairing ...

Sprich wenn ein Thermostat mit hci0 gepaired wurde, geht es nicht mit hci1?
VG

Denis

dominik

Das ist egal. Einmal gepaired kümmert sich fhempy um die Verbindung. Es wechselt die hci Devices immer durch und man muss nix konfigurieren.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

denis.robel

ok danke. Ich war mir nicht ganz sicher, ob das noch so funktioniert.
VG

Denis

F_Klee

Hallo Dominik,
du betreust ja eine Menge Module. Solltest du aber trotzdem Langeweile haben, so hätte ich noch eine Idee  ;D
Die Thermostate haben ja einen Wochenplan eingebaut, den man zwar auslesen, mit dem Modul aber nicht beschreiben kann. Das Problem bei einem Wochenplanmodul für eq-3 dürfte das UI sein. Vielleicht wäre es ja möglich, ein Modul zu schreiben, dass sich auf User-Seite so verhält wie das WeekdayTimer-Modul von FHEM. Dann könnte man es auch mit dem wdtimer-Widget von TabletUI steuern. Das Modul würde dann den Wochenplan entgegen nehmen, in das Format von eq-3 wandeln und über das Modul eq3bt an das Thermostat senden. Einfach mal so in den Raum geworfen.

Ich selbst habe das WeekdayTimer-Modul für die Steuerung eingerichtet. Kleiner Haken: Sollte zum Umschaltzeitpunkt das Thermostat nicht connected sein, so bekommt es scheinbar nichts davon mit. Gibt es da keine Warteschlange?

Die Idee ist eben auch, dass die Thermostate möglichst autark arbeiten sollten. Dann muss nur valvePosition ab und zu aktualisiert werden. Es macht dann auch nichts, wenn die Verbindung häufiger weg ist.

Gruß
Frank

dominik

Hi Frank,

Langeweile? Das kenne ich nicht ;)

Eigentlich sollte das Thermostat dauerhaft connected sein, wenn nicht, ist die Distanz vielleicht ein Stück zu groß. Eine richtige Warteschlange gibt es nicht, das wäre etwas zu kritisch. Weil wenn du auf 12 Grad stellst und die Verbindung erst um 8 Uhr Früh wieder aufgebaut wird, wird wahrscheinlich eine zuvor anders gesetzte Temperatur überschrieben. Daher wird bei jedem Befehl nur max. 30s auf eine Verbindung gewartet. Wenn keine Verbindung in dieser Zeit zustande kommt, dann wird der Befehl verworfen.

Wegen Wochenplan: Generell eine gute Idee, nur würde mir das in der Implementierung aktuell wirklich zu viel Zeit kosten sich da genau einzulesen. Ich glaube da warte ich auf den nächsten Winter ;) Sorry, aber im Moment stehen noch paar andere Themen an die ich implementieren möchte.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

F_Klee

War von mir auch nur erst einmal in den Raum geworfen. Meine Mieterin hat keinen NineToFive-Job und stellt die Thermostate je nach aktuellem Bedarf. Auch eine automatische Nachtabsenkung nutzt sie nicht. Den WeekdayTimer habe ich nur der Vollständigkeit halber eingebaut und weil ich aktuell ja noch lerne und teste.

Das mit dem zu großen Abstand habe ich schon befürchtet. Der Rock Pi S, den ich gerade als günstigen und lieferbaren Peer ausprobiere, will noch nicht mit eq3bt. Es gibt da eine lange Fehlermeldung in STATE:
Module failed to load: eq3bt
Maybe you need to update fhempy on this or remote peer.

Stacktrace:
Traceback (most recent call last):
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/fhem_pythonbinding.py", line 332, in handle_function
    module_object = await self.import_module(hash)
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/fhem_pythonbinding.py", line 538, in import_module
    functools.partial(importlib.import_module, pymodule)
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/utils.py", line 72, in run_blocking
    return await asyncio.get_event_loop().run_in_executor(pool, function)
  File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/eq3bt/eq3bt.py", line 7, in <module>
    from . import eq3btsmart as eq3
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/eq3bt/eq3btsmart.py", line 32, in <module>
    from ..core import bluetoothle
  File "/home/pi/.local/lib/python3.7/site-packages/fhempy/lib/core/bluetoothle.py", line 7, in <module>
    import bluetooth_adapters
ModuleNotFoundError: No module named 'bluetooth_adapters'

Dir sagt das bestimmt mehr als mir. Der Pi S ist sehr klein und nutzt ein sehr abgespecktes Linux Buster. Bluetooth selbst funktioniert und das Thermostat ist gepaired. Es kann natürlich sein, dass da trotzdem etwas fehlt und nachinstalliert werden muss. Nur was?

Momentan bin ich aber mit der Restaurierung eines anderen SmartHome-Servers beschäftigt, dessen Festplatte sich verabschiedet hatte. Das nötigste läuft, aber es wartet noch viel Arbeit auf mich.

dominik

Uij, Linux buster ist wirklich keine gute Idee. Mach bitte gleich ein Update auf bullseye. Bluetooth wird mit buster nicht supported, da es Python 3.9 erfordert welches mit bullseye geliefert wird.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

F_Klee

Leider nicht so einfach. Der SoC des Pi S ist letztes Jahr verändert worden. Für den neuen gibt es ein Armbian bullseye. Ich habe aber noch einen alten erwischt. Da auch die Rock Pi genau wie die Raspberry Pi von den Lieferschwierigkeiten betroffen, der Pi S aber zu bekommen ist so denke ich, dass es da noch größere Lagerbestände mit dem alten SoC gibt.

Fazit: Der Rock Pi S ist aktuell nicht zu empfehlen. Schade.