Anwesenheitserkennung mittels BT und RASPBERRY

[grissli1]

Warum soll die Zuverlässigkeit hier eine Selbsttäuschung sein?
Ich hatte das so Monate in Betrieb und keine einzige Falschmeldung. Wir brauchen unsere Handies dienstlich und somit hat jeder seines mit. Hat bei uns perfekt funktioniert.

Inzwischen verwenden wir die Piotek Tracker. Die sind super aber sehr groß. Werde da mal ein kleineres Gehäuse machen. Aber hier wird gerne mal einer zu Hause gelassen, weil wir die Haustüre und die Wohnungstüre schlüssellos öffnen. Da war es mit BT zuverlässiger.
Vielleicht gehen wir wieder zurück zu der BT Lösung.

Viele Grüße
Chris

Gesendet von meinem LG-V500 mit Tapatalk

[Homeberry]

bist Du dir 100% sicher dass RFID eine größere Reichweite hat als BT?

Nein eher eine geringere. Das könnte hilfreich sein um den Bereich klarer abzugrenzen in dem man erkannt wird. Wenn BT einen sehr großen Bereich abdeckt kann man nicht festlegen dass 2 m vor der Haustüre plötzlich Schluss ist mit Empfang.

Ich persönlich halte eine Haus-Automatisierung der ich manual sagen muss ob ich da bin oder nicht, für ein Widerspruch an sich. Dann kann ich es auch gleich lassen.

Den Gedanken kann ich nachvollziehen. Allerdings hat man wohl immer die Qual der Wahl, sage ich dem System ob ich da bin oder nicht und habe dafür die Sicherheit dass das System das tut was ich gerade will, oder lasse ich es selbst rausfinden ob ich da bin und muss damit rechnen dass es das nicht immer richtig macht. Für mich wärs undenkbar mich nur an meinem Smartphone zu identifizieren. Bei 30 min. einkaufen bleibt das auch gerne mal zuhause - obwohl ich weg bin. Nachts ists oft aus - obwohl ich da bin.
Wenn man dann große Hoffnungen hinein steckt und kritische Dinge damit steuert fällt man vielleicht unsanft auf die Nase. Das sollte einem bewusst sein. Vor allem wenn ich sehe wie manche ihr ganzes Leben ihrer Hausautomatisierung anvertrauen

Ich hatte das so Monate in Betrieb und keine einzige Falschmeldung.

Wenns so funzt, super!
Ich zweifle ja nicht an dem System an sich sondern am Zusammenhang zwischen den Fakten Smartphone zuhause - ich zuhause. Erfordert eben eine unheimliche Disziplin mit dem Smartphone, bei mir würde es wie gesagt nicht lange gut gehen.

Wenn jemand der wirklich 1:1 mit BT erkennbar ist das macht und es auch klappt, freuts mich. Wär doch nur schade wenn jemand wie ich das nachbaut und merkt dass es bei ihm nicht klappt, und dann auf das System schimpft statt zu merken dass es ganz einfach nicht passt.

[marius.jaworowski@gmail.com]

Hallo Freunde,

ich habe währen dessen ein paar Verbesserungen am Programm vorgenommen. Die meisten Veränderungen kamen der Stabilität zugute und der Ausgabe der Log-Datei.
Aber auch eine neue Funktion ist implementiert worden: Verlassen alle clients die Home-Zone, erhört Spot automatisch die Intervall der Abfragen.

Die neuste Version von Sport finden Ihr wie immer unter https://github.com/red-ip/spot

Gruß Marius

[homematic_fan]

Ich zweifle ja nicht an dem System an sich sondern am Zusammenhang zwischen den Fakten Smartphone zuhause - ich zuhause. Erfordert eben eine unheimliche Disziplin mit dem Smartphone, bei mir würde es wie gesagt nicht lange gut gehen.

Wer sein Smartphone nicht als Bluetooth-Gerät verwenden will, könnte alternativ so einen Tag benutzen:

http://www.gigaset.com/de_de/smart-home ... selfinder/

Der ein oder andere hat vielleicht so etwas schon. Bei mir hängt so ein Ding am Schlüsselanhänger bzw. dem Schlüsseltäschchen, weil ich den manchmal scheinbar unauffindbar verlege. Der Vorteil ist: Das Smartphone bleibt vielleicht mal zu Hause, wenn man das Haus verläßt, der Schlüssel wird immer mitgenommen --- falls nicht hat man ein anderes Problem .

Grüße
HM-Fan

[elvthg]

Moin, moin Marius,

ich habe währen dessen ein paar Verbesserungen am Programm vorgenommen. Die meisten Veränderungen kamen der Stabilität zugute und der Ausgabe der Log-Datei.

super, die habe ich nun mal installiert, sie scheint bislang ähnlich gut wie die Vorversion zu laufen.

Trotzdem kämpfe ich ich gerade mit einem sehr nervigen Problem, nämlich das ein älteres Handy sich alle 3 - 4 Minuten an und wieder abmeldet, das war auch schon mit der Vorversion des Programms der Fall. Was mich am meisten wundert, das dies nun ein "neues" Gerät ist, denn das Handy davor (nicht ganz so alt), machte die gleichen Probleme.

Mein anderes Handy (auch ein paar Jahre alt) funktioniert hingegen völlig problemlos, meistens jedenfalls, im Moment spinnt das auch gerade.

Deswegen habe ich mir einen Pi Zero W besorgt, um ihn als zweiten Sensor zu verwenden.

Beide Handys habe auch auch damit gepaired, die Installation vom Pi3 auf den Zero übernommen und nur das Init-Script nach Readme angepasst. Das scheint auch irgendwie zu laufen, allerdings erkennt der Pi3 den zusätzlichen Sensor-Spot nicht.

Der Parameter -m funktioniert leider nicht, da gibt es einen Fehler:

Code: Alles auswählen

------------------- Spot 1.2.9 -------------------
------------------- IP manual set to 10.20.30.32:10002 -------------------
Usage: spot.py [-options] [arg]

spot.py: error: Sensor IP and Port (10.1.1.2:10002) Mandatory if you not using Automatic Discovery Mode

Allerdings ist der "Quatsch", denn der String den Du abfragst lautet "{'10.20.30.32': '10002'}", aber Du testest auf ein "len(...) < 8" wohingegen "len" in dem Fall "1" ausgibt.

Ein wenig Starthilfe wäre hier also noch sinnvoll.

Sonderbar ist auch, das der Pi3 nach wie vor den zweiten Sensor sucht, obwohl ich den eigentlich "abgeklemmt" habe:

Code: Alles auswählen

25.04.2017 18:19:11 [ERROR   ] Sensor 10.20.30.32 timeout - sensor_com.py - display_msg

Aber auch eine neue Funktion ist implementiert worden: Verlassen alle clients die Home-Zone, erhört Spot automatisch die Intervall der Abfragen.

Das bedeutet, das die Erkennung schneller reagieren sollte? Muss ich mal ausprobieren

Ich plane das aber noch zu erweitern, ich möchte auf meinem Pi Zero W ein paar RGB-LEDs setzen, mit dem ich den Status der Erkennung anzeigen lassen kann. Z.B. eine LED die leuchtet, wenn der "Erstkontakt" via Bluetooth erkannt wird und eine weitere, wenn "sicher" ist, das eine Person anwesend ist. Da muss ich aber noch den "Einsprungpunkt" im Programm finden.

Eine weitere Idee wäre, die Erkennung "robuster" zu machen, indem man zusätzlich auch den WLAN-Status abfragt, da habe ich mal ein wenig rumgebastelt, bislang aber ohne Erfolg.

Die neuste Version von Sport finden Ihr wie immer unter https://github.com/red-ip/spot

Vielleicht kannst Du da noch eine Beispiel-Konfig mit ins Repository legen, zumindest habe ich keine gefunden.


Vielen Dank für Deine Mühe,

[elvthg]

Trotzdem kämpfe ich ich gerade mit einem sehr nervigen Problem, nämlich das ein älteres Handy sich alle 3 - 4 Minuten an und wieder abmeldet,

es sind ziemlich genau alle 3 Minuten.

Ich hatte gestern Nacht die Parameter von 5 Sekunden/2 Mal nicht gesehen erhöht:

Code: Alles auswählen

[SPOT]
log_file_location = /opt/spot/log
sleep_timer_sec = 20
max_time_not_seen = 3

[CLIENTS]
log_file_locations_clients = /opt/spot/log

[CCU]
ip_ccu = 10.20.30.25

[PIFACECAD]
pifacecad_support = false

Hat aber leider nichts gebracht, hatte heute Morgen unzählige Mails im Postfach


Grüße,

elvthg

[marius.jaworowski@gmail.com]

Hallo elvthg,

den Pi Zero W habe ich mir auch vor ein paar Wochen besorgt und nutze diesen ebenfalls als einen Sensor. Deine Idee mit den RGB LED finde ich klasse, wir sollten das implementieren!

aber zuerst zu deinem Problem:
Wenn ich alles richtig deute, befinden sich alle Komponenten im gleichen IP-Subnetz (10.20.30.0/24). Ich werde mir den -m Parameter anschauen, aber diesen brauchst du in deinen Fall wahrscheinlich nicht. Der Pi3 sucht nach dem Start und dann alle paar min nach neuen Sensoren automatisch. Deine Konfigurationsdatei scheint ok zu sein.

Versuchern wir mal herauszufinden was das los ist. Dazu musst du dich auf den Pi3 sowie Pi0 über eine Terminalsitzung (ssh) anmelden und die folgenden Schritte auf beiden Geräten abarbeiten.

Lass uns Super Rechte anfordern:
sudo su

Gehe dann in das VZ von Spot:
cd /opt/spot/

Beende auf beiden Geräten Spot
python spot_sensor.py -s
python spot.py -s

Überprüf ob Spot auch wirklich aus ist:
ps aux | grep spot | grep -v grep

Sollte ein Prozess noch laufen, kill es
kill <PID>

Starte Spot Sensor auf den Pi0 im debug modus
python spot_sensor.py -l

Starte Spot auf den Pi3 im debug modus
python spot.py -l

Sobald beide Seiten gestartet sind, solltest du nach 1-2 Min einiges an output bekommen.

Bei mir seht der output vom Sensor wie folgt aus:

lading CFG
debug Lading Config file
------------------- spot_sensore 1.4.6 -------------------
------------------- Log DEBUG manual set to True -------------------
debug DEBUG LOG manual set to True
Starting in Terminal
debug checking if ip interface is ready
debug IP-Interface ready! - 192.168.180.84
debug GetSock got the IP : 192.168.180.84
info Bind the socket to the IP:Port : 192.168.180.84:10002debug UDP server listening on : ('', 55555)

debug Starting up socket on port : 10002
debug Waiting for connection
debug Detected client : 1 on ('192.168.180.52', 56342)
debug Client is connected, IP : ('192.168.180.52', 52789)
debug Sensor - Checking command: ping
debug Received ping, responding with True
debug Sensor - Checking command:

der output vom Spot sieht bei mir wie folgt aus:

python spot.py -l
lading CFG
debug Lading Config file
------------------- Spot 1.3.5 -------------------
------------------- Log DEBUG manual set to True -------------------
debug DEBUG LOG manual set to True
Terminal Mode
Local Sensor Mode Enabled - You will need to stop the Sensor manually : python spot_sensor.py -s
debug Script file is present, OK .
debug Starting : spot_sensor.py
lading CFG
debug Lading Config file
------------------- spot_sensore 1.4.6 -------------------
debug Got the option to stop the Daemon
Could not stop, pid file '/tmp/spot_sensor.pid' missing.
lading CFG
debug Lading Config file
------------------- spot_sensore 1.4.6 -------------------
------------------- Log DEBUG manual set to True -------------------
debug DEBUG LOG manual set to True
------------------- Preparing to run in daemon mode -------------------
info Preparing to run in daemon mode

started with pid 30026
info Starting to collect parameters
debug checking if ip interface is ready
debug IP interface is ready to go! local IP : 192.168.180.52
debug Running Auto Discovery for Sensors
debug sending broadcast to discover the sensors
debug 1 sensors discovered : {'192.168.180.84': '10002 '}
debug Getting Devices for check from CCU2
debug Connecting to the CCU to get device list : 192.168.180.220
info Connection to the CCU establish (RX): 192.168.180.220
info All parameters collected. System OK -> STARTING WORK
debug sendVariableToCCU2 Command : http://192.168.180.220/config/xmlapi/st ... value=true
debug sendVariableToCCU2.html Answer from CCU2 : <?xml version="1.0" encoding="ISO-8859-1" ?><result><changed id="4112" new_value="true" /></result>
debug 192.168.180.84 sending msg to sensor's display : Hello Marius
debug Sensor 192.168.180.84 has not displayed Text: Hello Marius
info Sensor is online

Sollte dein Output Fehlermeldungen enthalten, dann würde ich dich bitten dein output zu posten. Wenn alles so wie bei mir aussieht, können wir mit der Analyse fortfahren.

[elvthg]

Moin, moin Marius,

erstmal vielen Dank für die prompte Antwort

Vorweg, bevor ganz viel "unnützes" Zeug kommt

Gibt es eine Möglichkeit zu erkennen (und zu übertragen) von welchem Sensor ein Gerät (zuerst) erkannt wurde? Man hätte da bei der Steuerung weitergehende Möglichkeiten.

Ansonsten sieht es eigentlich ganz gut aus, würde mein Pi0 nicht nach relativ kurzer Zeit die WLAN-Verbindung komplett verlieren (der Pi3 ist verkabelt, wie alles was LAN hat auch)

Das hilft nur Neustart des Accesspoints und des Pi0, muss ich also nach schauen.

Jetzt noch mein Log, soweit ich sehe, sieht das gut aus und scheint nun im Prinzip auch zu funktionieren:

Code: Alles auswählen

root@pi3:/opt/spot# python spot.py -l
lading CFG
debug    Lading Config file
------------------- Spot 1.3.5 -------------------
------------------- Log DEBUG manual set to True -------------------
debug    DEBUG LOG manual set to True 
Terminal Mode
Local Sensor Mode Enabled - You will need to stop the Sensor manually : python spot_sensor.py -s
debug    Script file is present, OK .
debug    Starting : spot_sensor.py
lading CFG
debug    Lading Config file
------------------- spot_sensore 1.4.6 -------------------
debug    Got the option to stop the Daemon 
Could not stop, pid file '/tmp/spot_sensor.pid' missing.
lading CFG
debug    Lading Config file
------------------- spot_sensore 1.4.6 -------------------
------------------- Log DEBUG manual set to True -------------------
debug    DEBUG LOG manual set to True
------------------- Preparing to run in daemon mode -------------------
info     Preparing to run in daemon mode

started with pid 1055
info     Starting to collect parameters
debug    checking if ip interface is ready
debug    IP interface is ready to go! local IP : 10.20.30.29
debug    Running Auto Discovery for Sensors 
debug    sending broadcast to discover the sensors
debug    2 sensors discovered : {'10.20.30.29': '10002 ', '10.20.30.32': '10002 '}
debug    Getting Devices for check from CCU2
debug    Connecting to the CCU to get device list : 10.20.30.25
info     Connection to the CCU establish (RX): 10.20.30.25
info     All parameters collected. System OK -> STARTING WORK
debug    sendVariableToCCU2 Command : http://10.20.30.25/config/xmlapi/statechange.cgi?ise_id=17821&new_value=true
debug    sendVariableToCCU2.html Answer from CCU2 : <?xml version="1.0" encoding="ISO-8859-1" ?><result><changed id="17821" new_value="true" /></result>
debug    10.20.30.29 sending msg to sensor's display : Hello TG
debug    Sensor 10.20.30.29 has not displayed Text: Hello TG
debug    10.20.30.32 sending msg to sensor's display : Hello TG
debug    Sensor 10.20.30.32 has not displayed Text: Hello TG
info     Sensor is online
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 is still present. Loop : 1
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    1 of 6 are in the coverage of Spot
debug    devices around
debug    going sleep for 20.0 s
debug    Sensor ping failed to : 10.20.30.32 . Moving on to the next sensor
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 is first time no seen. Loop : 2
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    no more devices around
debug    going sleep for 10 s
debug    Rediscovering Sensor and devices. Loop : 3
debug    Connecting to the CCU to get device list : 10.20.30.25
debug    sending broadcast to discover the sensors
debug    1 sensors discovered : {'10.20.30.29': '10002 '}
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 is first time no seen. Loop : 3
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 10 s
debug    sendVariableToCCU2 Command : http://10.20.30.25/config/xmlapi/statechange.cgi?ise_id=17821&new_value=true
debug    sendVariableToCCU2.html Answer from CCU2 : <?xml version="1.0" encoding="ISO-8859-1" ?><result><changed id="17821" new_value="true" /></result>
debug    10.20.30.29 sending msg to sensor's display : Hello TG
debug    Sensor 10.20.30.29 has not displayed Text: Hello TG
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 is still present. Loop : 4
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    1 of 6 are in the coverage of Spot
debug    devices around
debug    going sleep for 20.0 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 is still present. Loop : 5
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    1 of 6 are in the coverage of Spot
debug    going sleep for 20.0 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    no more devices around
debug    going sleep for 10 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 10 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    sendVariableToCCU2 Command : http://10.20.30.25/config/xmlapi/statechange.cgi?ise_id=17821&new_value=false
debug    sendVariableToCCU2.html Answer from CCU2 : <?xml version="1.0" encoding="ISO-8859-1" ?><result><changed id="17821" new_value="false" /></result>
info     OUT - TG since 2017-04-26-23:47:02.
debug    ..:..:..:..:..:48 - TG is last seen at 2017-04-26-23:47:02. going to update the CCU2
debug    ..:..:..:..:..:48 changes successfully updated to CCU2
debug    10.20.30.29 sending msg to sensor's display : TG left
debug    Sensor 10.20.30.29 has not displayed Text: TG left
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 10 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 10 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 10 s

Code: Alles auswählen

root@pi0:/opt/spot# python spot_sensor.py -l

lading CFG
debug    Lading Config file
------------------- spot_sensore 1.4.6 -------------------
------------------- Log DEBUG manual set to True -------------------
debug    DEBUG LOG manual set to True
Starting in Terminal
debug    checking if ip interface is ready
debug    IP-Interface ready! - 10.20.30.32
debug    GetSock got the IP : 10.20.30.32
debug    UDP server listening on : ('', 55555)
info     Bind the socket to the IP:Port : 10.20.30.32:10002
debug    Starting up socket on port : 10002
debug    Waiting for connection
debug    Detected client : 1 on ('10.20.30.29', 46615)
debug    Client is connected, IP : ('10.20.30.29', 40094)
debug    Sensor - Checking command: ping
debug    Received ping, responding with True
debug    Sensor - Checking command: 
debug    Waiting for connection
debug    Client is connected, IP : ('10.20.30.29', 40096)
debug    Sensor - Checking command: displaytext
debug    Received text to Display, responding with True
debug    PIFACECAD_SUPPORT is not Enabled
debug    Sensor - Checking command: 
debug    Waiting for connection
debug    Client is connected, IP : ('10.20.30.29', 40098)
debug    Sensor - Checking command: ping
debug    Received ping, responding with True
debug    Sensor - Checking command: 
debug    Waiting for connection
debug    Client is connected, IP : ('10.20.30.29', 40100)
debug    Sensor - Checking command: checkdevice
debug    command received and accepted : checkdevice
debug    responding with True
debug    waiting for command parameters
debug    Command parameter received : ..:..:..:..:..:53
debug    Command parameter received : ..:..:..:..:..:B1
debug    Command parameter received : ..:..:..:..:..:48
debug    Command parameter received : ..:..:..:..:..:9A
debug    Command parameter received : ..:..:..:..:..:1F
debug    Command parameter received : ..:..:..:..:..:72
debug    parameters: {'..:..:..:..:..:53': '', '..:..:..:..:..:B1': '', '..:..:..:..:..:48': '', '..:..:..:..:..:9A': '', '..:..:..:..:..:1F': '', '..:..:..:..:..:72': ''}
debug    The number of valid parameters (MAC-Address) is: 6
debug    Transmitting the results back to the client (Spot collector)
debug    bluetooth lookup for MAC : None : False 
debug    bluetooth lookup for MAC : None : False 
debug    bluetooth lookup for MAC : None : False 
debug    bluetooth lookup for MAC : None : False 
debug    bluetooth lookup for MAC : None : False 
debug    bluetooth lookup for MAC : None : False 
debug    Transition is done
debug    Sensor - Checking command: 
debug    Waiting for connection
Write failed: Host is down

Allerdings nervt gerade auch mein Handy rum und meint öfter mal "gehen" zu wollen:

Code: Alles auswählen

debug    ..:..:..:..:..:48 is first time no seen. Loop : 14
...
debug    ..:..:..:..:..:48 is first time no seen. Loop : 1

Morgen ...


Viele Grüße,

elvthg

[marius.jaworowski@gmail.com]

Hallo elvthg,

Glückwunsch, du hast einen Bug gefunden!
Das System hat immer, wenn es das Handy nicht mehr gesehen hat, einen Zähler hoch gezählt. Diesen aber nicht zurückgesetzt wenn das Handy zwischendurch wieder erreichbar war.

Dein Problem mit dem WLAN hat das ganze noch verstärkt.

Bitte Installier die Version "1.3.6" die diesen Fehler nicht mehr hat.

Diese Problem mit den Pi0 habe ich auch. Die WLAN Verbindung bricht immer wieder Grundlos ab. Noch schlimmer war es als ich eine Multicast Anwendung über das WLAN verwendet haben, dabei wurde das ganze WLAN in die Knie gezogen. Ich nutze Enterprise WLAN Komponenten sowie Fluke AirMagnet Analyse Tools, konnte aber das Problem bisher nicht lokalisieren.

Um aber auf deine Frage einzugehen:
Bei der Entwicklung habe ich darüber nachgedacht ob es einen praktischen Nutzen gibt zu unterscheiden welcher Sensor mich sieht und welcher nicht. Zum damaligen Zeitpunkt ist mir aber nichts eingefallen. Momentan schmeisse ich alle Ergebnisse der Sensoren einfach in die Funktion "accumulate_sensor_data()" rein. Natürlich kann mann das aber erweitern.
Was ist deine Idee hierfür?

[elvthg]

Hallo Marius,

Glückwunsch, du hast einen Bug gefunden!
Das System hat immer, wenn es das Handy nicht mehr gesehen hat, einen Zähler hoch gezählt. Diesen aber nicht zurückgesetzt wenn das Handy zwischendurch wieder erreichbar war.

Dein Problem mit dem WLAN hat das ganze noch verstärkt.

Bitte Installier die Version "1.3.6" die diesen Fehler nicht mehr hat.

die habe ich nun auf dem Pi3 installiert und teste die, bin mal gespannt ob sie nun tut.

Gestern Nacht habe ich den Raspi irgendwann abgeschaltet, weil er immer meinte "geht", "geht nicht", "geht", "geht nicht" ...

Diese Problem mit den Pi0 habe ich auch. Die WLAN Verbindung bricht immer wieder Grundlos ab. Noch schlimmer war es als ich eine Multicast Anwendung über das WLAN verwendet haben, dabei wurde das ganze WLAN in die Knie gezogen. Ich nutze Enterprise WLAN Komponenten sowie Fluke AirMagnet Analyse Tools, konnte aber das Problem bisher nicht lokalisieren.

Ich tendiere dazu zu behaupten, das sich WLAN und BT vom Pi0 auf den 2,4 GHz "bekriegen", denn solange ich nichts mit BT mache, läuft das WLAN völlig stressfrei. Sieht also so aus, als ob ich mir einen kleinen 5 GHz-Stick kaufen müsste um darüber die Netzwerkanbindung zu machen. Alternativ ginge auch ein USB-Netzwerkadapter, aber da wo ich "hin will", wäre das eher suboptimal.

Um aber auf deine Frage einzugehen:
Bei der Entwicklung habe ich darüber nachgedacht ob es einen praktischen Nutzen gibt zu unterscheiden welcher Sensor mich sieht und welcher nicht. Zum damaligen Zeitpunkt ist mir aber nichts eingefallen. Momentan schmeisse ich alle Ergebnisse der Sensoren einfach in die Funktion "accumulate_sensor_data()" rein. Natürlich kann mann das aber erweitern.
Was ist deine Idee hierfür?

Man kann damit Aktionen zu unterschiedlichen Zeitpunkten auslösen, wenn man die Sensoren "geschickt" verteilt. So reagiert z.B. ein an der Tür/Fenster angebrachter Sensor viel früher wenn man von draußen kommt, als der, der zentral in der Wohnung/Haus aufgestellt ist. Zudem könnte man auch die Bewegungsrichtung erkennen, je nachdem welcher Sensor zuerst anspricht.

Bissel "doof" ist gerade, das Spot mein Handy nicht finden will, obwohl btctl sage, das es da sein:

Code: Alles auswählen

root@pi3:/# bluetoothctl
[NEW] Controller ..:..:..:..:..:16 pi3 [default]
[NEW] Device ..:..:..:..:..:72 PR102
[NEW] Device ..:..:..:..:..:48 HandyTG
...
[NEW] Device ..:..:..:..:..:7F Flower care

[bluetooth]# scan on
Discovery started
[CHG] Controller ..:..:..:..:..:16 Discovering: yes
...
[NEW] Device ..:..:..:..:..:34 Flower care
[CHG] Device ..:..:..:..:..:48 RSSI: -82
[CHG] Device ..:..:..:..:..:7F Connected: yes
[NEW] Device ..:..:..:..:..:13 Flower care
...
[CHG] Device ..:..:..:..:..:7F Connected: no
[bluetooth]# pair ..:..:..:..:..:48
Attempting to pair with ..:..:..:..:..:48
Failed to pair: org.bluez.Error.AlreadyExists

Weder ein Handy noch ein Pi3-Neustart habe da geholfen.

Code: Alles auswählen

debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 20.0 s
debug    Rediscovering Sensor and devices. Loop : 1
debug    Connecting to the CCU to get device list : 10.20.30.25
debug    sending broadcast to discover the sensors
debug    1 sensors discovered : {'10.20.30.29': '10002 '}
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 20.0 s
...
debug    going sleep for 20.0 s
...
debug    going sleep for 20.0 s
...
debug    going sleep for 20.0 s
...
debug    going sleep for 20.0 s
...
debug    going sleep for 20.0 s
debug    ..:..:..:..:..:53 remains unavailable
debug    ..:..:..:..:..:B1 remains unavailable
debug    ..:..:..:..:..:48 remains unavailable
debug    ..:..:..:..:..:9A remains unavailable
debug    ..:..:..:..:..:1F remains unavailable
debug    ..:..:..:..:..:72 remains unavailable
debug    0 of 6 are in the coverage of Spot
debug    going sleep for 20.0 s
...

Muss ich also nochmal suchen.

PS: Könnte es sein, das der Pi0 dem Pi3 das Handy "klaut", auch wenn da z.Z. Spot nicht läuft? Oder können beide Pi's unabhängig voneinander das gleiche Gerät erkennen?


Vielen Dank,

viele Grüße, elvthg