Raspberry Pi als Beacon Scanner für Gigaset G-Tags - Reloaded

Hallo miteinander,

ich habe lange versucht ein sehr zuverlässiges System für die Anwesenheitssteuerung zu finden. Es gibt hier im Forum verschiedene Ansätze um Beacons zu nutzen. Die Scripte sind teilweise einige Jahre alt und ich wollte das hier nochmal zusammenfassen.

Danke an @TomW für die Hilfe und fürs Teilen seiner Scripte.

Mehr Infos gibts vor allem hier:
https://www.symcon.de/forum/threads/30936-Raspberry-Pi-als-iBeacon-Scanner-f%C3%BCr-Schl%C3%BCsselbunddongle/page8?highlight=Beacon

Das Konzept sieht bei mir so aus, dass ich mehrere Pis (am liebsten Zero W) einsetze, um nach den G-Tags zu scannen. Auf diesen Pis läuft ein Script, welches im Hintergrund in Echtzeit alle G-Tags sieht. Das Script wird zusätzlich jede Minute als cronjob neu gestartet um festzustellen, ob der Dienst noch läuft und sich für den Fall, dass das nicht so ist, neu zu starten. Das ist dann notwendig, wenn der Empfänger nicht erreichbar ist, also unser Symcon System.

Es gibt zwei Möglichkeiten. Entweder man installiert auf den Scanner Pis auch Symcon und schickt die Ausgabe an 127.0.0.1 also localhost oder eben an jeden anderen Empfänger im Netzwerk. Die Ausgabe an das Haupt Symcon System zu senden empfiehlt sich nicht, denn es kommen bei meinen 5 Tags ca. 300 000 Meldungen pro Tag an. Das macht das ganze etwas unübersichtlich wenn man andere Meldungen erkennen möchte. Für Symcon selbst wäre das natürlich kein Problem.

Mein Setup sieht im Moment 4 Scanner vor. Auf diesen läuft nur das Script und diese schicken ihre Meldungen an ein Symcon System, welches nur für den Empfang und die Verwaltung der Tags verantwortlich ist. Dieses überträgt bei Änderung dann den Status der Anwesenheit an mein Hauptsystem. Dieses Scanner Empfangs Symcon kann natürlich auf einem der Scanner Pis laufen.

Jetzt gehts los:

Pi mit integriertem Wlan und Bluetooth LE. Also ab 3B. Bestens geeignet Zero W.
Raspbian Buster, Upgrades, Mit eigenem Wlan verbinden und per SSH erreichbar machen.

Anlegen eines init Scripts:

sudo nano /etc/init.d/BLEScan

#! /bin/sh
### BEGIN INIT INFO
# Provides: skeleton
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: BLE Scanner by DarthWeber
# Description:
### END INIT INFO
 
case "$1" in
    start)
        echo "BLEScan wird gestartet"
        var=`ps -eaf | grep BLEscan0 | wc -l`
        if [ $var -lt "2" ]; then
                su - root -c "/usr/local/bin/BLEscan0.sh&"
        else
                echo "BLEscan0 läuft bereits - Bus:"`hciconfig hci0 | grep Bus | cut -d " " -f5`
        fi
         ;;
    stop)
        echo "BLEScan wird beendet"
        # Beende Programm
        killall BLEscan0.sh
        killall hcitool
        ;;
    restart)
        echo "BLEScan wird beendet"
        killall BLEscan0.sh
        killall hcitool
        echo "BLEScan wird gestartet"
        # Starte Programm
        su - root -c "/usr/local/bin/BLEscan0.sh&"
        ;;
    status)
        var=`ps -eaf | grep BLEscan0 | wc -l`
        if [ $var -lt "2" ]; then
                echo "Error - BLEscan0 läuft nicht"
        else
                echo "OK - BLEscan0 läuft - Bus:"`hciconfig hci0 | grep Bus | cut -d " " -f5`
        fi
        ;;
    *)
        echo "Benutzt: /etc/init.d/BLEScan {start|stop|status}"
        exit 1
        ;;
esac
 
exit 0

ausführbar machen
sudo chmod +x /etc/init.d/BLEScan

Das Script welches scannt anlegen. Hier muss man sich nun die Ziel IP Adresse des Scanner Empfangs Symcon eintragen. Ausserdem ist es wichtig, für jeden Scanner einen eigenen beliebigen ID zu vergeben, so kann man später unterscheiden, welcher Scanner den G-Tag gesehen hat. In dem Beispiel ist die Ziel IP Adresse 192.168.1.20 und der ID des Scanners ist ble1

sudo nano /usr/local/bin/BLEscan0.sh

#!/bin/bash
# BLEscan0.sh
hciconfig hci0 down > /dev/null && hciconfig hci0 up > /dev/null
if [ $? = 0 ]; then
   stdbuf -i0 -o0 -e0 hcitool -i hci0 lescan --duplicates | grep --line-buffered "Giga" | sed -u 's/^/ble1 /' > /dev/udp/192.168.1.20/8173
else
   echo "hci0 Error" > /dev/udp/192.168.1.20/8173
fi

wieder ausführbar machen
sudo chmod +x /usr/local/bin/BLEscan0.sh

Gestartet wird der Dienst dann per
sudo /etc/init.d/BLEScan start

stop und restart und status gehen auch. Der Empfänger ist aber im Moment noch nicht erreichbar. Deshalb wird da gleich ERROR als status angezeigt.

Jetzt noch in den crontab mit minütlicher Ausführung
sudo crontab -e

Unten die Zeile einfügen:

          • /etc/init.d/BLEScan start

Speichern. Fertig mit den bash Scripten auf dem Sende Pi.

Der Empfang in Symcon:

I/O Instanzen. Neue Instanz. Multicast Socket
Sendehost: bei mir steht da localhost, spielt aber keine Rolle, es kommt von überall her an.
Sendeport: 8173
Empfänger Host: die IP Adresse des Symcon Scanner Empfangsystems oder All. Das ist das auf dem ihr gerade arbeitet.
Empfangsport: 8173

Socket öffnen

Den Rest so lassen. Änderungen übernehmen.

Damit empfängt Symcon die Nachrichten des Scanners. Wenn ihr jetzt auf dem Sende Pi den Dienst startet oder diesen rebootet, könnt ihr im Debug Fenster die Nachrichten sehen.

Weiter geht es mit einer Register Variable. Diese verarbeitet die eingehenden Nachrichten. Da mein Empfangs Symcon jungfräulich ist, erstelle ich die Register Variable im Hauptverzeichnis und die folgenden Scripte alle unterhalb der Variable. Das hat den Vorteil, dass man sehr einfach die IDs nach Namen bei gleichem Parent finden kann.

IP-Symcon, Hinzufügen Instanz, Register Variable

Diese wird erstellt, kann aber nicht gespeichert werden, solange kein Script hinterlegt ist. Also zurück zum Objektbaum und unterhalb der erstellten Register Variable ein script erstellen. Das Script legt entsprechend der vergebenen Namen Variablen für die Tags an. Unterhalb der Variablen wird eine weitere Variable pro Scanner angelegt. Diese heisst wie der Scanner (ihr erinnert euch an die ID die ihr im Scanner Script vergeben solltet?) und enthält den timestamp des letzten Empfangs. Praktisch für eine watchdog Funktion oder zum Auswerten eines bestimmten Scanners.

Name register

<?php

$s = IPS_GetScript(IPS_GetObjectIDByName ('Tags', IPS_GetParent($_IPS['SELF'])));
include($s['ScriptFile']);

$Verzeichnis = IPS_GetParent($_IPS['SELF']);   
 

function CheckMacs($Data)  {
  global $Macs;  
  $Returnvalue = Array();
  $Returnvalue[0]=false; 
  foreach($Macs as $Name => $Address) 
    {
      $pos = strpos($Data,$Address);
      if ($pos === false) continue;
      $Returnvalue[0]=true;
      $Returnvalue[1]=$Name;
      $Returnvalue[2]=substr($Data,0,4);
    }
  return $Returnvalue;  
}  // end function CheckMacs

function CreateVar($Path,$Name,$Typ) {
    global $Verzeichnis;
    $Id = @IPS_GetVariableIDByName($Name,$Path);
	
   if ($Id === false)
	{
	  $Id=IPS_CreateVariable($Typ); 
	  IPS_SetParent($Id,$Path);
	  IPS_SetName($Id,$Name);
    }
	return $Id;
}

if ($_IPS['SENDER'] == 'RegisterVariable')
  {
     $str = $_IPS['VALUE'];   
     $R = CheckMacs($str); 
   
     if ($R[0] === true ) 
       { 
         $id = CreateVar($Verzeichnis,$R[1],0);
         SetValue($id,true);   
         $idx = CreateVar($id,$R[2],1);
         SetValue($idx,time());     
       }


  }


?>

Speichern und zurück zur Register Variable. Dort das Script register als Ziel auswählen. Dann oben unter Gateway ändern unseren vorhin erstellen Mulitcast Socket auswählen. Änderungen übernehmen.

Damit das register Script weiss, nach was es suchen muss legen wir wieder unterhalb der Register Variable ein weiteres Script an mit dem Namen

Tags

<?php

$Macs = Array(
    'Buzz2' => '58:9E:C6:0E:EC:6F',
    'Buzz' => '58:9E:C6:0E:EE:3F',
    'Elli' => '58:9E:C6:0E:EF:68',
    'Car2' => '58:9E:C6:0E:ED:53',
    'Car1' => '58:9E:C6:0E:EC:CB'
    );

?>  

Jetzt sollten Eure Tags angelegt werden. Falls ihr die MAC Adressen eurer Tags nicht kennt, könnt ihr diese im Debug Fenster des Mulicast Socket sehen. Dazu stellt ihr von HEX auf Text um.

Damit diese auch auf abwesend gesetzt werden, brauchen wir ein weiteres Script. Hier sind zwei Minuten eingestellt und ich rufe das Script mit einem Timer alle 30s auf. Das ist aber natürlich beliebig.

Wieder unterhalb der Register Variable
Name setfalse

<?php
$now = time();
$s = IPS_GetScript(IPS_GetObjectIDByName ('Tags', IPS_GetParent($_IPS['SELF'])));
    include($s['ScriptFile']);

function setfalse()
{
global $Macs, $now;
foreach($Macs as $Name => $Address) 
    {  
     $eins=GetValue(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])));
     $eins_info = IPS_GetVariable(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])));
     $time_eins =  $eins_info["VariableUpdated"];
     if ($now - $time_eins > 120) if (GetValue(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])))) SetValue(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])),false);      
    }

}    

setfalse();

?>

Damit sollte alles laufen.

Die Übertragung ins Hauptsystem mache ich per webhook. Das ist im ursprünglichen Thread sehr gut erklärt. Gleich auf der ersten Seite.

Hier mein Script dazu. Der Webhook muss natürlich im Hauptsystem eingerichtet werden und zwar für jeden Beacon. Dazu die passende Variable und ein hook Script darunter. Damit das script funktioniert, müssen die hooks im Empfanhssystem so aussehen:

/hook/Buzz
also /hook/‚Name des Tags‘ so wie er im Script Tags hinterlegt wurde.

Wieder unterhalb der Register Variable
webhhook

<?php
$now = time();
$s = IPS_GetScript(IPS_GetObjectIDByName ('Tags', IPS_GetParent($_IPS['SELF'])));
    include($s['ScriptFile']);

function webhook()
{
global $Macs, $now;
foreach($Macs as $Name => $Address) 
    {
      $status = GetValue(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])));
       $string = "http://192.168.1.21:3777/hook/{$Name}?Status={$status}";
     file_get_contents($string);
    }

}    

webhook();

?>

Auf der Empfangsseite sieht mein Script unterhalb der Empfangsvariablen so aus

hook

<?

if ($_GET['Status'] == 1)
{
SetValue(IPS_GetParent($_IPS['SELF']), true);
}
if ($_GET['Status'] == 0)
{
SetValue(IPS_GetParent($_IPS['SELF']), false);
}

?>

Viel Spass und danke an alle für die großartige Vorarbeit!

Sebastian

Leider kann ich kein Modul schreiben, aber hier wären meine Gedanken dazu.

Die Scanner Pis werden wie gehabt angelegt. Mit der Scanner ID und der Empfangs IP Adresse.

Ich stelle mir ein Modul im Haupt Symcon System vor. Also kein extra System für die vielen Meldungen.

Das Modul legt den Socket und die Register Variable an, unterdrückt aber die eingehenden Meldungen. Behält diese nur für sich und wertet diese aus.

In einem Formular trägt man den Namen und die MAC Adresse der Tags ein. Vielleicht könnte das Modul auch unbekannte Tags in einem Debug Fenster zeigen, damit man einfach neue hinzufügen kann.
Außerdem gibt es ein Feld fürs Zeitintervall bis zum abwesend setzen.
Es gibt ein weiteres Feld für die ID des Parent Verzeichnis unter dem dann automatisch die Variablen angelegt werden. Unterhalb dieser Variablen wie gehabt die Scanner Ids mit timestamp.

Sebastian

Hi Sebastian,

den Watchdog brauchst du eigentlich nicht. Mein BLEScan script prüft beim Start, ob der Dienst bereits läuft - und startet nur in diesem Fall neu.

Du kannst also einfach in deiner cronatb das BLEScan minütlich starten, dann prüft es sich selbst jede Minute und startet ggf. neu:

          • root /etc/init.d/BLEScan start

Das war bei meinem RasPi leider auch notwendig, denn zumindest der Dienst am externen hci1 BT Dongle schmiert aller paar Stunden ab, so stört das aber nicht sonderlich. Der interne hci0 ist bei mir da deutlich stabiler.

Damit ist auch das „update-rc.d BLEScan defaults“ obselet (ich wußte das letzte Woche noch nicht)

Vielleicht kannst du das oben in deiner Beschreibung noch aufnehmen ?

Ich bastel gerade daran, alles in einem python script aufzunehmen und per mqtt durchzureichen, damit bräuchte man insgesamt nur noch ein script…

Hab ich erledigt.

Es gibt schon ein Python Script hier im Forum, von 2017. Kann man die Verwaltung der Tags dann trotzdem in symcon machen? Der Scanner Pi schickt alles durch und Symcon regelt den Rest?
Veränderungen in Symcon sind immer leicht, weil zentral durchführbar. Alle Pis umstellen ist da aufwendiger.

Gruss Sebastian

Theoretisch ja, bzw. genau so wie mit dem shell Script von mir, es muss halt eben auch die Daten per socket oder mqtt durchreichen. Hast du einen Link ?

Hallo Leute,

motiviert durch diesen Thread habe ich mir auch mal so ein Gigaset-G-Tags-Set bestellt. Noch ist es nicht da, denke aber schon jetzt über eine möglichst einfache Umsetzung nach. Aus IP-Symcon-Seite wäre das mit Sicherheit ein Modul, wofür ich mich gerne bereit erkläre das mal anzugehen, was mir aber fehlt ist das Wissen wie man es auf der Raspberry-Seite am Besten umsetzt, d.h. mit möglichst wenig Konfigurationsaufwand (aktueller Anspruch: Raspberry Pi-seitig einmalig installieren, Rest macht das Modul).

Wenn sich also einer bereit erklärt, dass in Aufgabenteilung mit mir anzugehen, so bitte ich um Nachricht…

Joachim

Hi,

Unter raspbian ist soweit alles installiert. „hcitool lescan“ und schon geht es los

Traxanos hat mal ein modul gemacht, heisst symconbtp wird aber nicht weiterentwickelt, vielleicht kannst du das als Vorlage nehmen ?

Hab das gestern abend mal mit dem obigen Script umgesetzt, symconseitig gehe ich einen etwas anderen weg. Hab einen trackee von chipolo ubd einen raspberry zero w, die Reichweite ist aber damit nicht so prall. Vielleicht 5-10m.

Am chipolo liegt es nicht, am Handy geht eine etage.

Viele grüsse

Gesendet von meinem EML-L29 mit Tapatalk

Das ist doch eigentlich in deinem GPIO Modul mit dem BT Teil schon drin.

Etwas mehr als fünf oder für jeden gefundenen BT eine Instanz wäre schön.

Hallo Ralf,

das charmante an dieser Lösung finde ich eigentlich, dass der Weg hier andersherum läuft. Bei meinem GPIO-Modul triggert IPS auf dem einen verbundenen Gerät diesen Prozess, hier arbeiten die n Raspberry Pi quasi autark. n ist dabei variabel (einer der Vorteile) und kann möglicherweise auch Rückschlüsse auf den Standort geben.
Was mir wichtig wäre damit es die einzelnen Nutzer möglichst einfach bei der Installation haben, dass es nur wenig manueller Aktivitäten auf dem Pi erforderlich sind. Im Idealfall kann die Applikation auf dem Pi sogar vom IPS Steuerungsbefehle annehmen.

Ich bin für solche eine Applikation auf dem Pi nicht wirklich der Profi, habe in einem anderen Projekt aber sehr positive Erfahrungen bei einer solchen Aufgabenteilung gemacht - man muss sich lediglich über die Schnittstellen austauschen…

Joachim

Hi,

ich hatte ursprünglich auf den Scanner Pis das Script laufen als Dienst und das hat an mein zentrales Symcon geschickt. Das hat sich nicht bewährt. Wenn das symcon System mal nicht erreichbar war (reboot, Wlan), gingen natürlich Telegramme verloren und bei kurzer Abwesenheit eines Tags sind blöde Sachen passiert.
Aktuell läuft bei mir auf jedem Scanner Pi Symcon. Die Scanner Pis schauen bei jeder Änderung eines Tags auf dem zentralen Symcon System nach, ob der Status für alle Tags stimmt und übertragen diesen bei Bedarf für alle Tags neu. Dafür habe ich ein Image und das ist auf jedem Pi gleich.
Vom zentralen Symcon setzte ich über die IP Adresse den Hostnamen und alle Parameter die ich ändere. Damit haben die ScannerPis keine Wartung.

Sebastian
Senden:

<?php

$remote_verzeichnis=29017;
$rpc = new JSONRPC("http:/user:ferzugriffPW@IP-AdresseHauptSymcon:3777/api/");

$s = IPS_GetScript(IPS_GetObjectIDByName ('Tags', IPS_GetParent($_IPS['SELF'])));
    include($s['ScriptFile']);
$scanner_name=GetValue(56455);

foreach($Macs as $Name => $Address) 
    {   
     $status=GetValue(IPS_GetObjectIDByName ($Name, IPS_GetParent($_IPS['SELF'])));
     try { 
         $remote_id_parent= $rpc->IPS_GetObjectIDByName($Name,$remote_verzeichnis);
    } catch (JSONRPCException $e) {
         $remote_id_parent= $rpc->IPS_CreateVariable(0);
         $rpc->IPS_SetParent($remote_id_parent,$remote_verzeichnis);
	     $rpc->IPS_SetName($remote_id_parent,$Name);
    }
    try { 
         $remote_id = $rpc->IPS_GetObjectIDByName($scanner_name,$remote_id_parent);
    } catch (JSONRPCException $e) {
         $remote_id= $rpc->IPS_CreateVariable(0);
         $rpc->IPS_SetParent($remote_id,$remote_id_parent);
	     $rpc->IPS_SetName($remote_id,$scanner_name);
    }
     $remote_status = $rpc->GetValue($remote_id);
     if ($remote_status != $status) $rpc->SetValue($remote_id,$status);
    }
    

Setzen der Parameter von zentral:

<?php
$scanner = array(
    'ble1' => '10.99.76.221',
    'ble2' => '10.99.76.222',
    'ble3' => '10.99.76.223',
    'ble4' => '10.99.76.224',
    'ble5' => '10.99.76.225',
    
);

$Macs = Array(
    'Buzz2' => '58:9E:xxxxxx',
    'Buzz' => '58:9E:xxxxxxxx',
    'Elli' => '58:9E:xxxxxxxx',
    'Car2' => '58:9E:xxxxxxxx',
    'Car1' => '58:9E:xxxxxxxx',
    'Franz' => '58:9E:xxxxxxxx'
    );


$Zeit_Abwesend = GetValue(IPS_GetVariableIDByName('Abwesend nach Sek', IPS_GetParent($_IPS['SELF'])));

foreach ($scanner as $Name => $Address)
{
$rpc = new JSONRPC("http://user:PW@$Address:3777/api/");
$parent = $rpc-> IPS_GetInstanceIDByName('Register Variable',0);
$remote_name = $rpc -> IPS_GetVariableIDByName('Name', 0);
$rpc-> SetValue($remote_name,$Name);
$remote_script_id = $rpc-> IPS_GetScriptIDByName('Tags',$parent);
$rpc->IPS_SetScriptContent($remote_script_id,$GetScript);
$remote_var_id = $rpc -> IPS_GetVariableIDByName('Abwesend nach Sek', 0);
$rpc -> SetValue($remote_var_id,$Zeit_Abwesend);
}

Hallo Buzz2912,

solche eine Lösung liegt eher nicht in meinem Fokus, m.E. zu viel Konfigurationsaufwand.

Ich denke, man könnte die beschriebene Situation auch im IPS-Modul abfangen, in dem man die sendenden Geräte (->IP) erfasst und parallel regelmäßig anpingt. Dann kann man auf eine negative Rückmeldung reagieren. Alles bisher nur Ideen, mir fehlen im Moment noch die Gigaset-G-Tags um es auszuprobieren.

Das eine oder andere Ereignis könnte man sicher zusätzlich noch abfangen, wenn das Skript auf dem Raspberry Pi etwas mehr Funktionalität bekommt. Gerade für diesen Part benötigen ich aber Unterstützung.
Ich habe jetzt erst einmal dass die im ersten Posting aufgezeigte Installationsschritte auf einem Raspberry Pi umgesetzt, damit kann man erst einmal starten. Bei einem Modul wie hier (I/O, Splitter, Devices, Konfigurator) besteht ja schon eine Menge Arbeit in der grundsätzlichen Konstruktion (Datenfluss, Konfigurationsformulare, Statusvariablen etc.) der eigentliche „funktionale“ Code ist da manchmal im Gesamtverhältnis der kleinere Teil…:wink:

Joachim

Hi,

ja das ist schon so. Allerdings ist der Aufwand nur einmalig.
Ich war auch Deiner Meinung, aber ohne eine lokale Symcon Intelligenz hatte ich nur Probleme.

Mein Vater verfolgt ebenfalls Deinen Weg. Er schreibt komplexe Python Scripte und kämpft mit eben genau den Problemen, dass die Stati nicht immer konsistent im zentralen System ankommen.

Ich bin mit meinem System extrem zufrieden. Falls Du Scripte oder ein ganzes Image willst, lass es mich wissen.

Sebastian

…was sind den die möglichen Gründe, warum der Status nicht korrekt übertragen wird? Eine Aufzählung könnte mir bei der Erstellung des Moduls eine wertvolle Hilfe sein…

Und wenn Dein Vater an dem Thema interessiert ist und eifrig dort Skripte schreibt: Vielleicht ist es ja der Beginn einer wundervollen Zusammenarbeit…:wink:

Joachim

Hi,

Ich habe in symcon das so gelöst, das meine Abwesenheitsvariable sich auf abwesend zurück setzt, wenn diese 5 sek. nicht aktualisiert wurde.

Die 5 sek. Sind natürlich beliebig, läuft auch bisher gut. Leider ist der chipolo tag komisch, sobald ich für hcitool „abwesend“ bin kann ich den chipolo nur noch wieder sichtbar mschen, wenn ich die batterie entferne und neu einsetze.

Hab mal gtags bestellt, mal sehen wie die laufen.

Viele Grüße

Gesendet von meinem EML-L29 mit Tapatalk

Hallo kris,

fünf Sekunden ist ja ganz schön sportlich. Mal sehen wie es sich gestaltet, wenn die Dinger endlich hier sind…

Ich habe mal eine Frage zu dem im ersten Posting dieses Threads:

stdbuf -i0 -o0 -e0 hcitool -i hci0 lescan --duplicates | grep --line-buffered "Giga" | sed -

Was macht diese Zeile im Code von /usr/local/bin/BLEscan0.sh? Insbesonder das „Giga“ darin?
Schließt es andere System damit quasi aus?

Joachim

Hi,

Ist ja nur zum testen. Will nicht solange warten wenn ich den raum verlasse. Später wird es im minutenbereich sein.

Grep sucht in der zeile nach dem wort giga. Du kannst auch nach den ersten drei bytes der mac adresse suchen. Die sollten gleich sein. So mach ich das weil die chipolos keinen namen ausgeben.

Hab mir aber auch mal einen esp32 mit wifi/bt bestellt. Autarkes devices und dann mqtt mit rein. Könnte mir gefallen.

Viele Grüße

Gesendet von meinem EML-L29 mit Tapatalk

Hallo Leute,

das Modul ist so weit erst einmal (I/O, Splitter, Configurator und Device-Instanz) „gebrauchsfertig“ (der eine oder andere Fehler wird wohl noch drin sein).

Link:
GitHub - Joey-1970/IPS2Beacons: Beacon-Integration für IP-Symcon

Es empfiehlt sich zunächst den Splitter zu installieren, danach den Configurator, daraus kann man dann bequem die Device-Instanzen erstellen.

Gegenüber der sehr guten Anleitung aus dem ersten Posting gibt es bei diesem Skript eine kleine Anpassung:

#!/bin/bash
# BLEscan0.sh
hciconfig hci0 down > /dev/null && hciconfig hci0 up > /dev/null
if [ $? = 0 ]; then
   stdbuf -i0 -o0 -e0 hcitool -i hci0 lescan --duplicates | grep --line-buffered "Giga" | sed -u 's/^//' > /dev/udp/192.168.1.20/8173
else
   echo "hci0 Error" > /dev/udp/192.168.1.20/8173
fi 

(Die Markierung „ble1“ ist verschwunden weil im Modul insofern nicht notwendig, da die IP des sendenden Gerätes erfasst wird.

Der Teil auf dem Raspberry Pi ist eher „try & error“, gerne würde ich hier noch das eine oder andere anpassen, ggf. wären auch Erweiterungen wie die Empfangsstärke möglich? Oder eine flexiblere Nutzung verschiedener Beacon? Da suche ich immer noch Unterstützung…:rolleyes:
Wäre toll wenn man auf der Seite noch etwas verbessern oder sogar erweitern könnte.

Joachim

Moin Joachim,

Empfangsstärke finde ich nicht sooo interessant, aber du kannst mit

gatttool -i hci0 -b xx:xx:xx:xx.xx;xx --char-read --handle=0x001b

noch den Batteriestatus abfragen, wenn du magst.Einzig Blöde an der Sache: Es legt u.U. die hcitool Abfrage lahm, wodurch es zur fehlerhaften Meldung kommt, wenn das nicht sauber abgefangen wird. Außerdem weiß ich nicht, ob diese Abfrage nicht auch den Batterieverbrauch erhöht - daher werfe ich die nur monatlich mal an, wenn der Sensor gerade in Reichweite ist. Das klappt auch nicht zuverlässig, also probiere ich dann so lange, bis ich einen Batteriestatus bekomme - dann schläft das script wieder für einen Monat…

Unterstützt dein Modul auch mehrere BT-Dongles ? Für mich wäre das wichtig, da ich damit sowohl die Garage als auch eine Haustür steuer. Klar, man kann einen zusätzlichen Zero nehmen - aber der Empfang mit BT und WLAN war bei mir deutlich schlechter als ein Raspi ohne WLAN, aber dafür mit externem BT Dongle. Damit komme ich auf Reichweiten bis zu 50m und einer Reaktionszeit von ca. 5s. Daher frage ich bei mir hci0 und hci1 ab, wobei gemein ist, dass der externe Dongle dann hci0 ist. Beim Ausfall des externen Sensors ist dann hci0 wieder der interne und hci1 tot - d.h. man kann sich nciht drauf verlassen, ob hci0 nun intern oder extern ist. Und für die Keute, die Reichweitenprobleme haben: Ich hatte immer Probleme bei aktiviertem WLAN und BT.

Noch ein kleiner Erfahrungsbericht: Die ganzen shell_exec Abfragen und/oder bash scripts aus php legten mein Produktiv-IPS immer mal wieder lahm, irgendwo klemmten php-skripte, die sich nicht mehr beenden ließen - daher habe ich die gesamte Anwesenheitserkennung auf einen 2.ten RasPi 3 ausgelagert. Komischerweise sind beide damit zufrieden und laufen jetzt seit einigen Jahren recht stabil.

LG,
Tom

Hallo Tom,

Du kannst n-Beacons (aktuell nur Gigaset) an n-Raspberry Pi betreiben, von daher volle Flexibilität. Die Skripte laufen ja auf den Clients, von daher wird aktuell keine shell_exec benötigt.
Das Prinzip finde ich gut da die wesentliche Arbeit auf den „externen“ Raspberry Pi stattfindet, daher würde ich diese gerne erweitern. Mir fehlt aber das Wissen.
Batteriestatus und weitere Information sollten nach Möglichkeit auch über diese Skripte ermittelt und dann an IPS gesendet werden, im Idealfall kann ich aus dem IPS diese Abfrage sogar antriggern.

Hoffe das sich da noch jemand findet…:wink:

Joachim

Hi Joachim - ich glaube, das ist doch mein Prinzip, oder ?

Ich habe einen RasPi3, an dem neben dem internen BT noch ein externer BT Dongle hängt. Der schickt dann die Presence-Meldungen mit UDP an mein Produktiv-IPS. Das BT des Produktiv-IPS nutze ich nicht.

Dieses sh Script mit dem Filter und udp und dem stdbuf hatte ich ursprünglich mal gemacht, da ich nicht wusste, wie ich Daten aus dem hcitool ins IPS kriege. Daher läuft das bei mir über 127.0.0.1, da ich das ganze Geplapper nicht im Netz haben wollte. Mittlerweile ist das ein eigenständiger Daemon geworden

Letztendlich läuft das gattttool natürlich auf dem Client-IPS, also dort, wo auch das BT ist. Das triggere ich dann natürlich aus dem Produktiv-IPS …