UnifiVoucherCache: Wie am besten umsetzen?

[Wuehler]

Hallo,

das Modul 74_Unifi.pm habe ich im dazugehörigen Thread testweise um Methoden zum erzeugen und ausgeben von Vouchern zum Zugang zum Gast—WLAN erweitert: https://forum.fhem.de/index.php/topic,40287.msg703047.html#msg703047
Jetzt stosse ich auf ein konzeptionelles Problem und brauche etwas Unterstützung von erfahreneren Modulentwicklern 
Da Unifi über http—request gesteuert wird und das Ganze Non—Blocking umgesetzt ist kann man einen Voucher nicht generieren und sofort den voucher—code zurückgeben. Ausserdem kann es sein, dass mehrere Voucher benötigt werden, so dass man nicht zwei mal denselben code innerhalb einer bestimmten Zeit ausliefern sollte. Die Wartezeit auf einen Voucher sollte aus Akzeptanzgründen auch möglichst kurz sein. Dies ist mit Non—Blocking auch schlecht hinzukriegen.

Wenn ich die Modulentwicklung FHEM richtig verstehe kann man Module aufeinander aufbauen. Ich bin mir leider nicht sicher, welches Vorgehen hoerfür das Richtige ist, und welche Prinzipien ich je nach Umsetzung evtl. verletze. Vier Alternativen:
1) Erweiterung von 74_Unifi.pm um einen VoucherCache.
—>Passt meiner Meinung nach aber nicht wirklich da rein.
2) 74_Unifi wird als ein physisches Modul gesehen und der Cache ist ein logisches Modul.
—>Dann könnte man bei jeder Aktualisierung die X_Parse Funktion aufrufen und die Vouvher im Cache aktualisieren.
3) der VoucherCache ist ein einfaches Modul
—>Dann braucht man zum Aktualisieren einen Timer oder Notifys
4) alles über dummy/notify—Funktionalitäten
—>Könnte ausreichen und unter Codeschnipsel gepostet werden.

Vielleicht gibt es noch mehr Alternativen, die mir nur nicht einfallen.

Was ist eure Meinung?

Danke svhonmal,
Der Wuehler
.

[herrmannj]

Da Unifi über http—request gesteuert wird und das Ganze Non—Blocking umgesetzt ist kann man einen Voucher nicht generieren und sofort den voucher—code zurückgeben.

Bitte um Erklärung was damit gemeint ist.

Verdacht: Du beziehst Dich auf das handling des Webinterface (?) Wenn ja, es gibt eine zum "get" gehörende asynchrone Methode im Webif (fhemweb). Das Ergebnis wird als pop-up dargestellt. Alternativ kann man ein Reading (asynchron) befüllen. Dies kann man dann auch loggen.

Ausserdem kann es sein, dass mehrere Voucher benötigt werden, so dass man nicht zwei mal denselben code innerhalb einer bestimmten Zeit ausliefern sollte.

Bitte um Erklärung was damit gemeint ist.

Die Wartezeit auf einen Voucher sollte aus Akzeptanzgründen auch möglichst kurz sein. Dies ist mit Non—Blocking auch schlecht hinzukriegen.

Was hat das eine mit dem anderen zu tun ?

[Wuehler]

Hallo Herrmannj,

Danke für die Fragen. Unifi stellt für seine Accesspoints und andere Netzwerkgeräte eine Controller—Software zur Verfügung. Darüber kann man dann alle Geräte bequem steuern. Die Software bietet zusätzlich eine Http—Json—Schnittstelle, so dass man die Netzwerkgeräte z.B. auch über scripte steuern kann. Es geht aber auch aus fhem mit dem Modul 74_Unifi. Darin sind einige Schnittstellen implementiert. Dabei wurden aus HttpUtils die Non—Blocking Funktionen für Request und Response genutzt.
Die Accesspoints bieten auch ein Gast—Wlan an, der einen Zutritt ins eigentlich Wlan nur erlaubt wenn man einen 10 stelligen, einmal gültigen Vouchercode in eine Login—Webseite eingibt. Die Gültigkeit der Dauer nach Anmeldung kann ebenfalls bei Erzeugung des Vouchers angegeben werden. Z.B. 2 Stunden. Danach fliegt man aus dem Gast—Wlan.
Szenario: man bekommt Besuch und möchte nicht allen den Key des eigenen Wlans starten. Also jedem einen Vouchercode geben. Meine Kinder fordern den z.B. Über einen Telegrambot an.
Und da gibt es dann die oben beschriebenen Szenarien hintereinander für alle einen Code anzufordern. Hier sollte dann nicht immer derselbe zurückgegeben werden. Bei der Erzeugung eines neuen Vouchers ist der Rückgabewert der API leider nur die create—time, so dass anschließend ein weiterer call gemacht werden muss, um den Voucher zu bekommen. Das dauert ein wenig und ist asynchron und die Idee, Voucher im Modul zu cachen.

Ich habe das bestehende Modul um createVoucher und getVoucherList ergänzt. Habe aber ein konzeptionelles Problem bei der Erstellung der Readings. Das Modul soll ja nicht total vollgemüllt werden.

Ich hoffe ich konnte den Anwendungsfall diesmal besser erklären. Wenn man gerade im Thema drin ist lässt man schnell wesentliches weg. 

[herrmannj]

wenn das "ein wenig dauert" liegt das aber sicher nicht daran das Du den call asynchron machst sondern an der Antwortzeit des Accesspoints.
Die asynchrone (non-blocking) Abfrage ist der einzig richtige Weg !

Wenn der Accesspoint also langsam ist dann existieren 2 Möglichkeiten:

A) dann ist das eben so
B) Du legst Dir codes "auf Vorrat an", zb beim Start von fhem 10 Stück und wenn einer verbraucht wird forderst Du im Hintergrund gleich einen neuen an. Das meinst Du evtl mit cache ? Wenn das Unifi Modul um den voucher erweitert wurde kannst Du das dort implementieren. Würde ich aber mit dem maintainer vorher besprechen. Voraussetzung ist natürlich das die codes ihre Gültigkeit behalten.

Technisch möglich wäre zum Beispiel eine bei Start ein array im modul zu befüllen. Die non blocking get methode für den voucher müsste beim modul start ausgelöst werden. Die callback Funktion prüft dann einfach den Füllstand des arrays. Wenn weniger als gewünscht im array liegen wird der voucher gespeichert und http-get gleich wieder aufgerufen.

Wenn (via fhem get) ein voucher "verbraucht" wird, fordert das modul nach dem gleichen Prinzip einen neuen im Hintergrund an.

Ob sich der Aufwand für Dich lohnt musst Du selber entscheiden.

vg
joerg

[Wuehler]

Danke für den Austausch. Manchmal sieht man den guten Weg einfach nicht selbst  Ein simples get ist natürlich auch möglich. Habe etwas zu kompliziert gedacht.
Aufwand spielt nicht so die Rolle. Ist ja Hobby, dauert dann vielleicht nur etwas länger. Und mit Cache meinte ich die 10 auf Vorrat.

Da die user andere Anforderungen an die Gültigkeit der Voucher haben werde ich noch ein Attribut aufnehmen, in dem der Voucher konfiguriert werden kann. Ausserdem kann man sich intern speichern, wann der Voucher per get abgerufen wurde und das beim nächsten get berücksichtigen.