Zyklischer Aufruf der Gerätesuche

demel42 · 28. Mai 2022 um 14:05

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.

Dr.Niels · 30. Mai 2022 um 08:00

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

demel42 · 30. Mai 2022 um 09:21

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 )

Dr.Niels · 30. Mai 2022 um 12:35

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.

demel42 · 30. Mai 2022 um 13:42

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“.