Zyklischer Aufruf der Gerätesuche

Erweiterungen PHP-Module (Entwicklung)
1

Hintergrund: es wird ja durch die Gerätesuche regelmässig der auch alle Konfigurationen aufgerufen.
Mit ist nicht bekannt, wie häufig der Aufruf passiert, schient aber u.U. recht häufig zu sein.
Ich hatte heute das Problem, das eine API mit begrenztem Abruf-Limit (Husqvarna) übergelaufen ist und als ich in die AutomowerIO-Instanz geschaut habe (über das auch die Datenabrufe des AutomowerConfig abwickelt) hatte ich alle ca. 30s einen API-Abruf, der nur aus dem AutomowerConfig kommen kann. Interessanterweise ist jetzt wieder Ruhe …

Frage: kann man bei der Modulentwicklung einer Konfiguration aus der Gerätesuche heraushalten bzw die Häufigkeit reduzieren? Bps. kann man unterschiedlich Helden, ob das hierzu verwendete IPS_GetConfigurationForm() von der Gerätesuche oder durch einen Aufruf der Instanz-Konfigurationsseite ausgelöst wurde? Dann könnte ich im Modul was einbauen, um nicht immer alle Abrufe zu machen (zB nur nur jede Stunde mal Daten abfrage, bis dahin aber die Daten aus einem Buffer holt) - aber wenn ich den Konfiguration von Hand aufrufe bzw aktualisiere, sollte er schon mit den aktuellen Daten arbeiten.

2

Unabhängig von der Herkunft des Aufrufs würde ich eher die Rückgabe cachen anstatt hier zu versuchen irgend eine Intelligenz einzubauen. Das solltest du bei GetConfigurationForm sowieso machen, damit du nicht das gesamte System ausbremst oder längere Ladezeiten beim Öffnen der Konfiguration hast.

Sprich:

  • Wird GetConfigurationForm aufgerufen und du hast noch keine Daten und es läuft auch aktuell keine Anfrage, dann gebe eine leere Konfigurationsliste zurück und starte asynchron eine Abfrage
  • Ist die Abfrage fertig aktualisiere per Dynamik die Liste und speichere dir das Ergebnis im Cache
  • Hast du Daten im Cache bei Anfrage via GetConfigurationForm, dann verwende diese
  • Das Aktualisieren kannst du dann ganz individuell gestalten, beispielsweise könntest du beim Aufruf von GetConfigurationForm eine neue asynchrone Anfrage stellen, wenn die alten Daten schon älter als 15 Minuten sind oder dergleichen.

Hier mal eine kleine Beispielimplementation, die sonst auch in der Doku verlinkt ist: SymconTest/module.php at master · symcon/SymconTest · GitHub

3

An einen Cache hatte ich ja auch gedacht, aber es ist aus meiner Sicht ja schon ein Unterschied, wenn eine Benutzer-Interaktion der Grund ist oder eine solche Hintergundfunktion.
Wenn ich als Nutzer interagiere, erwarte ich eigentlich schon, das der aktuelle Stand angezeigt wird, insbesondere, wenn ich den Button Aktualisieren betätige.

Von daher wäre es hilfreich, wenn man wüsste, aus welchem Kontext heraus der Aufruf erfolgt.

Leider sehe ich auch im _IPS-Array keinen Hinweis, auch _IPS[‚SENDER‘] ist in allen 3 Fällen (Aufruf des Konfigurators in der ProConsole, Betätigen des Aktualisieren-Button in diesem Formular sowie der Hintergrundaufruf) PHPModule.

SO sinnvoll ein Cache auch ist; ich stelle mir das beispielhaft plastisch vor: da kauft ein weiteres Endgerät und richtet das in der Hersteller-Cloud ein und muss dann (z.B.) 1h warten, bis er das im IPS einrichten kann …
Würde bedeuten, das ich einen eigenen Button „jetzt aber wirklich aktualisieren“ in die Konfigurations-Formulare integrieren müsste und damit das neu Laden erzwingt, damit der Benutzer neue Geräte dann auch zeitnah sehen kann.

Eine meiner Fragen ist noch offen: wie häufig/in welchem Intervall wird der Konfiguration denn nun aufgerufen? gesehen hatte ich, das die IO-Funktion, die nur aus dem Konfiguration benutzt wird alle ca. 15s aufgerufen wurde, nach einige Zeit war allerdings wieder Ruhe …

Danke dafür, habe ich mir angeschaut. Nur damit ich das richtig verstehe, das berührt primär die Fragestellung, wenn ein Datenabruf lange dauern würde, richtig?
( kleiner „formaler“ Vorschlag: so unformatiert, wie das beim Aufruf des Link im Browser dargestellt wird, ist das etwas schwer zu lesen … ihr hatte ja selbst mal den php-cs-fixer vorgeschlagen :wink: )

4

Die Anfragen kommen von der Konsole selbst, wenn diese offen ist. Anfangs ist das Abfrageintervall recht niedrig (das könnten die 15 Sekunden sein), wird aber dann mit jedem weiteren mal verdoppelt bis es nachher bei maximal einer oder zwei Stunden steht. Wird allerdings zwischendurch ein neuer Konfigurator bzw. Discovery erstellt, wird das Intervall zurückgesetzt.

Und ist der Code bei dir unformatiert dargestellt? Bei mir ist der schön eingerückt mit tollen Kommentaren darüber. Stil ist natürlich auch Geschmacksfrage, aber in meinen Augen sieht das alles wohl formatiert aus.

Wir haben das aber gerade auch mal intern diskutiert und würden den Configurator erweitern wollen, sodass du über ein neues Feld ein minimales Updateintervall definieren kannst. Ist bei der nächsten zyklischen Anfrage der Gerätesuche dieses Intervall noch nicht erreicht, dann wird keine neue Anfrage gestartet. Ich glaube, dass ist eine Variante, die in der Implementation recht einfach für beide Seiten ist und deinen Anwendungsfall erfüllt.

5

Aha, das ist etwas, was die Konsole macht … dann wird mir das etwas klarer, wieso ich auf diese Anzahlen gekommen bin. Wenn das jedes mal so ist, wenn man die Console öffnet … ich habe häufiger das Problem, das die Konsole sich wieder verbindet und natürlich, wenn ich mal nicht tippe, ist fix der Screensaver aktiv und die Console muss sich neu verbinden. Ok, das erklärt meine Beobachtung …

Ich habe gerade nochmal geschaut, das sieht völlig ok aus. Keine Ahnung, wo ich das gesehen habe, aber das war einiges ganz links dargestellt (zB die SetBuffer() in Create(). Also ein Darstellungsproblem bei mir … nur wo, habe ich noch nicht herausbekommen. Sollte ich so etwas nochmal sehen, mache ich direkt ein Screenshot und schreibe mir auf, wie ich dahin gekommen bin.
Einstweilen sorry für den falschen Alarm

ist eine prima Sache und für den Entwickler leicht zu nutzen.

Wobei es auch nicht schlecht wäre, wenn man irgendwo in _IPS den Kontext erkennen könnte und damit zwischen normalem Öffnen und manuellen Aktualisieren unterscheiden könnte. Ich habe einen Anwendungsfall, wo ich für bereits erstellte Geräte keinen weiteren Abrufe mache (es gibt eine API.Call, der die Liste der Geräte liefert und pro Gerät noch einen Call für Geräte-Details). Also unterlasse ich bei bereits erstellen Instanzen die Detailabfrage (weil ich schon alles in den Instanz-Properties habe).
Bedeutet natürlich, das ggfs.Differenzen zwischen Informationen des Hersteller-Systems und IPS nicht erkennbar wären. Ist natürlich ein mehr akademisches „Problem“ und jammern auf hohem Niveau und wenn das nicht passt, ist das selbstredend „verschmerzbar“.

6

Hallo @Dr.Niels : ich nehm an, das Feld ist discoveryInterval?
Ich habe das jetzt mal ein einem Konfigurator eingebaut mit dem Wert 60 * 60 * 24 (also 1 Tag). Leider wird der Konfigurator mindestens 4 mal pro Stunde aufgerufen (hatte letzte Tage wieder mehrfach die Situation (wie seinerzeit) das der Konfigurator das Limit für API-Calls (hier bei Husqvarna/Automowe) durchbricht (zulässig sind 10000 Calls/Monat, danach ist der Zugriff für den Rest des Monats gesperrt). Bei letzten Mal ist es bei dem Modul Miele@Home aufgetreten…

Ich kann natürlich nicht genau nachweisen, das es der Konfigurator ist, aber der Konfigurator nutzt als einziger einen bestimmen API-Call und der kam extrem häufig vor.
Ich habe daher in das Modul eingebaut, das es genau protokolliert, welche Instanz welche Calls wie häufig macht. Habe dann alle Browser (Konsole) sei Pro-Console geschlossen und zu Sicherheit IPS gebootet.
Dann habe ich abgewartet und nach >1h geprüft, wie häufig wird der API-Call gemacht: und es waren wieder 4 Aufrufe durch den Konfigurator. Und dann in den nächsten 2 Stunde, obwohl ich die Pro-Console mehrfach neu gestartet hatte, nur ein mal? Ich kann da keine Systematik erkennen, was entgeht mir da?

Du hattest ja oben darauf hingewiesen, das die Console das selbst auslöst. Aber es scheint (wie im auslösenden Fall letzte Woche) irgendwann nachts passiert zu sein, das er einige 1000 Aufrufe gemacht hat … so ganz ohne Benutzer oder aktivem Rechner. Ist schon sehr merkwürdig. Passiert ja auch nur ab und an (das letzte mal vor 6 Monaten), aber wenn es passiert, ist das unschön.

Bei diesen API’s macht auch die zynische Prüfung überhaupt keine Sinn, denn man bekommt ja nicht einen neuen Rasenmäher oder ein Haushaltsgerät, auf den einen IPS aufmerksam machen sollte; das sind ja ziemlich statische Situationen. Da müsste ja eigentlich ausreichen, das ein Abrufe sehr selten oder rein manuell erfolgt.

Natürlich kann ich in allen diesen Module mit externen API im Konfigurator ein Attribut (oder Buffer) machen, das als Cache dient und aus dem immer die Daten zur Darstellung geholt werden und einen eigenen Button, der dann diesen Cache aktualisiert. Automatisch, wenn überhaupt sinnvoll, alle 24h.
Dann gibt es 2 Refresh-Button, den über der Liste und einen zusätzliche Button im Aktionsbereich? Der über der Liste hat keinen Effekt, das ist nicht unbedingt intuitiv.

Nachtrag: ich habe im ersten Modul so einen Cache implementiert.
Es bleibt über, das discoveryInterval nicht so funktioniert hat, wie ich es erwartet/verstanden habe
Und natürlich, das es nun zwei Buttons zum Aktualisieren gibt

7

Magst du mir mal einen Link zu deinem Modul schicken? Dann schaue ich mir das mal an. Denn eigentlich sollte das genau so funktionieren…

8

gerne, ich habe die letzten Änderungen bisher nur in git: GitHub - demel42/IPSymconAutomowerConnect: Interface to Husqvarna Automower with Connect-Module

9

Danke, ich werde das mal bei mir laufen lassen und schaue, was so passiert :+1: