UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[afuerhoff]

@afuerhoff sagte in Test Adapter fb-checkpresence v1.1.x:

Zu Punkt 1 muss ich im Adapter etwas ändern.

Hallo, kannst Du mal schauen, ob der Datenpunkt meshstate auf false gesetzt ist. Jedes Device hat so einen Datenpunkt. Daran kann man erkennen, ob die Daten aktuell sind.

[Pedder007]

@afuerhoff
Hallo, ich habe das gerade alles nochmals gecheckt, kann aber keine Konfigurationsprobleme erkennen:

• Der Intervall steht auf 3 Minuten
• Der Adapter läuft grundsätzlich auch und man erkennt die Updates, z. B. auch daran, dass wenn man die Objektübersicht geöffnet hat, beim Update die Schrift in den Datenpunkten kurz grün eingefärbt wird und viele Datenpunkte auch angepasst werden, leider nur nicht immer alle, also zumindest mal all diejenigen welche sich verändert haben.
• Darüber hinaus habe ich auch nochmals schnell einen Test mit dem iPad gemacht, welches nach WLAN-Deaktivierung in der nächsten Aktualisierung auch direkt als 'active=0' angezeigt wurde.
• Die Objektliste hatte ich natürlich auch schon mehrfach aktualisiert ;-)

Hier nochmal ein gerade erzeugtes Beispiel dazu, was ich genau meine, bzw. was dann auch dazu führt, dass ich in meiner VIS-Übersicht veraltete Angaben sehe.
Wie Du hoffentlich erkennen kannst, findet sich an dem Datenpunkt in dem PopUp am Feld 'link' und dem Wert CamHaustuer, der Zeitstempel von vorgestern 02:28.

Den gleichen Eintrag mit CamHaustuer finde ich aber auch als gerade eben upgedated (siehe Zeitstempel) weiter unten, dort dann allerdings mit aktuellem Zeitstempel, bzw. so wie die CamHaustuer auch aktuell am Repeater hängt:

Ich hoffe man kann das noch lesen :-)

So sieht das so aus, als wäre die Cam, neben der aktuellen Verbindung, immer auch noch mit LAN1 verbunden, was natürlich Unsinn ist, da es sich um eine WLAN Cam handelt. Dieser Effekt ist dann wiederum der 2.te von mir beschriebene, dass da wahrscheinlich vorgestern unter der '0' noch das 5G WLAN angezeigt wurde ...

Der Datenpunkt Meshstate am Repeater-WZ steht auf 'true', was ich allerdings als der Wahrheit entsprechend verstanden hatte, da mein Setup komplett als Mesh läuft!?

Noch eine Ergänzung. Das Problem scheint nur beim auslesen der Datenpunkte der Netzwerk-Devices aufzutreten. Ich habe gerade auch nochmals die Datenpunkte an den beiden Cams selber geprüft und dort steht ausschließlich der aktuelle Connect am 5G WLAN.

[afuerhoff]

@Pedder007
Schon mal eine kurze Antwort zum meshstate. Der zeigt an, ob das Gerät in der Mesh Antwort der Fritzbox enthalten war. Wenn hier false steht sind die Daten veraltet.

[afuerhoff]

@Pedder007 sagte in Test Adapter fb-checkpresence v1.1.x:

So sieht das so aus, als wäre die Cam, neben der aktuellen Verbindung, immer auch noch mit LAN1 verbunden

Hier kannst du mal schauen, ob der Eintrag entsprechend in der Originalliste der Fritzbox im Datenpunkt mesh zu finden ist. Ich hatte ähnliche Effekte bei mir im Netzwerk, die ich mir nicht erklären kann. Kommt aber so aus der Fritzbox.

[Pedder007]

@afuerhoff
Ich bin mir nicht ganz sicher was Du mit der Originalliste der FB meinst?
Wenn ich allerdings im FB Menü die Mesh Übersicht (grafische Darstellung) oder die Übersicht des Netzwerkes (Listenansicht) öffne, dann stimmt dort alles, sprich alles komplett aktuell.
In der Liste stehen dann die aktiven Geräte im oberen Teil und der Rest als inaktiv im unteren Teil. Dieser Teil dürfte dann im Adapter ja nicht mehr mitkommen, bzw. wäre das evtl. eine Idee wo man den Adapter evtl. so aufbauen müsste, dass diese Einträge der inaktiven Geräte dann gezielt aus den Datenpunkten entfernt werden müssten?
Nur so ein Gedanke, evtl. tut Dein Adapter das ja schon und ich benutze ihn nur falsch?
Kann ich an der FB noch woanders nachschauen?

[afuerhoff]

@Pedder007
Ich meinte den Datenpunkt mesh in den Objekten. Dort ist die Meshliste aus der Fritzbox im Original abgelegt. Es ist eine Jsonliste. Der Adapter stellt genau diese Informationen zum Teil zur Verfügung. Wenn diese Informationen mit den Inhalten in den Objekten übereinstimmen kann ich im Adapter nichts machen.
Alle Objekte die in der Liste nicht vorkommen haben einen meshstate = false.

[Adios]

@afuerhoff said in Test Adapter fb-checkpresence v1.1.x:

Zu Punkt 1 muss ich im Adapter etwas ändern.

Erstmal vielen Dank für eure Energie in diesen tollen Adapter!!!

Gibt es denn bis zur Endlösung einen temporären Workaround? Ich habe überlegt mit dem Speed Wert zu arbeiten, allerdings ist dieser Wert immer leer....

Das mit den virtuellen MAC am Handy ist eher falls ein Handy nicht presence bekommt richitg? Ich bin aber nur von dem "always presence" Fehler betroffen.

Bis dahin Adios

[afuerhoff]

@Adios
Hast du die fb devices in der Konfiguration aktiviert?
Dann sollte auch der Speed Wert bei den Familienmitgliedern aktualisiert werden.

[Adios]

@afuerhoff
ja habe ich aktiviert..

Mein Handy verbunden

Mein Handy verbunden

Mein Handy nicht verbunden:

[afuerhoff]

@Adios
Diese Checkbox ist gesetzt?

[Adios]

@afuerhoff
nein, sollte?

[afuerhoff]

@Adios
Ja, für den Speed Wert ist das notwendig. Ich werde den Adapter noch umbauen, dann kann ich das anders lösen.

[Adios]

@afuerhoff
Danke, das wars!

Dann versuche ich jetzt mit dem Speed Wert zu arbeiten. Hast du eine vorstellung (Oder überhaupt schon eine Idee) wie lange die Lösung des eigentlichen Problems dauert? Das Problem ist ja das auf der FB Tabelle die Geräte weiter geführt werden... Warum AVM auf diesen Trichter kommt ist mir so oder so unklar..

@All
Sind eigentlich nur Repeater Nutzer davon betroffen?
Sind nur Repeater nutzer, die diesen nicht per Mesh eingebunden haben betroffen?

Adios

[Ein ehemaliger Benutzer]

@Adios
Hi, habe gerade auf deinem Screenshot gesehen, dass du bei der IP der Fritzbox den Namen eingetragen hast, wenn es funktioniert und deine DNS ok ist, gut, aber falls mal Probleme auftauchen....

IP = Numerisch und hier normal 192.168.178.1 oder wie auch immer gesetzt
Hostname = Text wie fritz.box
URL = http://192.168.178.1 oder wie auch gesetzt

Beim Fritzdect Adapter muss die URL eingetragen werden, beim TR-064 und hier die IP.

Nur mal so.. :-)

[Jaaannis]

@Adios sagte in Test Adapter fb-checkpresence v1.1.x:

@All
Sind eigentlich nur Repeater Nutzer davon betroffen?
Sind nur Repeater nutzer, die diesen nicht per Mesh eingebunden haben betroffen?

Adios

es scheint egal ob der Repeater im Mesh ist oder nicht. Bei beiden Varianten tritt das Problem auf.

[Pedder007]

@afuerhoff
Hallo, sorry war die letzten Tage etwas sehr busy ...

Ich habe das jetzt nochmals entsprechend Deinem Hinweis überprüft.
Als Beispiel: In der Jsonliste im Adapter finde ich aktuell z. B. eines unserer Kinder-Tablets (Toscido-schw) mit einem Eintrag als aktiv, was grundsätzlich auch stimmt.
Schaue ich nun aber in die Adapter-Einträge des Routers, an welchem es angemeldet ist, dann hängt das Geräte lt. diesen Einträgen am 2G WLAN und am 5G Guest WLAN, so wie im Screenshoot zu sehen. Überprüfung in der FB selber ergab, dass das Gerät definitiv am 2G WLAN hängt, sodass der 5G WLAN Eintrag also falsch ist.
Die zugehörigen Adapter-Einträge tragen alle Zeitstempel von gestern: 21.12.2020, unterschiedlich zwischen ~18:00h und 23:59h, was eigentlich auch nicht stimmen kann, da das Tablet über Nacht definitiv aus war und heute irgendwann wieder neu in Betrieb genommen wurde.

Erst dachte ich, dass das daran liegen könnte, dass die WLAN Einträge vom Repeater evtl. nicht richtig durchgereicht werden, ich sehe allerdings aktuell auch denselben Effekt an Geräten, welche direkt per LAN an der FB hängen. Z.B. tauchen meine ganzen Raspberrys aktuell gleich an mehreren LAN Ports parallel auf, was wenn ich in der Mesh-Übersicht der FB nachsehe definitiv nicht der Fall ist.

Nach Hinweis hier in Thread hatte ich gestern Abend in der Adapter-Konfig noch den Klarnamen der FB gegen die IP ausgetauscht, was aber auch nicht geholfen hat.

Dann habe ich soeben noch einige Einträge in der Familieneinstellung des Adapters ergänzt, z. B. das oben erwähnte Tablet, was aber auch nichts gebracht hat.

Leider im Gegenteil, nun steigt der Adapter bei jedem 2 Minuten Update lt. Log leider komplett aus:

Edit:
Habe jetzt den Abfrageintervall wieder auf 3 Minuten und das Familien-Polling auf 120 Sek. gesetzt und jetzt läuft der Adapter wieder ohne Fehler durch.

[afuerhoff]

@Pedder007
Hallo,

ich bin an dem Thema dran. Ich hoffe, dass ich bald einen Testkandidaten zur Verfügung stellen kann.

[Pedder007]

So'de'le, da mich Blockly immer schonmal interessiert hat und heute etwas Zeit über war, habe ich mir für den Übergang einen kleinen Work-Around gebaut.
Die Routine prüft die Zeitstempel aller Link-Datenpunkte in meinen 4 Network Devices und sobald der Zeitstempel älter als 30Minuten ist, überschreibt er die Datenpunkte schlichtweg mit einem "-".
Das Ganze läuft alle 10 Minuten durch, was für meine Zwecke zunächst einmal ausreicht ;-)

[Fenriswolf]

Hallo,

ich nutze den Adapter und bin recht begeistert. Nutze Ihn für die Anwesenheitserkennung.
Allerdings habe ich hin und wieder im Log Fehlermeldungen, die ich nicht wirklich zuordnen und deuten kann. Objektiv scheint alles zu funktionieren.

2020-12-27 11:31:04.471 - error: fb-checkpresence.0 (32384) getMeshList: Retried 3 times but still failed -> {"message":"timeout of 10000ms exceeded","name":"Error","stack":"Error: timeout of 10000ms exceeded\n at createError (/opt/iobroker/node_modules/axios/lib/core/createError.js:16:15)\n at ClientRequest.handleRequestTimeout (/opt/iobroker/node_modules/axios/lib/adapters/http.js:256:16)\n at Object.onceWrapper (events.js:420:28)\n at ClientRequest.emit (events.js:326:22)\n at Socket.emitRequestTimeout (_http_client.js:715:9)\n at Object.onceWrapper (events.js:420:28)\n at Socket.emit (events.js:326:22)\n at Socket._onTimeout (net.js:483:8)\n at listOnTimeout (internal/timers.js:554:17)\n at processTimers (internal/timers.js:497:7)","config":{"url":"http://192.168.99.1:49000/meshlist.lua?sid=3bcd8c0f258a3131","method":"get","headers":{"Accept":"application/json, text/plain, */*","User-Agent":"axios/0.19.2"},"transformRequest":[null],"transformResponse":[null],"timeout":10000,"responseType":"json","xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"cancelToken":{"promise":{}},"responseEncoding":"utf8"},"code":"ECONNABORTED"}
2020-12-27 11:31:04.476 - error: fb-checkpresence.0 (32384) getMeshList: {}
2020-12-27 11:33:01.731 - error: fb-checkpresence.0 (32384) getMeshList: Retried 3 times but still failed -> {"message":"timeout of 10000ms exceeded","name":"Error","stack":"Error: timeout of 10000ms exceeded\n at createError (/opt/iobroker/node_modules/axios/lib/core/createError.js:16:15)\n at ClientRequest.handleRequestTimeout (/opt/iobroker/node_modules/axios/lib/adapters/http.js:256:16)\n at Object.onceWrapper (events.js:420:28)\n at ClientRequest.emit (events.js:326:22)\n at Socket.emitRequestTimeout (_http_client.js:715:9)\n at Object.onceWrapper (events.js:420:28)\n at Socket.emit (events.js:326:22)\n at Socket._onTimeout (net.js:483:8)\n at listOnTimeout (internal/timers.js:554:17)\n at processTimers (internal/timers.js:497:7)","config":{"url":"http://192.168.99.1:49000/meshlist.lua?sid=3bcd8c0f258a3131","method":"get","headers":{"Accept":"application/json, text/plain, */*","User-Agent":"axios/0.19.2"},"transformRequest":[null],"transformResponse":[null],"timeout":10000,"responseType":"json","xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"cancelToken":{"promise":{}},"responseEncoding":"utf8"},"code":"ECONNABORTED"}
2020-12-27 11:33:01.732 - error: fb-checkpresence.0 (32384) getMeshList: {}

danke im Voraus

bis denne

[afuerhoff]

@Fenriswolf
Hallo, das ist nicht wirklich ein Fehler. Kommt bei mir auch hin und wieder vor.
Wenn der Adapter die Meshliste abfragt, versucht er das drei mal bevor die Meldung kommt.
Warum hin und wieder die Liste nicht abgefragt werden kann, konnte ich noch nicht ergründen.

PS: Die Meldung kann sicherlich noch optimiert werden.