Neues Modul: EQ3 Bluetooth Thermostat (10_EQ3BT)

Master_Nick · 28 Februar 2018, 22:56:20

Ich bin mir nun nicht ganz sicher, ob ich gemeint bin.

Aber hier ist das was an Änderungen von CoolTux kam mit meinen Anpassungen und dem neusten von dominik vereint in einer Datei.

Gasmast3r · 28 Februar 2018, 23:20:16

Zitat von: Master_Nick am 28 Februar 2018, 22:56:20
Ich bin mir nun nicht ganz sicher, ob ich gemeint bin.

Aber hier ist das was an Änderungen von CoolTux kam mit meinen Anpassungen und dem neusten von dominik vereint in einer Datei.

Jupp du warst gemeint, spiele es morgen mal ein und berichte.

Master_Nick · 28 Februar 2018, 23:46:36

Ich habe gerade wieder einen Langläufer und versuchte ihn ein wenig zu analysieren.

Habe dabei was für mich seltsames festgestellt.

Code Auswählen

pi@TouchPi3:~ $ sudo ps -ax | grep -E gatttool -b
6886: 2243 ?        Ss     0:00 bash -c gatttool -i hci0 -b XX:XX:XX:XX:XX:EC--char-write-req -a 0x0411 -n 4122 --listen 2>&1 /dev/null
7018: 2244 ?        S      0:00 gatttool -i hci0 -b XX:XX:XX:XX:XX:EC --char-write-req -a 0x0411 -n 4122 --listen /dev/null
7874:18941 ?        Ss     0:00 bash -c timeout 15 gatttool -i hci0 -b XX:XX:XX:XX:XX:DE --char-write-req -a 0x0411 -n 0312021C1729 --listen 2>&1 /dev/null
8025:18942 ?        S      0:00 timeout 15 gatttool -i hci0 -b XX:XX:XX:XX:XX:D4 --char-write-req -a 0x0411 -n 0312021C1729 --listen /dev/null
8163:18943 ?        S      0:00 gatttool -i hci0 -b XX:XX:XX:XX:XX:D4 --char-write-req -a 0x0411 -n 0312021C1729 --listen /dev/null
8329:18968 pts/0    S+     0:00 grep --color=auto -E gatttool -b

Hier sind gerade 2 Thermostate angesprochen eines völlig korrekt mittels timeout (Thermostat D4) davor und dann wieder das noch ungeklärte (wahrscheinlich einfach eine Stelle die noch nicht abgefangen wird für ssh) und das ist das THermostat mit EC.

Schaue ich nun mit pidof gatttool mal was so läuft sagt es mir:

Code Auswählen

pi@TouchPi3:~ $ sudo pidof gatttool
2244

Wie kann das sein? Der Prozess ist ja da und blockiert ja auch das Thermostat aber er ist nicht mehr aktiv erkennbar? Raff ich nicht :-D

Kann diesen Geister-Process daher auch nicht wie mein Gedanke war vorerst mittels grep und kill automatisch killen lassen... weil er nicht existent ist für Kill.

CoolTux · 01 März 2018, 05:15:10

Zitat von: Master_Nick am 28 Februar 2018, 23:46:36
Ich habe gerade wieder einen Langläufer und versuchte ihn ein wenig zu analysieren.

Habe dabei was für mich seltsames festgestellt.

Code Auswählen Erweitern
pi@TouchPi3:~ $ sudo ps -ax | grep -E gatttool -b 6886: 2243 ? Ss 0:00 bash -c gatttool -i hci0 -b XX:XX:XX:XX:XX:EC--char-write-req -a 0x0411 -n 4122 --listen 2>&1 /dev/null 7018: 2244 ? S 0:00 gatttool -i hci0 -b XX:XX:XX:XX:XX:EC --char-write-req -a 0x0411 -n 4122 --listen /dev/null 7874:18941 ? Ss 0:00 bash -c timeout 15 gatttool -i hci0 -b XX:XX:XX:XX:XX:DE --char-write-req -a 0x0411 -n 0312021C1729 --listen 2>&1 /dev/null 8025:18942 ? S 0:00 timeout 15 gatttool -i hci0 -b XX:XX:XX:XX:XX:D4 --char-write-req -a 0x0411 -n 0312021C1729 --listen /dev/null 8163:18943 ? S 0:00 gatttool -i hci0 -b XX:XX:XX:XX:XX:D4 --char-write-req -a 0x0411 -n 0312021C1729 --listen /dev/null 8329:18968 pts/0 S+ 0:00 grep --color=auto -E gatttool -b

Hier sind gerade 2 Thermostate angesprochen eines völlig korrekt mittels timeout (Thermostat D4) davor und dann wieder das noch ungeklärte (wahrscheinlich einfach eine Stelle die noch nicht abgefangen wird für ssh) und das ist das THermostat mit EC.

Schaue ich nun mit pidof gatttool mal was so läuft sagt es mir:
Code Auswählen Erweitern
pi@TouchPi3:~ $ sudo pidof gatttool 2244

Wie kann das sein? Der Prozess ist ja da und blockiert ja auch das Thermostat aber er ist nicht mehr aktiv erkennbar? Raff ich nicht :-D

Kann diesen Geister-Process daher auch nicht wie mein Gedanke war vorerst mittels grep und kill automatisch killen lassen... weil er nicht existent ist für Kill.

Das was geht wird normal abgefragt und das andere was hängt wird per ssh angesprochen?

Master_Nick · 01 März 2018, 17:20:40

Hi CoolTux,

es gibt bei mir keinerlei lokal (normal) abgefragte Thermostate ALLE arbeiten über SSH.
Alle haben den gleichen sshHost eingetragen (TouchPi3).

Somit das was hängt wird auch über ssh aber eben ohne timeout (warum auch immer bin dem code noch nicht gefolgt im modul).

Gasmast3r · 02 März 2018, 09:03:31

Hy hab die version nun 24 std am laufen und nur timeout for EQ3BT_execGetttool einträge im log bei verbose 1,soll das so sein

Habe aber nur 2 thermostate die errorCount einträge habe von mehr wie 20, alle anderen sind bei 0-6.

CoolTux · 02 März 2018, 10:33:01

Zitat von: Gasmast3r am 02 März 2018, 09:03:31
Hy hab die version nun 24 std am laufen und nur timeout for EQ3BT_execGetttool einträge im log bei verbose 1,soll das so sein
Habe aber nur 2 thermostate die errorCount einträge habe von mehr wie 20, alle anderen sind bei 0-6.

Diese timeout for EQ3BT_execGetttool Einträge kommen vom Blocking.pm Modul und können gesteuert werden in dem man loglevel als INTERNAL hinterlegt. Dann kann man den Loglevel vom Blocking.pm Modul steuern.
Sind die Thermostate besonders weit weg oder warum klappt das nicht?

Gasmast3r · 02 März 2018, 10:35:28

hy weit weck ist relativ

hatte jetzt ne weile alles ohne ssh am laufen, wollte mich am testen nur beteiligen um mehr als eine test Instanz zu haben

CoolTux · 02 März 2018, 10:52:22

Zitat von: Master_Nick am 01 März 2018, 17:20:40
Hi CoolTux,

es gibt bei mir keinerlei lokal (normal) abgefragte Thermostate ALLE arbeiten über SSH.
Alle haben den gleichen sshHost eingetragen (TouchPi3).

Somit das was hängt wird auch über ssh aber eben ohne timeout (warum auch immer bin dem code noch nicht gefolgt im modul).

Möglich das ich was gefunden haben. Ich habe mal debug Meldungen eingebaut. Hoffe das mein svn die Datei korrekt geupdatet hat.
Bitte mal angehängte pm probieren und im Log schauen. Wenn wieder ein Prozess ohne timeout gestartet wird mal schauen was im Log zu "listen Debug, listen:" steht.

Master_Nick · 02 März 2018, 15:29:39

Danke - ich teste ab sofort

Master_Nick · 02 März 2018, 18:41:15

Hihi

Hab dann mal aus $hci wieder $hciDevice gemacht

Hab dann doch noch 3 Stunden gebraucht um zu zu kommen.

Soweit lüppt es gerade - ich werde berichten. Vielen Dank schon mal für die Investition.

CoolTux · 03 März 2018, 10:37:14

Habe mal auf die schnelle was ein gebaut.

loglevel Support für BlockingCall
Zusätzliche Logausgabe zum finden des timeout Problemes

CoolTux · 03 März 2018, 10:53:57

Habe meinen nun auch wieder an geschraubt und kann mit testen.

CoolTux · 03 März 2018, 12:13:21

Meine Vermutungen haben sich bestätigt. Der timeout Befehl war zu lang und das und das BlockingCall Timeout zu kurz. Ich habe den timepout Befehl auf 10s gesetzt und den BlockingCall Timeout von 60s auf 90s
So läuft es bei mir erstmal sauber. Keine hängenbleibenden ssh gattttools mehr. Langzeittest muß nun mehr Aufschluß zeigen.

Angehängt die neuste Version.

Gasmast3r · 03 März 2018, 12:15:00

Zitat von: CoolTux am 03 März 2018, 12:13:21
Meine Vermutungen haben sich bestätigt. Der timeout Befehl war zu lang und das und das BlockingCall Timeout zu kurz. Ich habe den timepout Befehl auf 10s gesetzt und den BlockingCall Timeout von 60s auf 90s
So läuft es bei mir erstmal sauber. Keine hängenbleibenden ssh gattttools mehr. Langzeittest muß nun mehr Aufschluß zeigen.

Angehängt die neuste Version.

Lade ich gleich mal in mein sys