Bluetooth Low Energy DevIO?

Begonnen von dominik, 08 September 2019, 11:58:58

Vorheriges Thema - Nächstes Thema

dominik

Hallo,

nachdem mehr und mehr Geräte mit Bluetooth LE auf den Markt kommen, würde ich es für sinnvoll erachten, wenn es ein BLE IO Device gäbe. Damit würde sich der Entwicklungsaufwand pro Device um einiges reduzieren.

Leider konnte ich aber bisher keine BLE Library für Perl finden. Eventuell wäre BLE2MQTT eine Möglichkeit, nur konnte ich da auch noch keine fertige Lösung für einen RPi finden.

Ich hatte bisher in meinen Modulen immer direkt die gatttool Binary per Blockingcall ausgeführt. Schöner wäre natürlich eine aktive Connection zum BLE Device aufrecht zu erhalten.

Was meint ihr?
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

CoolTux

Wäre auf jeden Fall super. Ist leider nicht ganz einfach.
Jörg und ich haben uns mal vor 2 Jahren dran versucht. Würde aber mangels Zeit liegen gelassen. Ich selbst habe mich vor einem Jahr noch mal versucht, aber auch hier war die Zeit Schuld daran das nicht passiert ist.
Ich habe mir als Basis das lepresenced Skript angeschaut. Mit hat die darin enthaltene Idee gefallen. Dann hätte man einen laufenden von FHEM unabhängigen Serverdienst.
Ein IO Modul in FHEM würde dann mit diesen Serverdienst kommunizieren.
Soweit meine Idee.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dominik

In meinem letzten Modul habe ich Expect verwendet, das ist ziemlich cool, weil dann kann man das interaktive gatttool Interface offen lassen und dort ueber die laufende Connection Commandos schicken.
Siehe: https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/10_GFPROBT.pm

Meine Idee waere nun, das interaktive Gatttool zu nutzen und ein IO Device zu bauen welches mit der interaktiven Connection laufend kommuniziert.

Oder man baut einen separaten Server in Python/NodeJS welcher nur BLE2MQTT macht und komplett unabhaengig von FHEM ist. Waere auch eine Idee und wahrscheinlich einfacher handhabbar. Wir sind mit Perl mittlerweile echt ziemlich eingeschraenkt. Wir muessen uns Gedanken ueber ein NodeJS und Python Binding fuer neue Module machen, sonst werden wir ueber kurz oder lang Probleme mit einer schnellen Entwicklung haben.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

CoolTux

Expect war mein aller erster Ansatz so 2017 rum.

Etwas in Python oder NodeJS zu machen finde ich nicht gut. FHEM ist Perl und solange es Möglichkeiten gibt sollten wir in Perl bleiben. Ich möchte als User nicht gezwungen werden extra Zeug zu installieren wenn ich es nicht wirklich brauche.

Wieso sind wir mit Perl eingeschränkt?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dominik

Aus welchen Grund hattest du Expect dann wieder verworfen? Weil um mehrere Characteristics auszulesen, geht das mit Expect mit einem connect, bei gatttool wird jedes mal wieder neu verbunden was dann wieder laenger dauert.

Vielleicht ist jedoch BLE2MQTT der leichtere Weg? Da koennte man auf Basis der ESP32 Implementierung starten und dann Devices auf MQTT Basis implementieren.

Offtopic:
Zu Perl...bei neuen Technologien findet man auf CPAN kaum mehr Module und muss viel selbst entwickeln. Mit NodeJS geht das um einiges schneller. Fuer das GOOGLECAST Modul musste ich auch auf pychromecast (Python) zugreifen um nicht alles selbst zu machen. Bei NodeJS findet man sogar noch mehr Chromecast Implementierungen.
Google Assistant, Alexa und Siri sind ebenfalls ueber NodeJS integriert. Ich denke mit NodeJS oder Python Bindings koennten wir die Community um einiges groesser machen und fuer uns die Modulentwicklung ebenfalls vereinfachen.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

justme1968

um einen externen prozess am laufen zu halten und ständig mit ihm zu kommunizieren braucht man weder expect noch irgend welche anderen module/libraries/tools. das geht mit fhem bordmitteln. z.b. mit CoProcess.pm das für alexa, google assitant, tradfri und demnächst für homekit verwendet wird. systat verwendet so etwas und auch das plex modul kommuniziert extensiv über mehrere sockets und devices.

weder die kommunikation im netzwerk noch mit externen nrogrammen braucht 'neue technologien'. und mqtt ist oft nur ein schlagwort hinter dem heisse luft oder andere abhängigkeiten stehen. wie es hier helfen könnte verstehe ich nicht. diese eine zentrale stelle könnte dann auch verhindern das mehrere module gleichzeitig versuchen zu funken und sich in die quere kommen.


wenn es ein externes tool gibt das alle anforderungen erfüllt spricht absolut nichts dagegen es zu verwenden. andererseits gibt es keinen grund 10 externe libraries einzubinden wenn man über ein socket oder stdio kommunizieren möchte.

bei solchen diskussionen ist es wichtig zwischen dem protokoll (je nach komplexität lohnt es nicht nicht hier etwas neu zu erfinden) und der implementieren in fhem (um ein 'telnet' socket zu verwenden braucht es keine lib) zu unterscheiden.


das alles gesagt: was genau meinst du mit bindings? ich denke in alexa-fhem, homebridge-fhem und google assistant findest du alles was zur kommunikation mit fhem nötig ist. das könnte man extrahieren und analog zu CoProcess eigenständig verfügbar machen.

ein solches allgemeines bluetooth io sollte meiner meinung so wenig externe abhängigkeiten wie möglich haben. gattool über einen externen prozess und/oder einen dämon direkt ansteuern wäre meiner meinung nach der richtige weg.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Und was spricht im extrem Fall dagegen etwas mehr Energie rein zu stecken und eine Perl Bibliothek zu schreiben. Wie gesagt im Fall von es gibt sonst nichts. Wenn keiner mehr solche Bibliotheken schreibt in Perl ist es kein Wunder das Perl keine Rolle mehr spielt. Eine solche Bibliothek wäre dann nicht nur für FHEM sondern kann auch bei CPAN angeboten werden  ;) Aber das ist bestimmt wenn dann der extrem Fall. Ich stimme Andre zu.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

KölnSolar

Zitatwürde ich es für sinnvoll erachten, wenn es ein BLE IO Device gäbe
Find ich gut. Kann nichts dazu beitragen.
Zitatin Python/NodeJS welcher nur BLE2MQTT macht und komplett unabhaengig von FHEM ist.
Find ich schlecht.
Zitatbei neuen Technologien findet man auf CPAN kaum mehr Module und muss viel selbst entwickeln.
Damit hast Du zwar Recht, aber ich sehe da sonst nur Probleme auf uns zukommen
1. komplizierte Installation für den "einfachen" Enduser
2. kein Support, Weiterentwicklung durch die FHEM community möglich, da blackbox
3. weniger Sicherheit, da die Blackbox ungeprüft ist(in Perl guckt der ein oder andere in den Code des Moduls)
.
.

Grüße Markus
<OT> Kümmerst Du Dich um DLNARenderer gar nicht mehr ? <OT>
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

dominik

@Andre
CoProcess kann auch STDIN schreiben und STDOUT lesen? Das wusste ich noch nicht. Dann koennte man ja damit sogar ein DevIO bauen.

Bei BLE hat MQTT den Vorteil, dass man dann sofort weitere Strecken ueberwinden kann. Auf jedem Device das man fuer die Verlaengerung der Funkstrecke benoetigt FHEM installieren zu muessen macht wenig Sinn - wie z.B. mit einem ESP32.

Mit Bindings meine ich die Moeglichkeit zu schaffen auch ueber NodeJS oder Python FHEM Module zu bauen. Also eine Modul API fuer NodeJS/Python.

@Markus
Mit NodeJS und Python koennte man dann genauso Module bauen. Beides sind Scriptsprachen, daher ebenfalls offen und lesbar. Blackbox ist das keine.
DLNARenderer: Ich habe schon laenger daran nichts mehr gemacht, funktioniert etwas grundsaetzlich nicht? Wenn ja, bitte einfach kurze PN dazu.
fhempy -  https://github.com/fhempy/fhempy: GoogleCast, Tuya, UPnP, Ring, EQ3BT, Nespresso, Xiaomi, Spotify, Object Detection, ...
Kaffeespende: https://paypal.me/todominik

justme1968

ZitatCoProcess kann auch STDIN schreiben und STDOUT lesen? Das wusste ich noch nicht. Dann koennte man ja damit sogar ein DevIO bauen.

das ist eine der haupt anwendungen dafür :). schau hier: https://wiki.fhem.de/wiki/CoProcess und wie CoProcess für alexa-fhem verwendet wird. das alexa modul wertet stdout des externen prozesses aus. die gegenrichtung geht über websocket/longpoll. für tradfri/tradfri-fhem geht es in beiden richtungen per stdio. auch remote über einen anderen host per ssh.


ZitatBei BLE hat MQTT den Vorteil, dass man dann sofort weitere Strecken ueberwinden kann.
nein. das ist genau das was ich gemeint habe. nicht protokoll und netzwerk vermischen. das man weite strecken überwinden kann liegt nicht an mqtt sondern wlan/ethernet. wenn man mqtt über bluetooth oder 868mhz macht nützt das protokoll an sich erst mal garnichts um mehr als eine hand voll meter zu kommen. andererseits kann man jedes beliebige protokoll über wlan/ethernet machen und hat fast beliebige reichweite.

ZitatAuf jedem Device das man fuer die Verlaengerung der Funkstrecke benoetigt FHEM installieren zu muessen macht wenig Sinn - wie z.B. mit einem ESP32.
. das muss man doch garnicht. das CoProcess beispiel von oben geht z.b. auch per ssh über jeden beliebigen rechner ohne das fhem drauf läuft. nur der jeweilige i/o Prozess muss drauf laufen. in unserem fall wäre das z.b. gattool. wenn du bluetooth empfangen willst brauchst du zwingend ein bluetoth empfänger in reichweite bei le mehrere pro haus. da ändert auch mqtt nichts dran. und mit einem esp32 würde ich da garnicht dran gehen. ein raspberry zero w kosten kaum mehr und hat mit linux den vorteil das es tatsächlich alle möglichen tools gibt. nicht nur einzelne spezial lösungen wie für den esp.

Mit Bindings meine ich die Moeglichkeit zu schaffen auch ueber NodeJS oder Python FHEM Module zu bauen. Also eine Modul API fuer NodeJS/Python.die module selber würde ich immer in perl lassen. die möglichkeiten der integration mit fhem sind hier unschlagbar. aber bestimmte dinge auslagern geht doch jetzt schon problemlos. siehe CoProcess und dessen anwendungen.

Zitat1. komplizierte Installation für den "einfachen" Enduser
nicht unbedingt. wenn man alle siri, alexa, google home und tradfri anwender zusammen zählt haben die meisten keine Probleme und die auftretenden probleme liegen meist an zerschossenen installationen. im grossen und ganzen ist es nicht viel schlimmer als direkt in fhem. und mit dem npmjs modul und Meta.pm lässt sich die installation und die aktualisierung recht gut unterstützen und automatisieren.


off topic: der dlna renderer würde glaube ich profitieren wenn man keine externe dlna lib verwendet sondern alles mit fhem mitteln und non blocking erledigt. für das automatische erkennen der gerate bin ich an dem hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 dran. dauert aber leider noch etwas. die info zu den erkannten geräten (auch zur laufzeit hinzu gekommene) soll sich ausser für das autocreate auch für andere module auswerten lassen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

KölnSolar

Zitatdaher ebenfalls offen und lesbar. Blackbox ist das keine.
Na ja, schon. Es geht ja um die Codeschnipsel aus GitHub etc. Ich z.B. kämpfe gerade mit der Installation eines PythonSkript(ich kann kein Python), um es zum Laufen zu bringen. Dabei ist mein Ziel das Skript zu verstehen und die notwendigen rudimentären Elemente dann in ein FHEM-Perl-Modul zu packen. Nur einfach "benutzt" ist es eine Blackbox eines FHEM-Fremden. Die Installation kann man einem Enduser auch nicht zumuten. python2, python, python3.7, pip2, pip3.7, pipenv.....  :o

<OT>Guck mal in Deinen DLNARenderer-Thread. Da gibt es bestimmt 200 Beiträge, die Du nicht kennst. Ich hatte da vor über einem Jahr eine Weiterentwicklung für Samsung-Geräte gemacht. Ich wollte Dir schon vorschlagen das Modul zu übernehmen, weil Du Dich im Thread nie gemeldet hast. Ich hab nur das Problem, dass ich außer Samsung-devices keine Geräte zum testen habe. Vielleicht betreuen wir das Modul zukünftig gemeinsam ? Alles weitere machen wir dann aber wirklich per PN oder im DLNA-Thread.  ;)<OT>
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt