ESP32 mit Tasmota, BLE und MQTT Probleme

Begonnen von Christian72D, 22 Dezember 2021, 07:08:54

Vorheriges Thema - Nächstes Thema

Christian72D

So, auf meinem ESP32 läuft Tasmota 10.1.0, BLE ist aktiviert und die Geräte werden auch gefunden.

Jetzt das Problem, laut github sollte folgendes passieren, wenn ein Gerät nicht mehr gefunden wird:

ZitatIf the beacon can no longer be found during a scan and the timeout interval has passed the beacon's RSSI is set to zero (0) and it is no longer displayed in the webUI

Passiert bei mir nicht.

Ich habe zwei Gigaset Tags, einer am Wohnungs Schlüssel, einer am Auto Schlüssel.

Ich habe vor über 30 Minuten die Wohnung verlassen und die Readings sind wie folgt:

BLEDevices_7C2F80B9xxxx_a Wohnung 2021-12-22 06:32:28
BLEDevices_7C2F80B9xxxx_i 5 2021-12-22 06:32:28
BLEDevices_7C2F80B9xxxx_n Gigaset G-tag 2021-12-22 06:32:28
BLEDevices_7C2F80B9xxxx_r -90 2021-12-22 06:32:28
BLEDevices_7C2F80Cxxxx_a Auto 2021-12-22 07:02:28
BLEDevices_7C2F80Cxxxx_i 1 2021-12-22 07:02:28
BLEDevices_7C2F80Cxxxx_n Gigaset G-tag 2021-12-22 07:02:28
BLEDevices_7C2F80Cxxxx_r -63 2021-12-22 07:02:28


Und die default Werte fürs Scannen und "verwerfen" sind wie folgt:

Zitatu<x> = sets update interval in seconds (scan tags every <x> seconds) (default = 10)
t<x> = set timeout interval in seconds (send RSSI=0 if tag is not detected after <x> seconds) (default = 30)

Also statt den auf NULL zu setzen, wird einfach nichts mehr übertragen.

Wo setze ich jetzt an?

rudolfkoenig

Wegen dem gewaehlten Forumsbereich: soweit ich sehe, hat das Problem wenig mit MQTT zu tun.

Meine subjektive Reihenfolge: erst pruefen, ob eine Geraetekonfiguration hilft, dann ob ein Tasmota-Programm sowas machen kann und sonst in FHEM ein watchdog anlegen.

Christian72D

Was meinst du mit Tasmota Programm?

Wie gesagt, laut der github Seite ist es so:

"If the beacon can no longer be found during a scan and the timeout interval has passed the beacon's RSSI is set to zero (0) and it is no longer displayed in the webUI".

Und konfigurieren kann man an den Tasmota Settings nichts, was dieses verhalten ändern könnte.

rudolfkoenig

ZitatWas meinst du mit Tasmota Programm?
https://tasmota.github.io/docs/Scripting-Language/
Wie geschrieben, das waere _meine_ Reihenfolge.

ZitatWie gesagt, laut der github Seite ist es so:
Das mag sein, aber das wirst Du hier bei uns nicht einklagen koennen :)

rudolfkoenig


Beta-User

Zitat von: Christian72D am 22 Dezember 2021, 11:23:40
"If the beacon can no longer be found during a scan and the timeout interval has passed the beacon's RSSI is set to zero (0) and it is no longer displayed in the webUI".
Anders gesagt: Geht denn das raus, was lt. der Doku gesendet wird (zu kontrollieren über die Tasmota-Konsole auf dem Web-Interface des ESP):
https://tasmota.github.io/docs/Bluetooth_ESP32/#ibeacon
tele/ibeacon/SENSOR = {"Time":"2021-01-02T12:08:40","IBEACON":{"MAC":"A4C1387FC1E1","RSSI":-56,"STATE":"OFF"}}
Dafür (auch nicht für die Message darüber) findet sich nämlich nichts an Anhaltspunkt in deinem MQTT2_DEVICE.

Nochmal anders gesagt: FHEM kann nur verarbeiten, was in FHEM ankommt. Wenn das Gerät anders "tickt" als die Doku suggeriert, muss man dort nachhaken, wo der Code+die Doku gemacht werden, also bei Theo&Co.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Christian72D

Man sieht doch oben, was bei mir in fhem ankommt.

Das sind die betreffenden Readings aus dem MQTT Device.

Und Rules haben da überhaupt nichts mit zu tun, das ist eine grundlegende Einstellung, wie ich es oben von der Tasmota Seite zitiert habe.

Beta-User

Zitat von: Christian72D am 22 Dezember 2021, 13:04:57
Man sieht doch oben, was bei mir in fhem ankommt.
Ebend. Genau das paßt nicht zur Doku. Ergo ist die Doku falsch, und vermutlich tut auch der Code auf dem ESP nicht das, was dokumentiert ist.

Daher: Im Tasmota-Team nachfragen, ob/was geändert wurde, und was du jetzt tun sollst...

Anders gesagt: Du bist hier im FHEM-Forum falsch mit dem Wunsch, am Verhalten des ESP irgendwas zu ändern...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

ZitatMan sieht doch oben, was bei mir in fhem ankommt.
Nicht ganz, man sieht, was FHEM gespeichert hat.
Es koennte ja theoretisch(!) sein, dass die MQTT Pakete von FHEM nicht richtig interpretiert werden, weil z.Bsp. als Message ein Leerstring gesendet wird.
Oder dass json2nameValue 0-Werte ignoriert. Wie gesagt: theoretisch.

ZitatUnd Rules haben da überhaupt nichts mit zu tun, das ist eine grundlegende Einstellung, wie ich es oben von der Tasmota Seite zitiert habe.
Na wenn die Einstellung das Versprochene nicht haelt, koennte man womoeglich mit Rules ein MQTT-Paket senden, wenn Bluetooth ausbleibt.
Ich habe aber keine Ahnung, ob man beim Bluetooth-Ausbleiben ein Tasmota-Event generiert wird, und ob man per Rules MQTT Nachrichten schicken kann.

Beta-User

Zitat von: rudolfkoenig am 22 Dezember 2021, 13:15:01
Na wenn die Einstellung das Versprochene nicht haelt, koennte man womoeglich mit Rules ein MQTT-Paket senden, wenn Bluetooth ausbleibt.
Ich habe aber keine Ahnung, ob man beim Bluetooth-Ausbleiben ein Tasmota-Event generiert wird, und ob man per Rules MQTT Nachrichten schicken kann.
...vermutlich wäre das Publishen per rule nicht das Thema, wenn man einen "Anpack" hätte...

Grundsätzliche Anmerkung vielleicht:
Das Team um "Tasmota-Theo" ist sehr rührig, und es kommt immer mal wieder was neues dazu. Meistens dauert es einfach ein paar Wochen oder gar Monate, bis neue Bereiche wirklich funktional sind. Bis dahin kommt es eben zu solchen Abweichungen zwischen Anspruch und Wirklichkeit. Hatten wir jüngst erst mit dem Jalousie-Aktor - also der Erweiterung für drehbare Lamellen.

Es ist dann halt wichtig, dass die Jungs Rückmeldung bekommen, wenn etwas nicht so funktioniert wie erwartet, in der Regel wir es dann schnell gefixt (entweder in der Doku oder im Code).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Christian72D

Zitat von: Beta-User am 22 Dezember 2021, 13:21:41
Es ist dann halt wichtig, dass die Jungs Rückmeldung bekommen, wenn etwas nicht so funktioniert wie erwartet, in der Regel wir es dann schnell gefixt (entweder in der Doku oder im Code).

Ich habe schon einen Beitrag in "Discussion" gepostet, da wurde mir dann gesagt, ich solle damit in den "Chat" gehen.  :(

Christian72D


rudolfkoenig

ZitatUnd wie könnte sowas aussehen?
define wd watchdog BLEDevices_7C2F80B9xxxx_r 00:05 SAME set Chef1 abwesend
attr wd autoRestart 1


Nur als Info:
- ich wusste es auch nicht auswendig, und habe in der Doku nachgeschaut
- ungetestet