Hallo zusamen,
ich dachte ich melde mich mal wieder hier um euch über unsere neue Version 1.3.0 von Theengs Gateway (Linux/RPi und Windows) zu informieren, unsere Schwester-Applikation von OpenMQTTGateway.
https://gateway.theengs.io/
In der neuen Version haben wir die lokale Präsenzerkennung von Apple Watch, iPhone und iPad implementiert - und für alle anderen Geräten mit random changing Bluetooth MAC-Adressen, für die ein Identity Resolving Key bekannt ist.
Zusätzlich haben wir eine boolean unlocked Eigenschaft hinzugefügt, um sicherheitsrelevante Automationen nur starten zu können, wenn die Apple Geräte auch von einen autorisierten Benutzer entsperrt sind.
Da ich nicht weiß, ob FHEM auto-discovery unterstützt, hier Beispiel MQTT Nachrichten
{"id": "AA:BB:CC:DD:EE:FF", "rssi": -64, "brand": "Apple", "model": "Apple iPhone/iPad", "model_id": "APPLEDEVICE", "type": "TRACK", "unlocked": false}
{"id": "FF:EE:DD:CC:BB:AA", "rssi": -63, "brand": "Apple", "model": "Apple Watch", "model_id": "APPLEWATCH", "type": "BODY", "unlocked": true}
die mit der dann statischen MAC Addresse/id zu tracken sind.
Vielleicht ist das hier für einige von euch interessant.
Schöne Grüße vom Theengs/OpenMQTTGateway Team.
Liest sich sehr interessant.
Allerdings sieht das für mich sehr overpowert aus.
Ich mach anwesenheitserkennung mit esp32 und tasmota über BLE an Mii Band 6.
iPad und Handys nutz ich zwar auch, sind mir aber viel zu ungenau.
Mit den esps (die in all mein rolladen verbaut sind), kann ich relativ genau tracken wer wo im Haus ist.
Die systemlast ist auf viel esps verteilt und fällt somit kaum auf.
BTW. Ich glaub du bist im falschen Forums Teil. Mit mqtt hat das ja nur sekundär zu tun.
Ich glaube du vermischst da ein bisschen generelle Präsenzerkennung (Anwesenheitserkennung) und präzise Raum-Lokalisierung; letzteres würde ich auch mit ESP32s in jedem Raum machen, dann aber mit Radarsensoren an den ESPs, was genauer als jede Bluetooth Lösung ist.
AFAIK ist es mit dem Mi Band 6 ja auch so, dass es eine statische, immer gleichbleibende Bluetooth MAC Adresse hat, welche schon in genug Geschäften fürs Kundentracking verwendet wird und auch jedem interessierten Nachbarn, oder wem auch immer, die Anwesen- oder Abwesenheit ankündigt.
Ohne einen zusätzlichen Unlocked Sicherheitsstatus würde ich auch kein Gerät dafür verwenden, dass sich zum Beispiel meine Alarmanlage ausschaltet sobald ich mich der Haustür nähre ;)
Da Theengs Gateway alle Daten über MQTT sendet, sowie auch zusätzlich über 90 Sensoren erkennt, dekodiert und auch über MQTT bereit stellt, und OpenMQTTGateway - auf einem oder auch mehreren ESP32s - auch als Satelliten-Proxy über MQTT für die Präsenzerkennung und Sensorerkennung von Theengs Gateway eingesetzt werden kann, damit auch sehr große Gebäude abgedeckt werden können, dachte ich schon, dass die MQTT Sektion am besten passt.
Hallo DigiH,
ich habe das mal bei mir auf einem Raspi0 eingerichtet und recht schnell brauchbare Ergebnisse erhalten:
Internals:
CFGFN
CID fhem1
DEF fhem1
FUUID 65aab9c4-f33f-0fc1-aff9-0acd682517d96ea7
IODev mqtt2_client
LASTInputDev mqtt2_client
MSGCNT 90
NAME apple_watch.pre
NR 158
STATE ???
TYPE MQTT2_DEVICE
eventCount 104
mqtt2_client_MSGCNT 90
mqtt2_client_TIME 2024-01-19 19:10:29
OLDREADINGS:
READINGS:
2024-01-19 19:08:52 IODev mqtt2_client
2024-01-19 19:24:10 brand Apple
2024-01-19 19:26:05 distance 6.447880072893823
2024-01-19 19:24:10 id AC:88:FD:A4:8C:A4
2024-01-19 19:24:09 major 5
2024-01-19 19:25:13 manufacturerdata 4c0010050e982933a4
2024-01-19 19:14:09 mfid 4c00
2024-01-19 19:14:09 minor 0
2024-01-19 19:24:10 model Apple Watch
2024-01-19 19:24:10 model_id APPLEWATCH
2024-01-19 19:26:05 rssi -76
2024-01-19 19:25:13 track true
2024-01-19 19:24:10 type BODY
2024-01-19 19:08:41 unlocked true
2024-01-19 19:14:09 uuid 1ca92e23f0874df7b9a2fd4b716a4bf6
2024-01-19 19:14:09 volt 0.3
Attributes:
autocreate 0
devicetopic home/TheengsGateway/presence
event-on-change-reading .*
readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
room MQTT2_DEVICE
timestamp-on-change-reading .*
Der Einfachheit halber habe ich direkt das topic presence angesprochen.
Was ich nun erwarten würde wäre ein presence Reading. Presence ist laut python -m TheengsGateway.diagnose eingeschaltet:
{
"adapter": "",
"bindkeys": {},
"ble": 1,
"ble_scan_time": 5,
"ble_time_between_scans": 5,
"discovery": 1,
"discovery_device_name": "TheengsGateway",
"discovery_filter": [
"IBEACON"
],
"discovery_topic": "homeassistant",
"enable_tls": 0,
"enable_websocket": 0,
"hass_discovery": 1,
"host": "10.3.3.4",
"identities": {
"AC:88:FD:XX:XX:XX": "***"
},
"log_level": "INFO",
"lwt_topic": "home/TheengsGateway/LWT",
"pass": "***",
"port": 1883,
"presence": 1,
"presence_topic": "home/TheengsGateway/presence",
"publish_advdata": 1,
"publish_all": 1,
"publish_topic": "home/TheengsGateway/BTtoMQTT",
"scan_duration": 10,
"scanning_mode": "active",
"subscribe_topic": "home/+/BTtoMQTT/undecoded",
"time_format": 0,
"time_sync": [],
"tracker_timeout": 120,
"user": "***"
}
Wie komme ich also an ein presence Reading?
VG Sebastian
Hallo Sebastian,
ZitatWie komme ich also an ein presence Reading?
Hier muss ich leider zugeben, dass ich mit FHEM nicht so vertraut bin, dass ich jetzt genau verstehe was du meinst ;)
Die Presence Nachrichten, die unter dem
"presence_topic": "home/TheengsGateway/presence",bei aktiviertem
"presence": 1,gesendet werden, werden meist nur für Raum-Lokalisierung verwendet, da die MQTT Nachrichten dann auch eine RSSI-abhängige
distance Eigenthscaft beinhalten.
Als generelle Präzenserkennung nehme ich bei meinem Controller die laufend ankommenden MQTT Nachrichten bei anwesendem Gerät unter
publish_topic + "/AC88FDXXXXXX" (in deinem Fall)
home/TheengsGateway/BTtoMQTT/AC88FDXXXXXXund nachdem diese beim Verlassen des Hauses (oder Ausschalten der Apple Watch zum Testen) nicht mehr ankommen, da ja Theengs Gateway dann auch keine BLE Broadcasts mehr empfängt, wird nach
"tracker_timeout": 120,eine Offline/Away Nachricht mit
{"id": "AC:88:FD:XX:XX:XX", "state": "offline"}auf dem gleichen Topic gesendet.
Für Controller, die Auto-Discovery unterstützen, werden die Apple Geräte als device_tracker class entdeckt, die als value template
{% if value_json.get('rssi') -%}home{%- else -%}not_home{%- endif %}definiert.
Nach dem Motto: Beinhaltet die letzte MQTT Nachricht die Eigenschaft 'rssi', dann ist das Gerät Zuhause, falls nicht, wie bei der letzten
"state": "offline" Nachricht nach dem
tracker_timeout, dann Abwesend.
Falls oben genannten Vorgehensweisen für FHEM weniger intuitiv sind, würden wir gerne wissen was die gängige FHEM-Präsenz Home/Away Erkennung ist, um dies vielleicht dann auch angepasster in einer zukünftigen Version einzubauen.
Gruß
Hallo,
das mit
state offline 2024-01-20 08:24:13
habe ich hinbekommen. Allerdings bleibt der state auf offline selbst wenn die Watch wieder in Reichweite ist
und rssi und distance wieder aktualisiert werden.
Allerdings bin ich auch über Starting on RPi Zero W ends up in an error every time (https://github.com/maretodoric/theengsgateway-docker/issues/5) gestolpert.
Damit ist das leider für mich so nicht zu gebrauchen.
VG Sebastian
ZitatAllerdings bin ich auch über Starting on RPi Zero W ends up in an error every time gestolpert.
Damit ist das leider für mich so nicht zu gebrauchen.
Alles klar, obwohl ich jetzt nicht verstanden habe, ob du dieses Problem selbst hattest obwohl du ja "brauchbare Ergebnisse erhalten" hast, oder nur den alten Bug auf dem fremden Docker Repo, welches nicht von uns ist, gesehen hast. Soweit ich weiß, ist der nicht mehr aktuell.
Zitathabe ich hinbekommen. Allerdings bleibt der state auf offline selbst wenn die Watch wieder in Reichweite ist
und rssi und distance wieder aktualisiert werden.
Dazu kann ich leider wirklich wenig sagen mit meinem fehlenden FHEM Wissen, aber schade, dass es bei FMHEM so schwer zu sein scheint, diesen Home/Away Status einfach hinzubekommen. Liegt vielleicht auch an der generellen MQTT Erkennung, die in deinem oben genannten Beispiel die Apple Watch Nachricht auch fälschlicher Weise als iBeacon Format mit uuid, major, minor und volt zu erkennen scheint!?!
Zitat"identities": {
"AC:88:FD:XX:XX:XX": "***"
},
Eindeutige MAC Adressen zu anonymisieren ist immer eine gute Idee, mach das auch mal in dem READINGS: Output, oder lösche ihn. Muss nicht jeder deine eindeutige Apple Watch Bluetooth MAC wissen ;)
Gruß
Zitat von: DigiH am 20 Januar 2024, 02:04:49Falls oben genannten Vorgehensweisen für FHEM weniger intuitiv sind, würden wir gerne wissen was die gängige FHEM-Präsenz Home/Away Erkennung ist, um dies vielleicht dann auch angepasster in einer zukünftigen Version einzubauen.
Die gängigen Parameter für Anwesenheit und nicht da sind
present
o.
absent
Aber im Grunde ist es Fhem absolut schnuppe wie du das nennst, das lässt sich alles übersetzten.
P.s. Hab ich dich oben schon richtig verstanden. Nur hatte ich gleich noch den Bogen weiter gespannt zur genauen Lokalisierung.
Mac Adressen oder ip (iPhone/ipad) haben nur einen Riesen Nachteil... du musst die Abwesenheit per timeout ermitteln.
Ich seh an Hand von triangulation wer das Haus betritt oder verlässt. Auf ca.1m genau.
Dazu kommt das meine Haustür mit etlichen Sensoren gespickt is. Ich check noch zusätzlich Gewicht und Körpergröße ab und kann so auch Leute erfassen die garkeine miiuhr anhaben.
Hallo DigiH,
kann man nicht einmalig eine Online/present Nachricht mit
{"id": "AC:88:FD:XX:XX:XX", "state": "present"}senden, sobald das Apple Device erkannt wird, und dann einmalig eine Offline/absent Nachricht mit
{"id": "AC:88:FD:XX:XX:XX", "state": "absent"}sobald keine Topics beim Verlassen des Hauses (oder Ausschalten der Apple Watch zum Testen) nicht mehr ankommen?
Das würde helfen.
Beste Grüsse
ZitatDie gängigen Parameter für Anwesenheit und nicht da sind
present
o.
absent
Zitatkann man nicht einmalig eine Online/present Nachricht mit
Das war ja meine Frage oben, wie ihr es sonst so bei FHEM macht. Wir versuchen schon alle gängigen Controller so gut wie möglich zu unterstützen, aber da ca. 75% der Open Source Controller heutzutage Auto-Discovery unterstützen haben wir natürlich das erstmal so gemacht, ohne bis jetzt ein present/absent zu benötigen, oder dass danach bis jetzt gefragt wurde.
ZitatMac Adressen oder ip (iPhone/ipad) haben nur einen Riesen Nachteil... du musst die Abwesenheit per timeout ermitteln.
Ich seh an Hand von triangulation wer das Haus betritt oder verlässt. Auf ca.1m genau.
Dann würde ich aber gerne mal wissen, wie du ohne timeout erkennst/definierst, dass ein Gerät abwesend ist. Auch absent kann ja eigentlich erst gesendet werden, wenn eine bestimme definierte Zeit lang das Gerät nicht mehr empfangen wurde, oder bei einer Triangulation auch erst nach einer bestimmen timeout Zeit oder wie lange nach einem timout nachdem der letzte ESP32 einen Empfang bestätigt hat.
ZitatAber im Grunde ist es Fhem absolut schnuppe wie du das nennst, das lässt sich alles übersetzten.
Das dachte ich ja auch, dass eine eindeutige "state": "offline" Nachricht leicht für FHEM als absent zu interpretieren ist, und wieder neu reinkommende Nachrichten, auch ganz egal mit welchen Inhalten, als present. Da scheine ich mich aber getäuscht zu haben, oder ihr seid einfach an ein present/absent gewöhnt :)
Nichtsdestotrotz denke ich aber auch, dass die falsche zusätzliche iBeacon Erkennung irgendwie dazwischen funkt, da wohl die letzte "state": "offline" auch wieder weitere falsche iBeacon Eigenschaften beinhaltet und dieser Fehler vielleicht auch weiterhin fehlerhafte iBeacon Nachrichten sendet - vielleicht auch von einem internen BT Adapter - obwohl das keinen Sinn macht bei der Identity MAC Adresse??
Von dem Beispiel oben sieht es ganz danach aus, dass FHEM alle BLE manufacturerdata, die mit "4c00..." anfangen wahllos als iBeaon Format abstempelt.
Wie gesagt, present/absent ist kein großes Problem einzufügen, dann mit einem Argument, dass für FHEM Benutzter zu aktivieren ist - für andere Controller wären diese zusätzlichen Nachrichten nur verwirrend. Ich werde das die Tage mit den anderen aus dem Team besprechen. Sind dann ein paar von euch auch bereit und hätten die Möglichkeit Testbuilds zu installieren und zu testen?
Bei der offline/absent Nachricht müsste dann für FHEM wohl auch unlocked:false mitgeschickt werden, damit auch hier gleich ein automatisches sinnvolles 'verriegelt' bei Abwesenheit eingetragen wird.
Gruß
Hallo DigiH,
bei mir siehts so aus wie unten im List von meinem device. Meine Watch wird aber nicht als iBeacon erkannt, wie Du geschrieben hast. Present/absent hatte ich mir über ein eigenes userreading 'status' erzeugt. Zusätzlich merke ich mir noch die beiden Zeitstempel, wann die Uhr present und absent war.
ZitatSind dann ein paar von euch auch bereit und hätten die Möglichkeit Testbuilds zu installieren und zu testen?
Ja, gerne.
ZitatBei der offline/absent Nachricht müsste dann für FHEM wohl auch unlocked:false mitgeschickt werden, damit auch hier gleich ein automatisches sinnvolles 'verriegelt' bei Abwesenheit eingetragen wird.
Das habe ich auch genau so über ein seperates notify gelöst, wenn Du das unlocked:false bei Abwesenheit mit einbauen kannst, das wäre prima.
List von meinem Device:
CID IOMQTT
IOMQTT_MSGCNT 5456
IOMQTT_TIME 2024-01-20 22:38:25
DEF IOMQTT
IODev IOMQTT
LASTInputDev IOMQTT
MSGCNT 5456
NAME myWatch
NR 3071
STATE Status: present         Unlocked: true<br>Last: 2024-01-20 22:38:25   Rssi: -72
TYPE MQTT2_DEVICE
eventCount 218
OLDREADINGS:
READINGS:
2024-01-19 09:06:46 IODev IOMQTT
2024-01-20 12:28:32 TimeOffline 2024-01-20 12:28:32
2024-01-20 16:38:54 TimeOnline 2024-01-20 16:38:54
2024-01-20 22:38:25 brand Apple
2024-01-20 22:38:25 id 11:22:33:44:55:66
2024-01-20 22:38:25 lastSeen 2024-01-20 22:38:25
2024-01-20 22:38:25 lastSeenOld 2024-01-20 22:38:24
2024-01-20 22:38:25 model Apple Watch
2024-01-20 22:38:25 model_id APPLEWATCH
2024-01-20 22:38:25 rssi -72
2024-01-20 12:28:32 state offline
2024-01-20 22:38:25 status present
2024-01-20 22:38:25 type BODY
2024-01-20 22:38:25 unlocked true
hmccu:
Attributes:
IODev IOMQTT
event-on-change-reading unlocked,status
event-on-update-reading state
group PRESENCE
readingList home/TheengsGateway/BTtoMQTT/112233445566:.* { json2nameValue($EVENT) }
room Favourites
stateFormat Status: status         Unlocked: unlocked<br>Last: lastSeen   Rssi: rssi
userReadings status {ReadingsAge($name,'rssi',999) < 35?'present':'absent';;},
lastSeenOld {ReadingsVal($name,'lastSeen','nA')},
lastSeen {ReadingsTimestamp($name,'rssi','nA')},
TimeOnline:status:.present {ReadingsTimestamp($name,'status','nA')},
TimeOffline:offline {ReadingsTimestamp($name,'state','nA')}
War eigentlich der Meinung ich hätte das erklärt, aber gern nochmal,
Ich hab eine ,,homebase" die die aussenkontur des Haus ,,darstellt".
Verlässt du die, sag ich du bist nicht da.
Ich muß gestehen, das ich presence nur sehr stiefmütterlich nutze. Ich hab das mal vor Jahren wie hier im Wiki beschrieben mit den bereits vorhandenen Modul begonnen und war sehr unzufrieden mit der Genauigkeit und eben den ständig hängenden oder verschwundenen devices.
Dann hatte ich geofancy entdeckt, bin aber kein Freund von google/Apple oder whatever externen gps ortungsdiensten.
Aber die Idee dahinter gefiel mir. Nur eben ohne bigbrother.
Sei's wies ist, etwas C (#) und Fhem hat mir gezeigt das es geht und machbar ist. leider kommt aber der Faktor Mensch dazu, und hat mein Wunsch des definierten Zustand (ich komm ausm sondermaschinenbau und da gibts eigentlich kein undefinierten Zustand). Zunichte gemacht.
Mal ist der Akku leer, oder man trägt seine Uhr nicht. So das ich's wie gesagt schleifen lassen hab.
Auf gut deutsch es ging als machbarkeitsstudie in die Schublade zurück.
Läuft hier zwar nach wie vor im Hintergrund, wird aber nicht genutzt.
Drum hab ich ja den Firlefanz mit Waage und ,,lichtgitter" an der Haustür installiert. Aber rate mal, wer auch das, recht schnell ausgetrickst hat. :))
Mensch is halt einfach super kompliziert. So richtig eineindeutig bekommt man den nur mit Kameras erfasst.
ZitatMeine Watch wird aber nicht als iBeacon erkannt, wie Du geschrieben hast.
Nur wie ich oben im List von Sebastian gesehen habe, da da zusätzliche Einträge mit mfid, uuid, major, minor und volt sind, was ich sehr verwirrend fand. So wie bei dir ist es, wie ich es erwarte und es eigentlich sein soll.
ZitatDas habe ich auch genau so über ein seperates notify gelöst, wenn Du das unlocked:false bei Abwesenheit mit einbauen kannst, das wäre prima.
Da es bei Discovery auch so gleichzeitig gelöst ist, wäre es für eine FHEM Lösung auch sinnvoll so zu imoplementierren, ohne dass jeder separat ein notify einbauen muss ;)
ZitatWar eigentlich der Meinung ich hätte das erklärt, aber gern nochmal,
Ich hab eine ,,homebase" die die aussenkontur des Haus ,,darstellt".
Verlässt du die, sag ich du bist nicht da.
Trotzdem wird es bei Gateway, oder anderen BLE Lösungen, ohne ein timeout nicht gehen, welcher ja auch von
ble_scan_time und
ble_time_between_scans abhängig ist.
Die Einstellungen, die Sebastian oben mit 'python -m TheengsGateway.diagnose' bekommen hat, sind auch in der
theengsgw.conf Datei im Home-Verzeichnis. Dort können alle Einstellungen editiert werden, um danach ein einfaches Starten mit
python -m TheengsGateway zu erlauben.
Stellt da am besten "discovery": auf 0, damit ihr in eurem MQTT Broker keine retained Discovery Messages mehr bekommt.
Habt ihr eigentlich alle MQTT Explorer? Damit am besten mal gleich das ganze homeassistant Topic löschen, um die für euch nicht brauchbaren retained Discovery Einträge zu löschen.
Mir war zwar persönlich sehr wichtig für die Apple Geräte die zusätzliche
unlocked Eigenschaft einzubauen, aber alle anderen Devices, die hier auch als Presence Tracker markiert sind, werden von Theengs Gateway als solche erkannt und veröffentlicht. Mit einer present/absent Änderung also auch für diese Geräte. Ich habe zwar selbst keinen, aber viele User haben den BM2 Battery Monitor, um auch ihre Fahrzeug-Präsenz im Carport oder der Garage zu erkennen ;)
https://decoder.theengs.io/devices/devices.html
Ich gebe Bescheid, sobald es etwas neues zum Testen gibt.
Gruß
ZitatIch nutze keine scan bei BLE und auch kein timeout
Ich weiß, dass du irgendeine ",,homebase" die die aussenkontur des Haus ,,darstellt"" hast, und das ist schön so, aber bei BLE Geräteerkennung, um die es hier geht, wirklich nicht relevant.
Dein oben genanntes Mi Band 6 wird aber auch nicht anders als mit BLE Scan erkannt ;)
Wenn du scannst, empfängst du alles.
Ich scanne nicht, ich lass senden ... so alle 10sekunden.
Die Mi Bands senden alle 550 ms einen BLE Advertising Braodcast aus, der von verschieden BLE Scan Lösungen wie Theengs Gateway, OpenMQTTGateay, ESPresence, Tasmota, ble-monitor ... und wie sie alle heißen, empfangen/gescannt werden kann, um diese empfangenen Daten entweder du decodieren mit Schrittanzahl und Aktivitätspuls, oder nur um die Präzens des Garätes anzuzeigen.
All diese BLE Scan Lösungen, auch ESPresence und Tasmota, arbeiten mit einem timeout, da es bei den Grundlage von BLE Scans logischerweise auch nicht anders geht.
Eine Möglichkeit auf dem Mi Band etwas zu installieren, um nur alle 10 Sekunden etwas zu senden gibt es nicht.
Eine andere Möglichkeit um von einem ESP32 etwas nur alle 10 Sekunden zu senden geht zwar, aber das ändert nichts an den BLE Braodcasts welches ein Mi Band so oder so alle 550 ms raus schickt, oder an der Tatsache welche Daten es raus schickt, außer beim Mi Band der Unterschied zwischen einem passiven Scan oder aktivem Scan, wo beim letzteren die Empfangsstation einen kleinen aktiven Kick ans Mi Band schickt um vollständigere Daten beim nächsten Broadcast zu erhalten.
Dies ist aber auch schon seit dem Model Mi Band 7 unterbunden worden, und wir wohl in weiteren neueren Versionen auch so sein, bis hin zu auch wechselnden Bluetooth MAC Adressen, der Privatsphäre wegen.
Aha
Dann ist customfirmware nur ein hirngespinnst.
Ich hatte es ja vorhin schon mal gesagt, für mich ist die Diskussion hiermit beendet.
Viel Erfolg mit deim Vorhaben.
@Jamo - ich habe mal nach dem Mittagessen ne schnelle, grobe Unterstützung gemacht, obwohl ich gleich schon sagen muss, die presence Eigenschaft wäre wohl als true/false boolean besser als mit "present"/"absent" Strings, aber nur nur ne Kleinigkeit.
Zum testen kannst du mal die fhemtest Branch auschecken, builden und pip installieren, und uns wissen lassen, ob die MQTT Nachrichten so einfacher in FHEM zu integrieren ist.
https://gateway.theengs.io/install/install.html#advanced-users-build-and-install
Also Settings wird im Moment noch
"discovery": 1,
...
"FHEM_presence": 1,
benötigt
Hallo DigiH,
gerne, aber ich scheitere am git clone:
fhem@inuc:~/theengs$ git clone https://github.com/theengs/fhemtest.git
Cloning into 'fhemtest'...
Username for 'https://github.com':und
fhem@inuc:~/theengs$ git clone https://github.com/theengs/gateway/tree/fhemtest.git
Cloning into 'fhemtest'...
fatal: repository 'https://github.com/theengs/gateway/tree/fhemtest.git/' not found
fhem@inuc:~/theengs$
Hallo Jamo,
gerne, aber ich scheitere am git clone
https://github.com/theengs/fhemtest.git
Kein Problem, fhemtest.git gibt es nicht, fhemtest ist nur eine Branch von gateway.git.
Versuche es mal so
git clone https://github.com/theengs/gateway.gitDann rein in die Directory
cd gateway/und die relevante fhemtest Branch auschecken mit
git checkout fhemtestDann hast du die gewünschte Branch und kannst sie mit
pip install .builden und installieren.
Zurück in Home Verzeichnis mit
cd ~/und die Test Version starten, nachdem du die Argumente
"discovery": 1,
...
"FHEM_presence": 1,angepasst hast.
Ich hoffe du hattest die vorherige Release Version auch mit pip installiert, oder es kommt vielleicht noch eine pip Hürde auf dich zu.
Hi DigiH,
sieht gut aus, wie man sich das vorstellt! Danke! Allerdings wirft er bei mir jetzt auch immer die distance mit aus:
Absent:
READINGS:
2024-01-19 09:06:46 IODev IOMQTT
2024-01-22 08:48:24 brand Apple
2024-01-22 08:55:25 distance 3.3940094477016304
2024-01-22 08:50:43 id 11:22:33:44:55:66
2024-01-22 08:50:43 lastSeen 2024-01-22 08:48:24
2024-01-22 08:48:24 model Apple Watch
2024-01-22 08:48:24 model_id APPLEWATCH
2024-01-22 08:50:43 presence absent
2024-01-22 08:48:24 rssi -68
2024-01-22 08:48:24 type BODY
2024-01-22 08:50:43 unlocked false
und present false
READINGS:
2024-01-19 09:06:46 IODev IOMQTT
2024-01-22 08:55:25 brand Apple
2024-01-22 08:55:25 distance 2.0094476303970144
2024-01-22 08:55:25 id 11:22:33:44:55:66
2024-01-22 08:55:25 lastSeen 2024-01-22 08:55:25
2024-01-22 08:55:25 model Apple Watch
2024-01-22 08:55:25 model_id APPLEWATCH
2024-01-22 08:54:59 presence present
2024-01-22 08:55:25 rssi -65
2024-01-22 08:55:25 type BODY
2024-01-22 08:55:25 unlocked false
und present true
READINGS:
2024-01-19 09:06:46 IODev IOMQTT
2024-01-22 08:57:21 brand Apple
2024-01-22 08:57:21 distance 1.6029664746240697
2024-01-22 08:57:21 id 11:22:33:44:55:66
2024-01-22 08:57:21 lastSeen 2024-01-22 08:57:21
2024-01-22 08:57:21 model Apple Watch
2024-01-22 08:57:21 model_id APPLEWATCH
2024-01-22 08:54:59 presence present
2024-01-22 08:57:21 rssi -63
2024-01-22 08:57:21 type BODY
2024-01-22 08:57:21 unlocked true
{
"FHEM_presence": 1,
"adapter": "hci1",
"bindkeys": {},
"ble": 1,
"ble_scan_time": 3,
"ble_time_between_scans": 20,
"discovery": 1,
"discovery_device_name": "TheengsGateway",
"discovery_filter": [
"IBEACON"
],
"discovery_topic": "homeassistant",
"enable_tls": 0,
"enable_websocket": 0,
"hass_discovery": 1,
"host": "168.99.0.32",
"identities": {
"11:22:33:44:55:66": "asdf",
"11:22:33:44:55:66": "jklö"
},
"log_level": "INFO",
"lwt_topic": "home/TheengsGateway/LWT",
"pass": "lskdfhlsifhslifh",
"port": 1883,
"presence": 1,
"presence_topic": "home/TheengsGateway/presence",
"publish_advdata": 0,
"publish_all": 1,
"publish_topic": "home/TheengsGateway/BTtoMQTT",
"scanning_mode": "active",
"subscribe_topic": "home/+/BTtoMQTT/undecoded",
"time_format": 0,
"time_sync": [],
"tracker_timeout": 120,
"user": "fhem"
}
Hi Jamo,
Zitatsieht gut aus, wie man sich das vorstellt! Danke!
Freut mich, obwohl dann für eine Release noch an ein paar Kleinigkeiten gefeilt werden muss ;)
Dank dir für die unkomplizierte und zivilisierte Mitarbeit!
ZitatAllerdings wirft er bei mir jetzt auch immer die distance mit aus:
"presence": 0,dann ist die distance auch weg.
"FHEM_presence": 1,macht jetzt alles, ohne eine distance.
Hallo DigiH,
ich wollte das TheengsGateway auf einem weiteren Raspberry PI installieren.
Der fhemtest Branch existiert aber nicht mehr, und im normalen Branch ist die FHEM Funktionalität noch nicht drin.
Kannst Du den Branch nochmal zur Verfügung stellen, bzw wann würde ein neues Release mit der FHEM_presence funktionalität kommen?
PS: das unlocked funktioniert bei mir nur für die Apple Watch, nicht aber für das iPhone. Ist das bekannt oder nur bei mir so?
PSS: Hat sich erledigt, ich habe mir den fhem Branch auf den weiteren Raspberry PI kopiert und nochmal kompiliert.
Dank Jamo, seiner Unterstützung und dem Testen, hier die für FHEM benötigten Start- und Settings-Argumente für Release 1.5.0 von Theengs Gateway.
-D 0 -Gp 1Zitat-D DISCOVERY, --discovery DISCOVERY
Enable(1) or disable(0) MQTT discovery
...
-Gp GENERAL_PRESENCE, --general_presence GENERAL_PRESENCE
Enable (1) or disable (0) general present/absent presence when --discovery: 0