[31_PLAYBULB.pm] Modul für MiPow PLAYBULB Candle Bluetooth Lampen

[CoolTux]

Na dann brauche ich mich ja nicht zu wundern. Wo kommen denn die Aufrufe alle her?
Die müssen alle beendet werden.

[jonah]

[noob-Content:] Ich verstehe mal wieder nicht? Freue mich aber, dass es bei dir anders ist. Was soll ich machen?

[CoolTux]

Du hast noch laufende gatttool Prozesse. Wo kommen die her? Hast du noch irgendwas anderes auf?

Am besten du startest den ganzen fhem Pi Mal durch

[jonah]

Das ist wohl der Moment, in dem ich mich mit verschämt-rotem Kopf unterm Tisch verstecke. Kein Plan, wo die Prozesse aktuell herkommen, ich hab schon etwas länger rumgespielt, um die Dinger zum Laufen zu kriegen. Ups. Hab auch hin und wieder nen reboot gemacht. Sorry fürs Zeitverschwenden. Jetzt (nach einem Reboot) gibt auch die 16 nen Output:

Code Auswählen Erweitern


pi@fhem:~ $ ps ax | grep -v grep | grep "gatttool"
pi@fhem:~ $ gatttool -b 12:5A:4B:10:AC:E6 --char-read -a 0x16
Characteristic value/descriptor: 06 17 00 fb ff
pi@fhem:~ $ gatttool -b 12:5A:4B:10:AC:E6 --char-read -a 0x19
Characteristic value/descriptor: 00 00 00 00
pi@fhem:~ $ gatttool -b 12:5A:4B:10:AC:E6 --char-read -a 0x29
Characteristic value/descriptor: 02 2a 00 26 2a
pi@fhem:~ $ gatttool -b 12:5A:4B:10:AC:E6 --char-read -a 0x14
Characteristic value/descriptor: 06 15 00 fa ff


[CoolTux]

Und noch besser. Jetzt sollte hoffentlich auch fhem das ganze können

[jonah]

leider nicht. nachdem der pi wieder hochgefahren ist, lässt sich die Kerze weiterhin nicht ansteuern. Logfile sagt auf statusRequest nach ein paar Versuchen, die Farbe einzustellen, dieses hier:

Code Auswählen Erweitern

2017.10.22 21:18:54 4: (Sub PLAYBULB - Kerze2) - Call BlockingRun
2017.10.22 21:18:54 4: (Sub PLAYBULB_Run - Kerze2) - Running nonBlocking
2017.10.22 21:18:58 1: Timeout for PLAYBULB_BlockingRun reached, terminated process 815
2017.10.22 21:18:58 4: (Kerze2) - The BlockingCall Process terminated unexpectedly. Timedout
2017.10.22 21:18:58 4: (Sub PLAYBULB - Kerze2) - Call BlockingRun
2017.10.22 21:18:58 4: (Sub PLAYBULB_Run - Kerze2) - Running nonBlocking
2017.10.22 21:19:07 1: Timeout for PLAYBULB_BlockingRun reached, terminated process 840
2017.10.22 21:19:07 4: (Kerze2) - The BlockingCall Process terminated unexpectedly. Timedout
2017.10.22 21:19:07 4: (Sub PLAYBULB - Kerze2) - Call BlockingRun
grep: Schreibfehler: Datenübergabe unterbrochen (broken pipe)
2017.10.22 21:19:07 4: (Sub PLAYBULB_Run - Kerze2) - Running nonBlocking

Ich muss gleich ins Bett, würde es aber gerne ein ander Mal weiterprobieren. Danke für die freundliche Unterstützung!

[CoolTux]

Alles klar.

Kannst ja dann noch mal

Code Auswählen Erweitern


ps ax | grep -v grep | grep "gatttool"


probieren.



Gute Nacht

LG

[RaspiLED]

Hi,
dann probiere doch mal in der shell
sudo killall gatttool
und schaue dann nachmal in FHEM.
Natürlich müssen wir danach noch die Quelle Deiner gatttool Instanzen finden
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[CoolTux]

Guten Morgen. Wie gesagt eigentlich darf gar kein gatttool Prozess laufen. Das ist es ja was mich so wundert. Aber wenn einer läuft, dann kill und Mal bitte mit FHEM ein statusRequest machen.

[kurt6908]

Hallo,

ich habe ja auch das Problem mit dem gatttool (siehe einige Posts vorher) und konnte das Verhalten mit dem laufenden Prozess nachvollziehen:

- ein "statusrequest" beendet den gatttool-Prozess sauber, dann wird auch der Status in FHEM angezeigt
- ein "set" sonstwas erzeugt zwei gatttool-Prozesse, einen ohne "-n" und einen mit "-n". Der zweite gatttool-Prozess mit "-n" bleibt dann aber stehen und wird nicht beendet, der FHEM-Set erzeugt dann ein "unreachable".
- ein kill gatttool beendet diesen zweiten Prozess
- und dann geht auch wieder ein "statusrequest"

Was ich nicht nachvollziehen konnte, ist das ein wiederholtes "set" mehrere gatttool-Prozesse erzeugt, bei mir bleibt immer nur einer stehen.

Vielleicht hilft es weiter und löst auch mein Problem, wobei ich glaube, es ist das gleiche ...

Gruß

Kurt

[jonah]

Danke schonmal für die Rückmeldungen. Ich komme jetzt erst dazu, hier etwas ausführlicher zu antworten.

Ich schreibe jetzt mal parallel zu meinen Versuchen. Um sicherzustellen, dass alle irgendwann mal eingerichteten Bluetooth-Versuche gekillt werden deinstalliere ich alle Bluetooth-verwandten Pakete am Pi:

Code Auswählen Erweitern

sudo apt-get purge blueman bluetooth pi-bluetooth bluez
Nach einem Reboot installiere ich sie neu:

Code Auswählen Erweitern

sudo apt-get install blueman bluetooth pi-bluetooth bluez
Nach einem erneuten Restart überprüfe ich Bluetooth mit sudo bluetoothctl, es erscheint folgende Ausgabe:

Code Auswählen Erweitern

pi@fhem:~ $ sudo bluetoothctl
[NEW] Controller 00:1A:7D:DA:71:0B fhem [default]
[bluetooth]#
Ein gatttool-Prozess scheint auch nicht zu laufen:

Code Auswählen Erweitern

pi@fhem:~ $ ps ax | grep -v grep | grep "gatttool"
pi@fhem:~ $

Irgendetwas scheint beim Bluetooth-Status aber noch nicht ganz astrein zu sein, aber der Service läuft wohl:

Code Auswählen Erweitern

pi@fhem:~ $ sudo /etc/init.d/bluetooth status
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-10-25 09:34:27 CEST; 4min 25s ago
     Docs: man:bluetoothd(8)
Main PID: 867 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─867 /usr/lib/bluetooth/bluetoothd

Okt 25 09:34:26 fhem systemd[1]: Starting Bluetooth service...
Okt 25 09:34:26 fhem bluetoothd[867]: Bluetooth daemon 5.43
Okt 25 09:34:26 fhem bluetoothd[867]: Starting SDP server
Okt 25 09:34:26 fhem bluetoothd[867]: Bluetooth management interface 1.14 initialized
Okt 25 09:34:26 fhem bluetoothd[867]: Failed to obtain handles for "Service Changed" ch...istic
Okt 25 09:34:26 fhem bluetoothd[867]: Sap driver initialization failed.
Okt 25 09:34:26 fhem bluetoothd[867]: sap-server: Operation not permitted (1)
Okt 25 09:34:27 fhem systemd[1]: Started Bluetooth service.
Hint: Some lines were ellipsized, use -l to show in full.

Ein Bluetooth-Scan per hcitool scan listet mein Telefon und das einer Nachbarin. Ein LE-Scan liefert eine lange Liste, in der die PLAYBULBS auftauchen:

Code Auswählen Erweitern

pi@fhem:~ $  sudo hcitool lescan
LE Scan ...
AC:E6:4B:07:B5:E8 (unknown)
AC:E6:4B:07:B5:E8 PLAYBULB CANDLE
AC:E6:4B:05:26:CF (unknown)
AC:E6:4B:05:26:CF PLAYBULB CANDLE
AC:E6:4B:07:A4:BE (unknown)
AC:E6:4B:07:A4:BE PLAYBULB CANDLE
AC:E6:4B:07:B5:E8 (unknown)
AC:E6:4B:05:26:CF (unknown)
AC:E6:4B:07:A4:BE (unknown)
AC:E6:4B:07:A4:BE PLAYBULB CANDLE
AC:E6:4B:05:26:CF (unknown)
AC:E6:4B:05:26:CF PLAYBULB CANDLE
12:5A:4B:10:AC:E6 (unknown)
12:5A:4B:10:AC:E6 PLAYBULB CANDLE
...

Ich unterbreche den Scan mit strg+c.

In fhem sind die Kerzen mit den MAC-Adressen angelegt. Nach einem shutdown restart (sicherheitshalber) ist der Status der Kerzen in der Kerzen-Übersichtsseite erst unknown, nach ein paar Sekunden wird tatsächlich erkannt, dass sie gerade alle an sind (sichtbar durch die orangene Glühbirne rechts neben den Device-Namen).
Zur weiteren Diagnose setze ich global auf verbose 5.
Wenn ich nun auf Kerze1 gehe und dort im Farb-Fenster rechts neben dem Birnensymbol klicke, um die Farbe zu verändern, veränder sich der state der Kerze1 innerhalb von ca. 2sec auf unreachable. Im Logfile steht folgendes:

Code Auswählen Erweitern


2017.10.25 09:59:01 5: Cmd: >set Kerze1 rgb fb4c17<
2017.10.25 09:59:01 4: BlockingCall (PLAYBULB_BlockingRun): created child (695), uses telnetForBlockingFn_1508918239 to connect back
2017.10.25 09:59:01 4: (Sub PLAYBULB - Kerze1) - Call BlockingRun
2017.10.25 09:59:01 5: Starting notify loop for Kerze1, 1 event(s), first is rgb fb4c17
2017.10.25 09:59:01 5: createNotifyHash
2017.10.25 09:59:01 5: End notify loop for Kerze1
2017.10.25 09:59:01 4: WEB: /fhem?cmd=set%20Kerze1%20rgb%20fb4c17&XHR=1&fwcsrf=csrf_757658735086775&fw_id=34 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 09:59:01 4: Connection accepted from telnetForBlockingFn_1508918239_127.0.0.1_57924
2017.10.25 09:59:01 5: Cmd: >{BlockingRegisterTelnet($cl,5)}<
2017.10.25 09:59:01 4: (Sub PLAYBULB_Run - Kerze1) - Running nonBlocking
2017.10.25 09:59:02 1: PERL WARNING: substr outside of string at ./FHEM/31_PLAYBULB.pm line 476.
2017.10.25 09:59:02 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_PLAYBULB.pm line 476.
2017.10.25 09:59:11 1: Timeout for PLAYBULB_BlockingRun reached, terminated process 695
2017.10.25 09:59:11 5: Starting notify loop for Kerze1, 1 event(s), first is unreachable
2017.10.25 09:59:11 5: End notify loop for Kerze1
2017.10.25 09:59:11 4: (Kerze1) - The BlockingCall Process terminated unexpectedly. Timedout
2017.10.25 09:59:54 4: Connection closed for WEB_192.168.178.67_57302: EOF
2017.10.25 09:59:54 4: WEB_192.168.178.67_57303 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-10.log; BUFLEN:0
Die anderen Lampen haben weiterhin den state on, wenn ich versuche, bei Kerze2 die Farbe zu ändern passiert das gleiche wie bei Kerze1.
Ein gatttool-Check zeigt, dass nun gatttool-Prozesse laufen:

Code Auswählen Erweitern

pi@fhem:~ ps ax | grep -v grep | grep "gatttool"
  717 ?        S      0:00 gatttool -b 12:5A:4B:10:AC:E6 --char-write -a 0x16 -n 06fb4c17
  776 ?        S      0:00 gatttool -b AC:E6:4B:07:A4:BE --char-write -a 0x14 -n 005bff4f03000a00
.
Jetzt versuche ich mal einen statusRequest für Kerze3, die wird ja noch als on angezeigt. Ausgabe:

Code Auswählen Erweitern

2017.10.25 10:03:49 5: Starting notify loop for Kerze3, 9 event(s), first is color: on
2017.10.25 10:03:49 5: createNotifyHash
2017.10.25 10:03:49 5: End notify loop for Kerze3
2017.10.25 10:03:49 4: (Sub PLAYBULB_Done - Kerze3) - Abschluss!
2017.10.25 10:03:59 4: Connection closed for WEB_192.168.178.67_58116: EOF
2017.10.25 10:03:59 4: WEB_192.168.178.67_58118 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-10.log; BUFLEN:0

Nach dem statusRequest hat die Lampe weiterhin den state on. Nun versuche ich wieder, die Farbe zu ändern, warte kurz und mache dann noch einen statusRequest, wenn sie unreachable ist. Ausgabe:

Code Auswählen Erweitern

2017.10.25 10:06:26 5: Cmd: >set Kerze3 rgb 8b3dff<
2017.10.25 10:06:26 4: BlockingCall (PLAYBULB_BlockingRun): created child (800), uses telnetForBlockingFn_1508918239 to connect back
2017.10.25 10:06:26 4: (Sub PLAYBULB - Kerze3) - Call BlockingRun
2017.10.25 10:06:26 5: Starting notify loop for Kerze3, 1 event(s), first is rgb 8b3dff
2017.10.25 10:06:26 5: createNotifyHash
2017.10.25 10:06:26 5: End notify loop for Kerze3
2017.10.25 10:06:26 4: WEB: /fhem?cmd=set%20Kerze3%20rgb%208b3dff&XHR=1&fwcsrf=csrf_757658735086775&fw_id=49 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 10:06:26 4: Connection accepted from telnetForBlockingFn_1508918239_127.0.0.1_57930
2017.10.25 10:06:26 5: Cmd: >{BlockingRegisterTelnet($cl,8)}<
2017.10.25 10:06:26 4: (Sub PLAYBULB_Run - Kerze3) - Running nonBlocking
2017.10.25 10:06:36 1: Timeout for PLAYBULB_BlockingRun reached, terminated process 800
2017.10.25 10:06:36 5: Starting notify loop for Kerze3, 1 event(s), first is unreachable
2017.10.25 10:06:36 5: End notify loop for Kerze3
2017.10.25 10:06:36 4: (Kerze3) - The BlockingCall Process terminated unexpectedly. Timedout
2017.10.25 10:06:41 4: WEB_192.168.178.67_58364 GET /fhem?cmd=%7BReadingsVal(%22Kerze3%22%2C%22statusRequest%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775; BUFLEN:0
2017.10.25 10:06:41 5: Cmd: >{ReadingsVal("Kerze3","statusRequest","")}<
2017.10.25 10:06:41 4: WEB: /fhem?cmd=%7BReadingsVal(%22Kerze3%22%2C%22statusRequest%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 10:06:42 4: Connection closed for WEB_192.168.178.67_58363: EOF
2017.10.25 10:06:42 4: WEB_192.168.178.67_58364 POST /fhem&detail=Kerze3&dev.setKerze3=Kerze3&fwcsrf=csrf_757658735086775&cmd.setKerze3=set&arg.setKerze3=statusRequest&val.setKerze3=; BUFLEN:0
2017.10.25 10:06:42 5: Cmd: >set Kerze3 statusRequest<
2017.10.25 10:06:42 4: BlockingCall (PLAYBULB_BlockingRun): created child (824), uses telnetForBlockingFn_1508918239 to connect back
2017.10.25 10:06:42 4: (Sub PLAYBULB - Kerze3) - Call BlockingRun
2017.10.25 10:06:42 5: Starting notify loop for Kerze3, 1 event(s), first is statusRequest
2017.10.25 10:06:42 5: End notify loop for Kerze3
2017.10.25 10:06:42 4: Connection accepted from telnetForBlockingFn_1508918239_127.0.0.1_57932
2017.10.25 10:06:42 5: Cmd: >{BlockingRegisterTelnet($cl,9)}<
2017.10.25 10:06:42 4: (Sub PLAYBULB_Run - Kerze3) - Running nonBlocking
2017.10.25 10:06:42 4: WEB_192.168.178.67_58364 GET /fhem?detail=Kerze3&fw_id=; BUFLEN:0
2017.10.25 10:06:43 4: WEB: /fhem?detail=Kerze3&fw_id= / RL:5285 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 10:06:43 4: WEB_192.168.178.67_58364 GET /fhem?cmd=%7BReadingsVal(%22Kerze3%22%2C%22sat%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775; BUFLEN:0
2017.10.25 10:06:43 5: Cmd: >{ReadingsVal("Kerze3","sat","")}<
2017.10.25 10:06:43 4: WEB: /fhem?cmd=%7BReadingsVal(%22Kerze3%22%2C%22sat%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775 / RL:22 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 10:06:43 4: Connection accepted from WEB_192.168.178.67_58607
2017.10.25 10:06:43 4: WEB_192.168.178.67_58607 GET /fhem?cmd=%7BAttrVal(%22Kerze3%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775; BUFLEN:0
2017.10.25 10:06:43 5: Cmd: >{AttrVal("Kerze3","room","")}<
2017.10.25 10:06:43 4: WEB: /fhem?cmd=%7BAttrVal(%22Kerze3%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_757658735086775 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.10.25 10:06:43 4: WEB_192.168.178.67_58364 GET /fhem?XHR=1&inform=type=status;filter=Kerze3;since=1508918801;fmt=JSON&fw_id=50×tamp=1508918805918; BUFLEN:0
2017.10.25 10:06:46 4: Connection closed for WEB_192.168.178.67_58364: EOF
2017.10.25 10:06:46 4: WEB_192.168.178.67_58607 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-10.log; BUFLEN:0
Jetzt laufen auch wie zu erwarten drei gatttool-Prozesse:

Code Auswählen Erweitern

pi@fhem:~ $ ps ax | grep -v grep | grep "gatttool"
  717 ?        S      0:00 gatttool -b 12:5A:4B:10:AC:E6 --char-write -a 0x16 -n 06fb4c17
  776 ?        S      0:00 gatttool -b AC:E6:4B:07:A4:BE --char-write -a 0x14 -n 005bff4f03000a00
  822 ?        S      0:00 gatttool -b AC:E6:4B:07:B5:E8 --char-write -a 0x14 -n 008b3dff03000a00

Helfen diese Beschreibungen, das Problem einzugrenzen? Ich verstehe die Abläufe und Ausgaben nicht einzuordnen. Ganz am Anfang nach einem Neustart liest fhem die states ja richtig, leider lassen sich keine Änderungen am Farbzustand der Kerzen einstellen, weil (wenn ich das richtig verstehe) die gatttool-Befehle nicht korrekt weitergeleitet werden.

Über Hilfe freue ich mich. Allerdings kann die Antwort etwas dauern - diese Woche der Lohnarbeit ist etwas umfangreicher. Danke schonmal!

[jonah]

So, das Wochenende und damit etwas mehr freie Zeit zum Basteln ist da.
Wenn jemand Vorschläge hat, was ich machen kann, um die Bulbs korrekt einzubinden, freue ich mich.

[jonah]

Heute hätte ich auch noch Zeit.

[CoolTux]

Bleiben denn die Prozesse immer noch in der Liste stehen?

Was passiert wenn du auf der Konsole die gatttool Befehle Mal so aus führst

gatttool -b AC:E6:4B:07:B5:E8 --char-write -a 0x14 -n 008b3dff03000a00

[jonah]

Der Prozess bleibt nicht hängen:

Code Auswählen Erweitern

pi@fhem:~ $ gatttool -b AC:E6:4B:07:B5:E8 --char-write -a 0x14 -n 008b3dff03000a00
^C
pi@fhem:~ $ ps ax | grep -v grep | grep "gatttool"                             
pi@fhem:~ $