NEWS
Geofency Adapterersatz mit Node-red
-
Grummel… das obere Kästchen oben links (TCP stream) muss wohl doch getauscht werden.
Die Meldungen werden beim Betreten eines Standorts gesendet und werden auch richtig verarbeitet.
Allerdings schickt die Geofency App dann immer wieder ältere Meldungen (die Standorte, die davor betreten wurden).
Fehler in Geofency oder Geofency erwartet eine Rückmeldung, sprich der TCP Stream reicht nicht?
Bei Owntracks funktioniert das richtig. Dort wird mqtt verwendet, mit dem entsprechenden Baustein.
Ich schau mal was man tun kann.
[EDIT]
Workaround ist in Arbeit
-
Neue Version:
Ältere (doppelte) Meldungen werden nun ignoriert.
iBeacon werden berücksichtigt.
0.1.2 06.05.2015 # Unterscheidung Meldung über GPS Standort oder iBeacon eingebaut
iBeacon Variablen eingebaut
0.1.1 05.05.2015 # msg.payload.routes[0].legs[0].end_address (Goolge Maps API Zieladresse) hinzugefügt
Zeitstempel angepasst. Nicht mehr die Zeit zum Zeitpunkt des Funktionsaufruf,
sondern nun wird die Zeit aus der JSON Meldung ausgegeben.
zwei neue Zeiten: Zeitpunkt aus der JSON Meldung als Epoche, aktuelle Zeit als Epoche
Topic den einzelnen Funktionen -> Variablen zugeorndet (bessere Lesbarkeit der Debugmeldung)
Dokumentation im Flow ergänzt
alle globalen Variablen beginnen nun mit gf (context.global.gf….)
Konfigurierbar: nur neuere Meldungen verarbeiten oder auch ältere Meldungen
Anzeige der aktuellen Kofiguration per Knopfdruck im Debug-Fenster
0.1.0 04.05.2015 # Erste version im Forum
sorry, kann ich leider nicht ablegen:
"Dein Beitrag enthält 117142 Zeichen. Es sind maximal 60000 Zeichen erlaubt."
.
-
Anbei die die aktuelle Version des Geofency Flows.
!!ACHTUNG!!
!Neue Struktur der Variablen! <- Bitte beachten, falls jemand schon mit der älteren Version getestet hat.
Die alten Variablen können über iobroker/admin gelöscht werden.
Die neuen Variablen nutzen eine Baumstruktur. Es werden nun bis zu drei Benutzer automatisch dargestellt und diese noch einmal zwischen GPS und iBeacon unterschieden.
Sollte in der Geofency App keine iBeacon Meldungen konfiguriert sein, dann werden die Variablen auch nicht unnötig erzeugt.
Unter eigene Daten/Konfig:
Die eigenen Koordinaten und die eigene Anschrift eintragen (wird für die Spielereien benötigt).
Die eigenen Device ID sollte man vorher auslesen und in der Konfig eintragen. Sonst wird ein Zweig Unbekannt in der Variablen-Baumstruktur erzeugt.
Dazu kann man vor dem ersten Start die Verbindung (A1) trennen und unter Debug (A) die eigene ID auslesen und dann in der Konfig eintragen.
Danach die Verbindung (A1) wieder herstellen.
Nicht benötigte Variablen können einfach gelöscht werden. Genauso, wie die Kästchen "Spielereien".
-
Anbei der Geofency Flow 0.2.0 als Dateianhang (txt):
Der neue Flow filtert die älteren Mehrfachsendungen von Geofency raus.
Das Thema der Geofency Webhook-Behandlung ist noch offen (derzeit tcp-Stream, muss in eine "richtige Behandlung des Webhooks geändert werden).
Dadurch, dass die doppelten Meldungen rausgefiltert werden, kann man den Flow nun so benutzen.
Beispiel, wie die Varibalen aufgebaut sind (weitere Verarbeitung, z.B. direkt in VIS, Node-red, Javascript-Adapter, usw.):
-
.
Anbei die neue Version.
Er ist benutzerfreundlicher für die, die den Flow bisher nicht verwendet haben.
Ein erster Start des Flows, ohne dass man seine eigene Device ID kennt, gibt erst einmal nur die ID aus, damit man diese in der Konfig nach pflegen kann. Dadurch werden, unter Umständen, nicht erwünschte Variablen, nicht angelegt.
Das Verhalten ist nun aber auch konfigurierbar.
Der Flow ist voll funktionsfähig (bei mir jedenfalls).
Das TCP Thema (anderer Topic) bringt derzeit noch folgenden Schönheitsfehler: Etwas mehr Traffic (nicht relevant), durch mehrfach gesendete Standorte. Und ggf. bei sehr schnell wechselnden Standorten (schneller, als der tcp Timeout). Dies tritt bei mir nicht aus, obwohl ich schnell zwischen den "normalen" Standorten und iBeacon Kennungen (z.B. ein iBeacon im Auto) wechsele. Ein anderer Schönheitsfehler ist, dass es sich bei den "normalen" Standorten nicht um GPS handelt, sondern um "Significant Change Location Service" Standorte. Im Variablenbaum heisst es gps und nicht sclss.
Versionshistorie / Änderungen
0.2.1 09.05.2015
Zoomstufe für Openstreetmaps konfigurierbar
tlw. Abfangen und Korrektur von ungültigen Werten in der Konfiguration
Konfiguration nach Init unter geofency.conf.xxxxx speichern.
Kann dort während der Laufzeit verändert werden, (z.B. Kartenzoomstufe über VIS).
beim erneuten Deploy wird auf die Werte aus der Node-Red Konfiguration zurückgesetzt.
Benutzerfreundlicher: unbekannte Device
Im DEFAULT werden unbekannte Devices nicht als Variable angelegt.
Es wird nur das Device ausgegeben. Die Device Kennung kann man dann in der Konfig zuordnen.
Wenn gewünscht (Konfig), werden auch unbekannte Devices angelegt.
Konfig: Möglichkeit unbekannte Devices mit Ihrer ID in den Variablen anzulegen
0.2.0 08.05.2015
Variablen neu vergeben (Baumstruktur)
eigene Variablen für bis zu drei Nutzer + Unbekannt
0.1.2 06.05.2015
Unterscheidung Meldung über GPS Standort oder iBeacon eingebaut
iBeacon Variablen eingebaut
0.1.1 05.05.2015
msg.payload.routes[0].legs[0].end_address (Goolge Maps API Zieladresse) hinzugefügt
Zeitstempel angepasst. Nicht mehr die Zeit zum Zeitpunkt des Funktionsaufruf,
sondern nun wird die Zeit aus der JSON Meldung ausgegeben.
zwei neue Zeiten: Zeitpunkt aus der JSON Meldung als Epoche, aktuelle Zeit als Epoche
Topic den einzelnen Funktionen -> Variablen zugeorndet (bessere Lesbarkeit der Debugmeldung)
Dokumentation im Flow ergänzt
alle globalen Variablen beginnen nun mit gf (context.global.gf….)
Konfigurierbar: nur neuere Meldungen verarbeiten oder auch ältere Meldungen
Anzeige der aktuellen Kofiguration per Knopfdruck im Debug-Fenster
0.1.0 04.05.2015
Erste version im Forum
Ich hatte noch angefangen ein Widget zu basteln.
Da freue ich mich auf die Änderung von Bluefox (danke noch einmal, dass die Idee so schnell aufgegriffen wurde), der Variablen {node-red.0…..} in den VIS-Feldern. Sobald das Feature da ist, schwebt mir ein recht dynamisches Widget vor.
-
Ich überlege, meine Anwesenheitserkennung über die WLAN Erkennung per Skript auf der Fritz!Box auf GeoFency umzustellen. Könnt ihr mir eine brauchbare App für Android empfehlen? `
Ich nutze unter iOS Geofency mit dem Flow hier und parallel Owntracks (der Flow ist auch hier im Forum).
Owntracks hat keine offenen Punkte in der Kommuniktation.
Für Android bekommst Du Owntracks im Google Play Store:
https://play.google.com/store/apps/deta … tude&hl=de
Habe das allerdings unter Android nicht getestet.
Ich bin mal auf Deine Anwesenheitserkennung gespannt.
Die Kombination aus WLAN, Zeitparameter, Türkontakte funktioniert schon sehr gut.
Mit den Geodaten kann man das dann verfeinern.
-
Leider werden anscheinend nicht alle hier eingesetzten Funktion auch von Node-Red unter Windows unterstützt. Die Connection kommt zwar an, aber es gibt weder eine Ausgabe im debug-Fenster noch erhält Geofency eine Rückmeldung. Irgendwann kommt dann eine Zeitüberschreitung und die im Node-Red angezeigt Connection verschwindet wieder. Das gleiche Verhalten habe ich auch bei ausgeschaltener Firewall.
-
Bei mir ist ioBroker mit Node-red unter Debian installiert. Unter Windows sollte es aber auch funktionieren.
Wenn Du den Debug-Node nach dem tcp-Node aktivierst, müsstest Du die Meldungen bekommen. Windows Firewall (hattest Du schon selbst geschrieben) oder Port-Forwarding im Router sind richtig konfiguriert?
-
hallo ruhr70,
ich habe mich heute mal mit deinem gefency Adapterersatz beschäftigt nur bekomme ich in den Objekten nix angezeigt, könntest dir das mal anschauen, hier ist die Ausgabe von node red:
mehr bekomme ich nicht, was fehlt den hier noch?
bin auch noch am verzweifeln wegen der portweiterleitung????
Mit freundlichen Grüßen
909_bildschirmfoto_2015-12-20_um_22.25.20.png -
Hallo,
habe mich auch mal an Node-RED (v0.3.5) rangetraut. Wenn ich allerdings zum testen in der iOS App auf "betreten" klicke, bekomme ich im io.broker Log folgenden Fehler angezeigt:
node-red.0 2016-01-12 15:37:14 warn node-red.0 12 Jan 15:37:14 - [warn] [http request:http request - Google API Route (Auto)] Warning: msg properties can no longer override set node properties. See bit.ly/nr-override-msg-propsUnter dem angegeben Link steht dazu folgendes:
` > Properties can be set in a node or in an incoming message to define behaviour.
For example, when using a file node, either setting 'Filename' in the node or setting msg.filename in an incoming message will read from that file. If both properties are set msg.filename will currently override the node property.
This behaviour is only found in some nodes and can have unexpected consequences as described in this issue. Therefore, message overriding has been deprecated.
In future nodes and future releases msg.some_property will only be used if the property is not set in the node.
Nodes currently using the override functionality will continue to function in this release but will also receive a warning noting that this behaviour is deprecated.
The core nodes and properties affected by this behaviour are:
http request: msg.url and msg.method
email: msg.to
file: msg.filename `
Geofency selbst spuckt auch einen Fehler… Mache ich noch was falsch?
Ich muss ja gestehen, dass der Adapter unter ccu.io leichter zu confen war ;) Leider fehlt das Gegenstück dazu für io.broker leider noch... :)
Danke!
-
es gibt jetzt auch endlich einen Adapter!
Support us
802
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge