Anwesenheitserkennung Bluetooth PebbleBee

[CoolTux]

Code Auswählen Erweitern


./Auto_GtagBatterie.sh: Zeile 5: bc: Kommando nicht gefunden.


Also noch tiefer kann man die Nase gar nicht rein gesteckt bekommen. Es fehlt das bc Programm. Siehe auch Wiki.

[SouzA]

Vielen Dank für Deine Antwort...

Aber wie bereits geschrieben, bin ich da einfach nur Abtipper innerhalb des Raspi.
Welches bc Programm? Und was ist das? Im Wiki von der Anwesenheit lässt sich für mich auf nichts dergleichen schließen.
Wo kriege ich das her und was macht es?

Code Auswählen Erweitern

sudo apt-get install bc

Für die, die es nicht wissen... das ist der BasisCalculator! (?!)
Naja, installiert und funzt.

Nochmals danke und einen schönen Abend wünsche ich

SouzA

[CoolTux]

https://packages.debian.org/de/sid/bc

[SouzA]

Da war ich knapp 1,5 min schneller

Trotzdem vielen vielen Dank!
Bin immer wieder fasziniert, wie viele Leute sich mit sowas auskennen... Und außerdem über die grandiose Arbeit, die an und im fhem geleistet wird! 

Bis denn
SouzA

[Devender]

Code Auswählen Erweitern

sudo apt-get install bc
Für die, die es nicht wissen... das ist der BasisCalculator! (?!)

ich habe das Wiki dementsprechend ergänzt. 

[Taasba]

Hallo miteinander,

ich habe mich durch den gesamten Thread "gekämpft" und muss sagen: Respekt vor Eurer Arbeit und der Geduld mit Neulingen hier in diesem Forum.

Hier noch das Stichwort für die Suche:
- Problem Batterieüberwachung mit G-TAG - Wert wird nicht an fhem übergeben - Lösung


Ich möchte meine Erfahrungen hier kurz mitteilen. Vielleicht können auch andere davon profizieren.

- ich habe 5 G-Tags im Einsatz und wolle dazu auch die Batterieüberachung umsetzen
- entsprechend dem WIKI Eintrag (http://www.fhemwiki.de/wiki/Anwesenheitserkennung#Anwesenheitserkennung_Bluetooth_PebbleBee_mit_PRESENCE_Modul) alles soweit eingerichtet. Funktionierte bis auf die Batterieüberwachung prima.
- Ich habe mir für jeden G-Tag eine eigenes Shell-Script angelegt, welche per crontab (1x mal in der Nacht) aufgerufen werden.
- Das Problem war, dass die Daten nicht an fhem übergeben wurden. ( perl /opt/fhem/script/fhem.pl 7072 "setreading <NAME-GTAG> Batterie $decimal" )

Nach langem Suchen habe ich nun den Übeltäter gefunden! Es lag an der Übergabe an telnet.

Mein telnet-Zugang war mit einem password gesichert, welches beim Aufruf des Scripts auch erwartet wurde. Nach Änderung in der fhem.cfg in globalpassword ging es dann.

Hier die Änderung:
define telnetPort telnet 7072 global
define allowed_telnetPort allowed
attr allowed_telnetPort globalpassword passwort
attr allowed_telnetPort validFor telnetPort
 
Jetzt klappt auch die Übergabe an fhem

LG

Torsten

[Taasba]

Hallo allerseits

erstmal vielen Dank für Eure tolle Arbeit.

Mithilfe dieses Forums habe ich 2 G-tags erfolgreich in FHEM (Jessie auf Raspberry 3) eingebunden.
Die beiden G-Tags werden gefunden:
pi@raspberrypi:~ $ sudo hcitool lescan
LE Scan ...
7C:2F:80:A1:2F:06 (unknown)
7C:2F:80:A1:2F:06 Gigaset G-tag
7C:2F:80:AD:C3:86 (unknown)
7C:2F:80:AD:C3:86 Gigaset G-tag

Lepresenced läuft ohne Fehler, in FHEM wird die Anwesenheit und Abwesenheit korrekt angezeigt.

Leider laufen in den Logdateien /var/log/syslog und /var/log/kernel im Sekundentakt folgende Meldungen auf:

Jul 29 15:08:11 raspberrypi kernel: [ 4905.634211] bt_err_ratelimited: 1 callbacks suppressed
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634231] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:12 raspberrypi kernel: [ 4906.647350] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.532081] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.655564] Bluetooth: hci0 advertising data length corrected
...

Wobei der Befehl "hcitool lescan" genau 2 Meldungen in den Logdateien erzeugt.
Bei "hcitool --duplicates" werden dann fortlaufend Meldungen generiert.

Leider habe ich bisher keine Möglichkeiten gefunden diese Meldungen abzustellen bzw. zu unterdrücken.

Habt Ihr vielleicht eine Idee ?

Ist zwar schon ein wenig her...aber bis auf den Tipp einer zusätzlichen "constant" in lepresenced gibt es keine weiteren Ideen. Scheinbar ist es ein Problem mit dem G-Tag und meinen RasPi3. Hat noch jemand diese Erfahrung?

Ist schon blöd, wenn die syslog pro Tag über 100.000 Einträge generiert (mehrere Einträge poro Sekunde!).

Lieben Dank.

Torsten

provisorische Lösung:

Edit: 06.10.2016
- zunächst einmal herzlichen Dank an Patrick Reinhardt (Entwickler lepresenced), der mir den Tipp gegeben hat.
- scheinbar tritt das Problem beim RasPi 3 auf. Fehlermeldungen werden in verschiedene log's geschrieben. Bei mir wurden maßgeblich "syslog" und "kern.log" zugemüllt. 
- eine provisorische Lösung, weil die Ursache damit ja nicht gelöst wird, ist das reine Unterbinden der Einträge:

1. Unter "/etc/rsyslog.d" eine Datei erzeugen mit dem Namen "01-blocklist.conf"
2. Inhalt: (Die Ausdrücke in den "" sind diejenigen, die aus dem log verschwinden sollen. - bei mir waren es die unten stehenden")
    :msg,contains,"Bluetooth: hci0 advertising data length corrected" ~
    :msg,contains,"bt_err_ratelimited:" ~
3. Dienst neu starten "sudo service rsyslog restart"
4. log prüfen und freuen, wenn alles geklappt hat.

Grundlage dieser Idee ist hier beschrieben: http://askubuntu.com/questions/18970/is-there-a-way-to-suppress-one-specific-message-from-syslog

[Jamo]

Batterieüberwachung mit G-TAG - bei mir stehen da jetzt im Batterie Reading Werte von "94" und "85" für die Batterie. Bei welchem Wert sollte man die Batterie denn Wechseln? Oder sind das die "% voll" Werte der Batterie?

Danke ! 

[CoolTux]

Das sind Prozentangaben

[CoolTux]

Hier mal wie ich es bei mir gemacht habe.

[Jamo]

Hallo Cooltux,
kannst Du mir vielleicht noch erklären, wie Du das zweite userreading "device_battery" angelegt hast?

Ich habe mir jetzt einen abgebrochen, und folgendes probiert, aber das funktoniert nicht:

attr Presence_GTAG_collect userReadings Batterie, Device_Battery:state.* {if ( ReadingsNum("Presence_GTAG_collect","Batterie","NA") < 30) {fhem("setreading Presence_GTAG_collect Device_Battery low")} else {fhem("setreading Presence_GTAG_collect Device_Battery ok")}}

Danke !

[CoolTux]

Also um ehrlich zu sein ist das kein Userreading sondern Readings die durch eine Funktion gesetzt werden.
Wie das mit Userreadings geht müsste ich auch erst schauen.

[Jamo]

OK, ich denke Du willst das gleiche erreichen wie ich, nämlich das bei einem bestimmten % batterie-level das Reading 'device_battery' auf 'low' gesetzt wird. Wenn das elegant über eine Funktion geht ist das auch prima für mich

[CoolTux]

Ich denke es ist besser wenn Du auf jemanden wartest der weiß wie das mit dem userReading richtig geht.
Grund ist das meine Funktion das macht was das hier beschriebene bash Script macht.
Ich rufe in meiner Funktion das Toll gatttool auf und lese den Wert aus der dann umgerechnet wird. Danach setze ich das Reading mit dem Prozentwert und das Reading mit ok oder Low dessen Wert ich vorher noch bestimme.
Das ganze lasse ich nonBlocking arbeiten. Ist also Recht komplex.

Wenn Bedarf besteht kann ich alles gerne hier einstellen.


Grüße

[SouzA]

Heute ist mir gleiches aufgefallen:

Hallo allerseits

erstmal vielen Dank für Eure tolle Arbeit.

Mithilfe dieses Forums habe ich 2 G-tags erfolgreich in FHEM (Jessie auf Raspberry 3) eingebunden.
Die beiden G-Tags werden gefunden:
pi@raspberrypi:~ $ sudo hcitool lescan
LE Scan ...
7C:2F:80:A1:2F:06 (unknown)
7C:2F:80:A1:2F:06 Gigaset G-tag
7C:2F:80:AD:C3:86 (unknown)
7C:2F:80:AD:C3:86 Gigaset G-tag

Lepresenced läuft ohne Fehler, in FHEM wird die Anwesenheit und Abwesenheit korrekt angezeigt.

Leider laufen in den Logdateien /var/log/syslog und /var/log/kernel im Sekundentakt folgende Meldungen auf:

Jul 29 15:08:11 raspberrypi kernel: [ 4905.634211] bt_err_ratelimited: 1 callbacks suppressed
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634231] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:12 raspberrypi kernel: [ 4906.647350] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.532081] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.655564] Bluetooth: hci0 advertising data length corrected
...

Wobei der Befehl "hcitool lescan" genau 2 Meldungen in den Logdateien erzeugt.
Bei "hcitool --duplicates" werden dann fortlaufend Meldungen generiert.

Leider habe ich bisher keine Möglichkeiten gefunden diese Meldungen abzustellen bzw. zu unterdrücken.

Habt Ihr vielleicht eine Idee ?

Hat jemand dazu mittlerweile eine Idee?

Da kommen ganz schön viele Einträge zusammen... ob das so gut ist für ne SD?
Könnte das mal bitte jemand an seinem Raspi checken, ob es bei Ihm genauso ist?

Code Auswählen Erweitern

sudo nano /var/log/syslog

Vielen Dank!
SouzA