Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wenn 291 und 292 deine iKOs sind, die direkt vom BTdaemon kommen, dann machst du da ein "Wenn alle anwesend"?
Wenn du ein "wenn alle abwesend" machen möchtest, dann brauchst du einen Inverter vor den Eingängen.
Wenn der Keeper erkannt wird, wird das iKO = 1 gesetzt. Wenn abwesend, dann iKO = 0.
Im UND Baustein ist A1 nur dann = 1, wenn E1 UND E2 <> 0 sind. D.h. sobald eine der beiden Personen anwesend ist, ist E1 oder E2 = 1 und damit A1 vom UND Baustein = 0. Die Ausgangsboxen reagieren aber nur, wenn E1 <> 0. Und das wäre nur der Fall, wenn kein Keeper erkannt wird.
Dieser Baustein bildet ein UND-Gatter nach. Wenn alle(!) Eingänge mit einem Wert ≠0 belegt sind, wird A1=1 gesetzt. Ist einer der Eingänge =0 wird A1=0 gesetzt.
Jedes neue Telegramm an einem Eingang triggert den Baustein und führt dazu, dass A1 entweder =0 oder =1 gesetzt wird.
BEIDE müssen 1 sein..
Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groüen Saal.
Die Gigaset Keeper dürfen nicht noch zusätzlich mit dem Handy verbunden sein. Zumindest ist es bei mir so, dass sie als offline angezeigt werden, wenn sie mit dem Handy verbunden sind. Wenn ich sie am Handy wieder trenne, sind sie wieder online.
Die BT.ini schaut genau so bei mir aus. Die Gtags sind auch nicht mit dem Handy verbunden.
ich habe jetzt wieder folgendes Problem habe heut früh den deamont gestoppt und wieder gestartet. Dann bringt er die richtigen werte ein paar Minuten später waren alle IKO wieder auf 0. obwohl alle Gtags anwesend waren. Mir kommt es so vor als sich mei bluetoth modul immer aufhängen würde. Wäre das Möglich?
Ist eventuell auch Möglich das Script so zu ändern das ich es über Edomi statrten könnte?
würde dann nämlich wenn niemand anwesend wäre alle 20 sek einmal starten lassen und wenn dann jemand anwesend ist nur noch alle 5 oder 10 minuten suchen lassen. Und dann könnte ich auch wenn ein Gtag nicht mehr gefunden wird ihn nach 20 min noch mal suchen lassen ob er auch wirklich abwesend ist um kurze verbindungssbbrüche zu Überbrücken.
Hintergrund der überlegen wäre um die Batterie des Gtags zu Sparen. Weil jetzt scheint er alle drei sekunden zu Suchen wenn ich das richtig sehe in Putty
ich habe jetzt wieder folgendes Problem habe heut früh den deamont gestoppt und wieder gestartet. Dann bringt er die richtigen werte ein paar Minuten später waren alle IKO wieder auf 0. obwohl alle Gtags anwesend waren. Mir kommt es so vor als sich mei bluetoth modul immer aufhängen würde. Wäre das Möglich?
Möglich ist alles. Du müsstest ins Log schauen, ob das BT Modul noch Daten liefert.
Ist eventuell auch Möglich das Script so zu ändern das ich es über Edomi statrten könnte?
Das ist schon möglich und zwar über den SSH LBS.
Ob das sinnvoll ist sich mit so einem Workaround zu beschäftigen würde ich mal bezweifeln. Besser wäre es die Ursache für die Instabilität (sofern diese vorliegt) zu finden und zu beheben. Bei mir läuft der Daemon schon über eine Woche problemlos ohne jeglichen Neustart. Dies auf einem RPI3 als auch auf einem RPI Zero W. Letzteren halte ich für die Ideallösung für dieses Projekt. Mit 15€ ist er günstiger als ein Keeper Tag und hat WLAN und Bluetooth LE an Bord. Nur noch ein kleines Netzteil und ne kleine SD Karte und evtl. ein Gehäuse und fertig ist die Laube.
Wie komm ich den in den log um zu sehen ob noch daten kommen?
bei mir läuft das ganze auch auf einem RPI 3
wenn das ganze läuft möchte auch noch meinen zero noch mit einsetzen.
Welches betriebsystem benutz du dafür jonofe ?
vll setzte ich ihn heut Abend nochmal schnell neu auf.
Richtig beschrieben und auch so verstanden, aber trotzdem ein Knoten im Hirn gehabt. Hab jetzt den Inverter LBS mal davor gehängt. Danke.
Bei einem Neustart (aus der Ferne, keiner zuhause) zeigt er mir komischerweise auch nur einen Keeper als abwesend. Und das auch nur 1x. Soll das so sein?
Hier steht er seit ner halben Stunde im Log ist auch nicht mehr drin, als der eine Keeper als abwesend:
D.h. wird wieder ein Keeper erkannt, läuft das Ganze auch weiter.
Ja, das Log ist genau richtig. Wenn der Keeper als inactive erkannt wurde wird nichts weiter ins Log geschrieben. Im Gegensatz dazu wird jeder erfolgreiche "PING" ins Log geschrieben. Es sollte also weitergehen, wenn der Keeper wieder in Reichweite ist.
Kann es sein, dass die Bluetooth Verbindung schlecht ist?
Gibt es denn danach gar keine Verbindung mehr? Auch nicht, wenn die Tags direkt neben dem RPI oder was auch immer du verwendest liegen?
EDIT: Passiert es immer nach derselben Zeit? Wie viele verschiedene Tags sind es denn? Die Smileys machen es etwas unübersichtlich. Am besten mal als CODE posten.
Möglich ist alles. Du müsstest ins Log schauen, ob das BT Modul noch Daten liefert.
Das ist schon möglich und zwar über den SSH LBS.
Ob das sinnvoll ist sich mit so einem Workaround zu beschäftigen würde ich mal bezweifeln. Besser wäre es die Ursache für die Instabilität (sofern diese vorliegt) zu finden und zu beheben. Bei mir läuft der Daemon schon über eine Woche problemlos ohne jeglichen Neustart. Dies auf einem RPI3 als auch auf einem RPI Zero W. Letzteren halte ich für die Ideallösung für dieses Projekt. Mit 15€ ist er günstiger als ein Keeper Tag und hat WLAN und Bluetooth LE an Bord. Nur noch ein kleines Netzteil und ne kleine SD Karte und evtl. ein Gehäuse und fertig ist die Laube.
Ich hab auch den Raspberry Zero W dafür geholt. In der Leerdose hinterm Tablet war genug Platz das Ding einfach da mit zu platzieren.
Übrigens, ein Tipp zu den Keeper/GTags....einfach mal bei Kleinanzeigen schauen. Ich hab das 3er-Pack dort für 21 Euro inkl. Versand bekommen
Es sind insgesamt 5 Gtags angelegt. 1 davon ist abwesend 2 liegen direkt neben dem RPI 3 und 2 einen Raum weiter.
Ob es immer zur selben zeit ist kann ich nicht sagen. Ich schau halt seid dem jeten Tag auf der Arbeit nach und stelle halt immer fest das der Status dazu nicht passt.
Code:
2019-01-30 20:45:13 - 7C:2F:80:EA:F1:D6 ACTIVE
2019-01-31 06:21:31 - 7C:2F:80:EA:F2:27 ACTIVE
2019-01-31 06:21:31 - 7C:2F:80:EA:F2:03 ACTIVE
2019-01-31 06:21:31 - 7C:2F:80:EA:F1:D1 ACTIVE
2019-01-31 06:21:31 - 7C:2F:80:EA:F1:D6 ACTIVE
2019-01-31 06:21:55 - 7C:2F:80:EA:F1:D6 inactive
2019-01-31 06:22:00 - 7C:2F:80:EA:F2:27 inactive
2019-01-31 06:22:00 - 7C:2F:80:EA:F2:03 inactive
2019-01-31 06:22:00 - 7C:2F:80:EA:F1:D1 inactive
Und wenn ein Tag einmal auf inactive geht, dann wird er nie wieder active?
Und ein Restart des Daemon behebt das Problem dann?
Du solltest mal prüfen, ob es immer nach einer bestimmten Zeit nach dem Restart des BTdaemon passiert. Würde ja auf ein Timeout hindeuten. Und sicherstellen, dass keine Gigaset App läuft, denn ansonsten antworten die Keeper nicht.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
6 ACTIVE
Kommentar