Anwesenheitserkennung Bluetooth PebbleBee

[Mitch]

@Steffen: da ist schon mal was:
gruss
  andre

Ne, das passt schon, ist der Bluetooth Dienst ansich.

Insgesamt passt das eigentlich schon.

[Steffen]

@Steffen: da ist schon mal was:
gruss
  andre

Ok habe mal den Prozess beendet(sudo kill 2242) aber dann bleibt es ständig "absent" aber muss dann was damit zu tun haben oder?!

Mfg Steffen

[Mitch]

Kannst es sein, dass dein Tag sich auch nur sporadisch meldet?

Wenn Du im fhem presenced disablest und hcitool lescan in der shell startest, lass das doch mal so 10 bis 15 sek. laufen und schau, wie oft und wie sich der Tag meldet.
Die PebbleBee senden ca. alle 500ms einen "Ping", kontinuierlich.

Evtl. hat Dein Kensing auch das Security Feature, seine Adresse zu wechseln (oder eines der anderen)?

Mach doch auch mal ein hcitool lewladd (Add device to LE White List).

Du kannst auch mal mit hcitool lecc (Create a LE Connection) versuchem, dich mit dem Tag zu verbinden.

[justme1968]

wenn sich dein tag nicht dauern meldet musst du noch --duplicates hinter den aufruf hängen.

gruss
  andre

[Markus Bloch]

guten morgen

die idee die integration anders und besser zu machen ist gut.

das HttpUtils beispiel ist es aber auf den zweiten blick glaube ich nicht weil es wichtige unterschiede gibt: ein HttpUtils aufruf bearbeitet eine anfrage mit einer definierten antwortlänge und liefert diese auf ein mal zurück. die antwort ist (meist) für ein fhem device bestimmt.

beim lescan sollte es normalerweise keinen kill geben und der callback würde unterm strich zu einer readFn.

der aufruf darf auch nur ein mal zentral und nicht durch jedes (logische) presence device erfolgen weil sich das hcitool nur ein mal gleichzeitig (pro dongle) aufrufen lässt. die auswertung würde dann eher per parse und dispatch erfolgen.

Und genau hier sehe ich ein Problem. Wie ihr bereits festgestellt habt, kann ein Bluetooth Dongle nur seriell von einem einzigen Programm benutzt werden. Wenn man nun einen hcitool lescan starten würde, der über ein HCITOOL Modul an PRESENCE dispatcht, würde dieser Dongle voll belegt sein und könnte nicht von weiteren PRESENCE Definitionen (local-bluetooth) verwendet werden. In PRESENCE ist dazu extra eine Prozesserkennung eingebaut, die sicher stellt, dass nur ein einziger hcitool Aufruf bei mehreren PRESENCE Definitionen läuft.

Wenn man nun den hcitool lescan kontrolliert startet und nach einem festen Timeout wieder beendet, würde der Bluetooth-Dongle auch nachwievor allen anderen PRESENCE local-bluetooth Definitionen zur Verfügung stehen um z.B noch das eigene Handy zu prüfen, usw.

je generischer man das jetzt aber macht um so unhandlicher wird es für den endanwender weil er sie clients und match listen konfigurieren müsste.

wie wäre es trozdem genau hier anzusetzen aber zumindest die schnittstelle nicht genetisch zu implementieren sondern genau auf den anwendungsfall zugeschnitten:

aus dem aktuellen PRESENCED wird ein hcitool modul. das bekommt die möglichkeit wahlweise lescan oder scan auszuführen. bei scan auf jeden fall mit timeout und für lescan optional auch statt der duplicates option. hier könnte man auch abwechselnd scan und lescan aufrufen um mit einem  dongle beides abzudecken.

dieses modul sammelt alle bluetoth devices in der nähe und bekommt ein get um die aktuell gesehene device liste mit namen auszuspucken. das würde auch das problem lösen die adresse eines neuen tag zu finden.

PRESENCE bekommt eine dispatch funktion die vom hcitool modul aufgerufen wird. ein tag das in reichweite kommt könnte (optional)  sofort auf present gehen ohne den presence timeout abzuwarten. es wäre nur noch der absence timeout nötig.

das lescan modul könne per autocreate direkt das passende presence device erzeugen wenn ein pairForSec parameter gesetzt wird. d.h. ein neuer tag wird dann nur kurz in die nähe gebracht und ist als device in fhem bekannt.

Das finde ich aus Endanwendersicht allerdings komplizierter. Man muss erstmal eine HCITOOL Instanz definieren. Viele User werden mit dem Begriff nichts anzufangen wissen, bzw. wofür hcitool überhaupt gedacht ist. Dann werden durch autocreate haufenweise Definitionen erzeugt (evtl. auch vom Nachbarn), wo man die ungewünschten Definitionen mit attr dummy 1 erstmal wieder deaktivieren muss. Desweiteren währe es nicht möglich hcitool lescan für BT-Tags und hcitool name für die reguläre BT Erkennung von Handys auf einem System zu kombinieren, da das Bluetooth device dauerhaft durch hcitool lescan belegt ist. Der User brauch also mind. 2 Dongles, dazu kommen dann wieder die ganzen Fragen im Forum: "Wieso geht die Erkennung mit Bluetooth nicht, ich hab doch einen Bluetooth Stick installiert? ..."

Ich finde es so, wie es bisher ist (eine Definition pro Device mit Device Adresse) für den Enduser am einfachsten und am logischsten, da es sich letztenendes auch nur um ein Gerät handelt (BT-Tag oder Handy,...). Alle PRESENCE Definitionen stellen untereinander sicher, dass nur ein hcitool Befehl zur gleichen Zeit läuft (so wie es bereits auch der Fall ist). Einen hcitool lescan würde ich gerne so wie du es demonstriert hast über eine ausgelagerte Funktion realisieren, die ein Non-Blocking Shell-Execution erlaubt.

Vorteil:
- Ich kann alle anderen PRESENCE Modis auf diese Funktion umstellen, und es gibt keine Probleme mehr mit BlockingCall, telnet Zugriff Fehler und korrupte FD's
- Speicherverbrauch bei kleinen Systemen sinkt, da kein Fork mehr erforderlich ist.
- Rudi sieht BlockingCall eh nicht als permanente Lösung, dein Vorschlag mit selectlist könnte man als eine gute Variante nehmen.

eventuell kann man später auch noch eine geschickte integration mit den roommate modulen einbauen.

die multiroom fähigkeit von collectord würde ich aber gerne erhalten bzw. auch hier erreichen.

Da stimme ich dir zu, das wäre dann aber ein nachgelagerter Schritt.

vielleicht kann man das konzept das scannen und cachen von bresence zu trennen auch auf andere bereiche erweitern die mehrere geräte in einem rutsch liefern. mir fällt gerade spontan die snmp/mac überwachung ein und vielleicht das regelmäßige scannen eines ganzen netzwerks oder teils. beides könnte man dann mit einem ein mal geforkten script mit endlosschleife tun und nicht immer wieder neu per BlockingCall

Das wäre ein guter Anwendungsfall für eine solche neue NonBlocking-Shell-Exec Funktion. Es muss ja nicht umbedingt ein Kill nach x Sekunden geben. Dazu eine Funktion (ähnlich wie bei HttpUtils NonBlocking) , die die Daten entgegen nimmt und entsprechend in FHEM einpflegt.

Wenn ich die Zeit hätte, hätte ich eine solche Funktion längst als Patch in FHEM Development vorgestellt

Viele Grüße

Markus

[Steffen]

wenn sich dein tag nicht dauern meldet musst du noch --duplicates hinter den aufruf hängen.

gruss
  andre

Hallo!

Also über die shell --duplicates bekomme ich im sekunden Tag die meldung vom Tag, ohne --duplicates bekomme ich nur eine meldung und dann keine weitere!
Die Mac und Name bleibt auch immer gleich!
Aber trotzdem bekomme ich im interval von Presence immer ein absent<>present, verstehe nicht wieso!
Was mir noch auf gefallen ist das im Presenced bei PARTIAL ist die mac oder name oft abgehackt so zum beispiel: "09:07:98", vielleicht ist das der Fehler?!
Der Cubi hat ja ein eigenes Bluetooth modul vielleicht stört das ja auch?

Mfg Steffen

[justme1968]

ich glaube du hast ein paar dinge in meinem post übersehen

was ich versucht habe zu beschreiben ist unter anderem die lösung für das problem das sich der usb dongle nur ein mal mit lescan öffnen lässt. es gibt eine zentrale instanz die das starten und stoppen und das umschalten zwischen den scan und lescan erledigt (so lange das noch nötig ist. siehe die idee mit dem hci socket). diese zentrale Instanz habe ich mal LESCAN genannt. das ist erst mal völlig unabhängig davon ob das ein eigenes modul oder nur ein bestimmter mode von PRESENCE ist. das wichtige ist diese instanz sollte nur ein mal laufen und das so permanent wie möglich. ohne kill wenn es irgendwie geht. ob man es den benutzer von extra definieren lässt (das ist vermutlich spätestens dann nötig wenn er tatsächlich mehr als einen dongle ansprechen will) oder ob man dafür sorgt das es automatisch angelegt wird sobald es ein device gibt das ihn benötigt ist ist vielleicht geschmacksache. ich glaube aber das die anwender durchaus damit klar kommen wenn man es erklärt. die trennung wäre wie bei jedem andere fhem rf modem: cul, hmlan, jeelink, hue bridge. es gibt ein zentrales device das die resource verwaltet und mehrere clients.

wenn die die resourcen verwaltung in die clients verschiebst ist der aufwand deutlich größer und du hast probleme weil die einzelnen clients unabhängig sind und auch unabhängige Intervalle haben. was willst du tun wenn ein PRESENCD device noch scannt aber der timeout in einem anderen abläuft und es jetzt eigentlich dran wäre? vor allem ist es im lescan gar nicht nötig etwas zu beenden wenn das scannen ein einziges mal zentral gemacht wird und sich die clients nur bedienen. die möglichkeit ganz ohne timeout und pollen sofort auf  ein device zu reagieren hast du auch nur mit einem scann der permanent läuft.

achtung: das mit dem resourcenverbrauch stimmt so nicht. hier ist ein non blocking shell aufruf nicht prinzipiell anders als ein BlockingCall. es wird genau so geforkt. es ist nur mehr versteckt. es gibt auch die gleichen potentiellen probleme (deshalb ist es eigentlich sinnvoll für die endgültige implementierung nicht einfach das perl open zu verwenden sondern es selber lösen um direkt nach dem fork erst mal wie gehabt alles zu schliessen. siehe sanbox modul). die shell ist danach ein eigener prozess der parallel läuft. der unterschied liegt nur in der kommunikation mit diesem geforkten prozess. im BlockingCall fall wird sie antwort gesammelt und nach beenden ein mal zurück gegeben. im diesem fall wird die antwort kontinuierlich direkt zurück gegeben. wenn du immer wieder killst verschenkst die genau diesen vorteil das kontinuierlich etwas läuft.

die zwei ersten vorteile die du anführst gibt es also garnicht.

lass uns das bitte so weit diskutieren bis das konzept klar ist und wir beide vom gleichen reden. ich glaube ein in fhem integrierter presenced der nicht gekillt wird so lange es nicht unumgänglich ist hat viele vorteile und wäre für features wie sofort reagieren und rssi werte sogar unabdingbar.

eine funktion wie du sie dir vorstellst habe ich in der sandbox idee schon gebaut. ich komme aber gerade nicht dazu das fertig zu machen. der generische fall ist aber deutlich komplizierter als es auf den ersten blick ausschaut bzw. hat viel mehr randbedingungen als das was wir hier gerade brauchen.

der dritte vorteil das rudi BlockingCall nicht wirklich mag und lieber per readFn und Parse/Dispatch arbeitet wäre damit automatisch gegeben.

gruss
  andre

[justme1968]

@steffen: hast du die --duplicates option auch im modul aktiv? siehst du das der gestartete prozess diese option hat?

das modul sollte die abgehackten teile automatisch zusammenbauen. das sollte da eigentlich nur so kurz stehen das es gar nicht zu sehen ist.

hast du zusätzlich zur eingebauten hardware noch einen anderen dingle angesteckt?

wenn du ein list auf das PRESENCED device machst solltest du bei den internals sehen das der timestamps hinter der mac im gleichen takt wie die meldungen hoch gezählt werden.

gruß
  andre 

[Mitch]

Der Cubi hat ja ein eigenes Bluetooth modul vielleicht stört das ja auch?

Das würde ich mal abschalten, bzw. geht Dein Modul evtl. auf hci0 und das ist das eingebaute Modul?
Dann hast Du wahrscheinlich noch ein hci1, welches du für das Modul benutzen musst.

[Steffen]

@steffen: hast du die --duplicates option auch im modul aktiv? siehst du das der gestartete prozess diese option hat?

das modul sollte die abgehackten teile automatisch zusammenbauen. das sollte da eigentlich nur so kurz stehen das es gar nicht zu sehen ist.

hast du zusätzlich zur eingebauten hardware noch einen anderen dingle angesteckt?

wenn du ein list auf das PRESENCED device machst solltest du bei den internals sehen das der timestamps hinter der mac im gleichen takt wie die meldungen hoch gezählt werden.

gruß
  andre

Hallo!

Also bin zum Test nochmal mit den gleichem "Einzigen" BlueStick auf meinem Pi umgezogen um Fehler Quellen vom Cubi aus zu schließen,
aber auch hier auf dem Pi das gleiche "absent<>present"!

Ich stelle hier jetzt einmal alle Informationen zusammen, vielleicht sieht ja jemand wo bestimmt der "kleinste Fehler aller Zeiten" ist...

auf pi fhem "list pd"

Code Auswählen Erweitern


Internals:
   CMD        sudo -u root /usr/bin/hcitool lescan --duplicates
   CONNECTS   1
   DEF        sudo -u root /usr/bin/hcitool lescan --duplicates
   FD         5
   LAST_CONNECT 2014-11-26 08:59:16
   NAME       pd
   NR         20
   NTFY_ORDER 50-pd
   PARTIAL    D0:FF:50:7A:24:08
   PID        2194
   STATE      Connected
   TYPE       PRESENCED
   Helper:
     Devices:
       D0:FF:50:7A:24:08 1417000337
       LE         1416988863
Attributes:


auf pi list Blue:

Code Auswählen Erweitern


Internals:
   ADDRESS    D0:FF:50:7A:24:08
   DEF        local-PRESENCED D0:FF:50:7A:24:08
   MODE       local-PRESENCED
   NAME       Blue
   NR         21
   STATE      present
   TIMEOUT_NORMAL 30
   TIMEOUT_PRESENT 30
   TYPE       PRESENCE
   Readings:
     2014-11-26 12:34:29   state           present
   Helper:
Attributes:

Internals:
   ADDRESS    D0:FF:50:7A:24:08
   DEF        local-PRESENCED D0:FF:50:7A:24:08
   MODE       local-PRESENCED
   NAME       Blue
   NR         21
   STATE      absent
   TIMEOUT_NORMAL 30
   TIMEOUT_PRESENT 30
   TYPE       PRESENCE
   Readings:
     2014-11-26 12:34:59   state           absent
   Helper:
Attributes:


fhem cfg:

Code Auswählen Erweitern


define pd PRESENCED sudo -u root /usr/bin/hcitool lescan --duplicates
define Blue PRESENCE local-PRESENCED D0:FF:50:7A:24:08


modul 73_Presenced.pm:

Code Auswählen Erweitern


# $Id: 73_PRESENCED.pm 4756 2014-01-27 21:15:50Z justme1968 $

my $cmd = join( " ", @a[2..@a-1]);
  $cmd = "sudo -u root /usr/bin/hcitool lescan --duplicates" if( !$cmd );


auf pi shell:

Code Auswählen Erweitern


root@raspberrypi:~# ps -ax
warning: bad ps syntax, perhaps a bogus '-'?
See http://gitorious.org/procps/procps/blobs/master/Documentation/FAQ
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:02 init [2]
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:05 [ksoftirqd/0]
    4 ?        S      0:00 [kworker/0:0]
    5 ?        S<     0:00 [kworker/0:0H]
    6 ?        S      0:01 [kworker/u2:0]
    7 ?        S      0:02 [rcu_preempt]
    8 ?        S      0:00 [rcu_bh]
    9 ?        S      0:00 [rcu_sched]
   10 ?        S<     0:00 [khelper]
   11 ?        S      0:00 [kdevtmpfs]
   12 ?        S<     0:00 [netns]
   13 ?        S<     0:00 [writeback]
   14 ?        S<     0:00 [bioset]
   15 ?        S<     0:00 [crypto]
   16 ?        S<     0:00 [kblockd]
   17 ?        S      0:00 [khubd]
   18 ?        S      0:00 [kworker/0:1]
   19 ?        S<     0:00 [rpciod]
   20 ?        S      0:00 [khungtaskd]
   21 ?        S      0:00 [kswapd0]
   22 ?        S      0:00 [fsnotify_mark]
   23 ?        S<     0:00 [nfsiod]
   29 ?        S<     0:00 [kthrotld]
   30 ?        S<     0:00 [VCHIQ-0]
   31 ?        S<     0:00 [VCHIQr-0]
   32 ?        S<     0:00 [VCHIQs-0]
   33 ?        S<     0:00 [iscsi_eh]
   34 ?        S<     0:00 [dwc_otg]
   35 ?        S<     0:00 [DWC Notificatio]
   37 ?        S<     0:00 [deferwq]
   38 ?        S      0:00 [kworker/u2:2]
   39 ?        S      2:54 [mmcqd/0]
   40 ?        S      0:10 [jbd2/mmcblk0p2-]
   41 ?        S<     0:00 [ext4-rsv-conver]
  156 ?        Ss     0:00 udevd --daemon
  296 ?        S      0:00 udevd --daemon
  308 ?        S      0:00 udevd --daemon
  320 ?        S<     0:00 [kworker/u3:0]
  322 ?        S<     0:00 [hci0]
  323 ?        S<     0:00 [hci0]
  325 ?        S<     0:02 [kworker/u3:2]
1582 ?        S      0:08 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I
1618 ?        S      0:01 /usr/sbin/ifplugd -i lo -q -f -u0 -d10 -w -I
1899 ?        Ss     0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
1953 ?        Sl     0:00 /usr/sbin/rsyslogd -c5
2000 ?        Ss     0:00 /usr/sbin/cron
2030 ?        Ss     0:06 /usr/bin/dbus-daemon --system
2031 ?        S      0:13 perl fhem.pl fhem.cfg
2036 ?        Ss     0:00 startpar -f -- fhem
2057 ?        Ss     0:58 /usr/sbin/bluetoothd
2066 ?        S<     0:00 [krfcommd]
2110 ?        Ss     0:02 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104
2146 ?        Ss     0:00 /usr/sbin/sshd
2174 ?        Ss     0:00 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/run/thd.pid --user nob
2185 tty1     Ss+    0:00 /sbin/getty --noclear 38400 tty1
2186 tty2     Ss+    0:00 /sbin/getty 38400 tty2
2187 tty3     Ss+    0:00 /sbin/getty 38400 tty3
2188 tty4     Ss+    0:00 /sbin/getty 38400 tty4
2189 tty5     Ss+    0:00 /sbin/getty 38400 tty5
2190 tty6     Ss+    0:00 /sbin/getty 38400 tty6
2191 ttyAMA0  Ss+    0:00 /sbin/getty -L ttyAMA0 115200 vt100
2194 ?        S      0:00 sudo -u root /usr/bin/hcitool lescan --duplicates
2195 ?        S      0:01 /usr/bin/hcitool lescan --duplicates
2217 ?        Ss     0:00 sshd: root@pts/0
2221 pts/0    Ss     0:00 -bash
2242 pts/0    R+     0:00 ps -ax


lescan ca.2min

Code Auswählen Erweitern


root@raspberrypi:~# sudo hcitool lescan
LE Scan ...
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408



lescan --duplicates ca.30sek.

Code Auswählen Erweitern


^Croot@raspberrypi:~# sudo hcitool lescan --duplicates
LE Scan ...
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408
D0:FF:50:7A:24:08 (unknown)
D0:FF:50:7A:24:08 Kensington Eureka 2408


Mfg Steffen

[Markus Bloch]

ich glaube du hast ein paar dinge in meinem post übersehen

was ich versucht habe zu beschreiben ist unter anderem die lösung für das problem das sich der usb dongle nur ein mal mit lescan öffnen lässt. es gibt eine zentrale instanz die das starten und stoppen und das umschalten zwischen den scan und lescan erledigt (so lange das noch nötig ist. siehe die idee mit dem hci socket). diese zentrale Instanz habe ich mal LESCAN genannt. das ist erst mal völlig unabhängig davon ob das ein eigenes modul oder nur ein bestimmter mode von PRESENCE ist. das wichtige ist diese instanz sollte nur ein mal laufen und das so permanent wie möglich. ohne kill wenn es irgendwie geht. ob man es den benutzer von extra definieren lässt (das ist vermutlich spätestens dann nötig wenn er tatsächlich mehr als einen dongle ansprechen will) oder ob man dafür sorgt das es automatisch angelegt wird sobald es ein device gibt das ihn benötigt ist ist vielleicht geschmacksache. ich glaube aber das die anwender durchaus damit klar kommen wenn man es erklärt. die trennung wäre wie bei jedem andere fhem rf modem: cul, hmlan, jeelink, hue bridge. es gibt ein zentrales device das die resource verwaltet und mehrere clients.

wenn die die resourcen verwaltung in die clients verschiebst ist der aufwand deutlich größer und du hast probleme weil die einzelnen clients unabhängig sind und auch unabhängige Intervalle haben. was willst du tun wenn ein PRESENCD device noch scannt aber der timeout in einem anderen abläuft und es jetzt eigentlich dran wäre? vor allem ist es im lescan gar nicht nötig etwas zu beenden wenn das scannen ein einziges mal zentral gemacht wird und sich die clients nur bedienen. die möglichkeit ganz ohne timeout und pollen sofort auf  ein device zu reagieren hast du auch nur mit einem scann der permanent läuft.

Angenommen wir würden das so umsetzen, da haben wir dann für 2 verschiedene Bluetooth Geräteklassen 2 völlig unterschiedliche Konzepte:

- Handys: werden durch direkte Definition einer PRESENCE Instanz überwacht. Alle Definitionen verwenden einen BT-Dongle gemeinesam. Pro Handy eine einzige PRESENCE Definition, die on-the-fly sofort out-of-the-box läuft (sorry für das Bullshit-Bingo )
- BT-Tags: benötigen eine zentrale Instanz, die mit dem BT-Dongle kommuniziert (über "hcitool lescan"). Es werden alle Devices (egal ob es die eigenen sind, oder nicht) sofort angelegt, sobald sie vom hcitool ausgespuckt werden (Dispatch-Fn). Aufgrund dessen, dass der BT-Dongle aber dauerhaft in Benutzung ist, können keine normalen Handys mehr überwacht werden, da der hcitool Prozess dauerhaft den Dongle belegt. Der User kann den Dongle auch nicht für andere Sachen verwenden, oder auf der Kommandozeile mal eben was testen.

Beides sind zwei völlig unterschiedliche Konzepte, die auch für den User gegenüber dem gewohnten sich stark unterscheiden. Ich möchte einfach vermeiden, dass wir für ein und die selbe Sache (Anwesenheitserkennung via Bluetooth) hier zwei völlig verschiedene Konzepte fahren, die sich nur darin unterscheiden, ob es BT Low-Energy ist, oder normales Bluetooth. Ich halte es nicht für richtig hier für so etwas einen völlig anderen Ansatz zu wählen, als bisher, nur weil das hcitool so nicht immer gekillt werden muss. Das ist dem User doch völlig egal.

achtung: das mit dem resourcenverbrauch stimmt so nicht. hier ist ein non blocking shell aufruf nicht prinzipiell anders als ein BlockingCall. es wird genau so geforkt. es ist nur mehr versteckt. es gibt auch die gleichen potentiellen probleme (deshalb ist es eigentlich sinnvoll für die endgültige implementierung nicht einfach das perl open zu verwenden sondern es selber lösen um direkt nach dem fork erst mal wie gehabt alles zu schliessen. siehe sanbox modul). die shell ist danach ein eigener prozess der parallel läuft. der unterschied liegt nur in der kommunikation mit diesem geforkten prozess. im BlockingCall fall wird sie antwort gesammelt und nach beenden ein mal zurück gegeben. im diesem fall wird die antwort kontinuierlich direkt zurück gegeben. wenn du immer wieder killst verschenkst die genau diesen vorteil das kontinuierlich etwas läuft.

die zwei ersten vorteile die du anführst gibt es also garnicht.

Diese Aussage kann ich leider nicht nachvollziehen. Wo wird denn bitte der FHEM Hauptprozess geforkt, wenn du einen Shell-Befehl so ausführst, wie du es Anfangs vorgeschlagen hast (mit open öffnen und in $selectlist hängen, usw.) Ich persönlich finde diese Variante bedeutend sauberer (wenn sie als Modulfunktion zur Verfügung steht), als einen BlockingCall, wo anschließend alle FD's geschlossen werden müssen und bei einem shutdown noch die Child-Prozesse geprüft werden müssen.

lass uns das bitte so weit diskutieren bis das konzept klar ist und wir beide vom gleichen reden. ich glaube ein in fhem integrierter presenced der nicht gekillt wird so lange es nicht unumgänglich ist hat viele vorteile und wäre für features wie sofort reagieren und rssi werte sogar unabdingbar.

Da bin ich auch völlig bei Dir. Die Vorteile von presenced der nicht gekillt wird bringt aber beim Thema rssi ein Problem mit sich. Den RSSI bekommst durch den Aufruf von "hcitool lecc/lecup/ledc". Genauso auch all die verschiedenen LE Kommandos für die Konfiguration der Whitelist usw. Diese Kommandos kannst du aber nicht ausführen, weil ja dein PRESENCED Modul den BT-Dongle blockiert. Wie willst du also den RSSI auslesen, wenn dein "hcitool lescan" dauerhaft läuft.

eine funktion wie du sie dir vorstellst habe ich in der sandbox idee schon gebaut. ich komme aber gerade nicht dazu das fertig zu machen. der generische fall ist aber deutlich komplizierter als es auf den ersten blick ausschaut bzw. hat viel mehr randbedingungen als das was wir hier gerade brauchen.

Das hört sich doch super an. Das ganze muss doch jetzt auch nicht sofort all-umfassend sein. Ich würde mich erstmal auf die offensichtlichen Funktionalitäten beschränken (non-blocking execution mit selectlist, optionaler Kill-Timer, evtl. ein Regexp Filter um den Output vorzufiltern, bevor er an die Parse-Funktion übergeben wird.

Tut mir leid, wenn ich nicht jeden Tag antworten kann. Ich lese aber zumindest mit.

Viele Grüße

Markus

[justme1968]

die idee ist nicht beide geräteklassen unterschiedlich zu behandeln sondern den lescan nicht in das alte konzept zu zwängen sondern statt dessen beides mit dem neuen konzept zu machen.

es soll auch hinterher alles out of the box laufen und im einfachen fall muss und soll der anwender nichts von der geänderten infrastruktur dahinter erkennen. erst

ich glaube aber das man den zugriff auf den dongle nicht völlig verstecken kann. zumindest nicht so lange man irgendetwas forkt. wenn zum beispiel gerade ein 'altes' presence device den dongle belegt hat kann man auf der kommando zeile auch nicht einfach ein lescan starten um etwas zu testen. man müsste jedes einzelne PRESENCE device das bluetooth verwendet deaktivieren. wenn es eine zentrale stelle gibt muss man nur an dieser einen stelle etwas deaktivieren.

diese eine zentrale stelle kann je nach bedarf nur den lescan dauerhaft laufen haben (mit den neuen features wie rssi und sofrtigem melden) oder nur den normalen scan laufen lassen oder dazwischen umschalten oder auch zwei oder mehr dongle ansprechen. alles an einer stelle zentral. für die anwender soll sich nichts in der einfachen bedienung ändern. es gibt nur mehr features.

es soll auch nicht jedes device automatisch angelegt werden. mit der zentralen stelle gibt es aber die möglichkeit dazu das halb automatisch zu tun. z.b. per liste der devices die sichtbar sind aus der man dann auswählen kann. wenn es für den anwender so einfach wie möglich sein soll ist auch das rausfinden der mac adresse eine hürde die man damit umgehen kann. ein 'show devices' und 'create xxx' würde hier schon weiter helfen.

also nicht zwei konzepte und auch nicht die le devices in das alte konzept pressen sondern beides gemeinsam in einem neuen konzept verbinden.

abgesehen davonist es glaube ich sinnvoll ganz auf den scan zu verzichten und das hci socket direkt von fhem aus anzusprechen. eventuell kann man dann sogar beide device typen mit einem dongle erschlagen.


der fhem hauptprozess wird immer dann geforkt wenn auf irgend eine art und weise ein anderes binary gestartet wird. auf systemebene gibt es keinen prinzipiellen unterschied zwischen BlockingCall, einem qx/system/... aufruf, einem open aufruf mit io redirection auf ein binary oder der der sandbox implementierung. es ist im kern immer ein aufruf von fork mit anschliessendem exec. das ist (von einer optimierung) abgesehen immer der weg einen anderen prozess zu starten. unterschiede gibt es nur in der art des io zwischen parent und child. der resourcenverbrauch ist immer identisch. vorher ein prozess danach zwei. bei allen arten muss man an irgendeiner stelle alle nicht benötigten filedescriptoren schliessen sond gibt es die bekannten probleme. das einzige das tatsächlich einfluss auf die verbrauchten resourcen hat ist so wenig wie möglich zu forken. wenn es geht nur ein mal und mit dem child 'live' zu komunizieren und nicht wie bei BlockingCall erst nach dem beenden.


nach meinem stand ist es möglich die rssi werte gleichzeitig mti dem lescan zu bestimmen. es werden nur zwei filedescriptoren in die select list gehängt und beide bedient.

auch hier ist es eventuell direkter das hci socket zu verwenden und direkt alles an der quelle abzuholen. ich vermute das dann auch der le devices und konventionelle devices gleichzeitig zu erkennen sind.


ich glaube das der selectlist teil nicht die eigentliche herausforderung ist. sondern das konzept 'alte' und neue devices unter einen hut zu bringen. so weit es nur geht ohne etwas immer wieder zu killen. der selectlist und readFn teil ist ein ist wirklich das kleinste dabei.

das ganze in zwei logische komponenten aufzuteilen die per dispatch/parse miteinander kommunizieren hat wirklich vorteile. nicht zuletzt die möglichkeit die teile auch auf unterschiedlichen rechner zu verteilen. und man kann das einbauen ohne den nachteil von zwei modulen an den endanwender weiterzugeben.

ich würde gerne für die weitere diskussion ein paar dinge ausprobieren. dazu gehört der wechselweise aufruf der beiden scan arten in einer zentralen instanz, das gleichzeitige auslesen der rssi werte und ob es mit dem hci socket möglich ist beide device typen gleichzeitig zu sehen. ich muss nur etwas umbauen und einen hub in betrieb nehmen und das estimote ibeacon finden. schon peinlich ein beacon nicht zu finden...

gruss
  andre

[Markus Bloch]

Nunja, das ganze würde funktionieren, wenn man denke ich versucht, direkt das BT Device anzusprechen, ohne hcitool Kommando, oder evtl. mit einem Perl Modul, was sowas anbietet.

Meiner Erfahrung nach ist es aber nicht möglich einen hcitool Befehl laufen zu lassen und während der läuft einen weiteren hcitool Befehl zu starten. In einem solchen Fall kommt dann keinerlei Ausgabe, da es sich ja um serielle Kommunikation mit dem Dongle handelt.

[fh168]

Welchen BT-Stick verwendet ihr? Kann man das eingebaute BT vom Cubietruck 3 nehmen?

LG
/robin

[volschin]

Nunja, das ganze würde funktionieren, wenn man denke ich versucht, direkt das BT Device anzusprechen, ohne hcitool Kommando, oder evtl. mit einem Perl Modul, was sowas anbietet.

Würde da

Code Auswählen Erweitern

sudo apt-get install libnet-bluetooth-perl
als Basis helfen?

Gruß
Veit