MikroTik über LBS steuern | Edomi

[jonofe]

möchte ich auch mal zum Anlass nehmen, mich bei Dir für Deine LBS und Deinen unermüdlichen Einsatz hier im Forum zu bedanken - das ist definitiv im besten Wortsinne "außer-gewöhnlich".

Vielen Dank für die Blumen. Immer wieder gerne!

Wir kann ich Dir auf anderem Wege einen monitären Dank zukommen lassen?

Ich habe mal einen SEPA Link ergänzt. Müsste eigentlich jetzt in der Hilfe sichtbar sein.

[saegefisch]

yepp, prima...ist bereits unterwegs...

[saegefisch]

E4 = 1|mac-address ergibt AA:BB:CC:1D:EE:FF an A4

Klappt alles ganz wunderbar mit V1.2 des MikroTik-LBS: Klasse!

Und auch fast mit dem JSON-Extractor. Allerdings habe ich den Effekt bei letzterem, dass wenn das JSON vom MikroTik weniger oder keine MAC mehr liefert (nur noch z.B. "{"MAC_gast":{"count":0}}"), der Selection Path x (z.B. "MAC_gast|1|mac-address"), der nun erfolglos ist, dennoch auf Ax weiter den alten Wert liefert; bei mir die MAC, die aber gar nicht mehr im Gäste-WLAN ist. Ist das so gewollt oder wäre es nicht schöner, wenn ein erfolgloser Path auch nichts mehr liefert? Ich hoffe, es ist reproduzierbar (Screenshot) - nicht, dass ich nur falsch geschaut habe...

Clipboard 1.png

[jonofe]

Das {"MAC_gast":{"count":0}} kommt aber vom Mikrotik-LBS, oder?

Habe es gerade mal nachgestellt. Für eine valide Query, welche kein Ergebnis liefert, erzeugt die MikroTik API ein JSON {count:0}
Ist aber konsistent, da bei einer erfolgreichen Query auch {count:<ANZAHL N>, 1:{index1:wert1}, 2:{index2:wert2}, ... {indexN:wertN}} liefert.

D.h. vom Ergebnis kannst du immer 'count' extrahieren und hast die Anzahl der Ergebnisse. Bei 0 ist eine leer Menge. Ich denke die Konsistenz ist hier sinnvoller als eine Spezialauswertung im LBS.

[saegefisch]

Ja, kommt vom MT aus der Query. Vielleicht habe ich es nicht gut ausgedrückt. Denn der Count ist immer wunderbar und wird vom JSON-Extractor an E1 korrekt geliefert.
Es geht um diese Query: MAC_gast|/caps-man registration-table print|ssid|<Deine Gast-SSID>|mac-address

Wenn sich ein Gerät anmeldet, wird zwischendurch mal z.B.
{"MAC_gast":{"count":1,"1":{"mac-address":"AA:BB:CC:1D:EE:FF"}}}
geliefert wird und nach verlassen des Gastes wieder
{"MAC_gast":{"count":0}},
dann liefert mir der nach gelagerte JSON-Extractor an E2 weiterhin die MAC-Adresse, obwohl sie mittlerweile nicht mehr im JSON enthalten ist, sondern nur vorher mal war. Mir scheint, dass wenn ein Selector Path nach erfolgreichem Finden später nichts mehr findet, der Ausgang dazu nicht geleert wird, sondern den alten Wert weiter ausliefert.

[jonofe]

Der JSON Extractor liefert nur die Werte, die er im JSON findet und die mit den Eingängen matchen. Wenn die MAC Adresse nicht mehr enthalten ist, dann wird auch der Ausgang nicht geupdatet. Er liefert also nur Events. Diese Defaultverhalten würde ich nur ungern ändern. Aber ich könnte mir vorstellen, ein Reset Flag als Eingang vorzusehen. Wenn dies gesetzt ist, werden alle Ausgänge, die zugehörige belegte Eingänge haben, bei Änderung gesetzt, d.h. wenn z.B. E2 gesetzt ist und das Reset Flag ist gesetzt, dann wird A2 auch bei "Non-Match" geupdated und zwar auf leeren String. Könnte aber kollidieren, wenn E2 matched und tatsächlich als Wert einen leeren String liefert. Dann wäre in diesem Fall der leere String nicht mehr erkennbar, denn es ist nicht klar, ob es ein leerer String ist oder der Werte an E2 einfach nicht mehr im JSON vorhanden ist. Irgendwie kompliziert... Ich muss noch mal drüber nachdenken. Ggf. das Reset Flag als String definieren, welche bei Non-Match am entsprechenden Ausgang ausgegeben wird. Ich vermute, das hat jetzt ohnehin niemand verstanden ...

[givemeone]

Aber ich könnte mir vorstellen, ein Reset Flag als Eingang vorzusehen. W

Das hätte ich ehrlich gesagt auch schon mal benötigt.... habe mir intern dazu eine abwandlung des LBS erstellt....

sG Joe

[saegefisch]

Ich vermute, das hat jetzt ohnehin niemand verstanden ...

Doch, doch, das hörte sich nicht nur in Deinem Kopf gut an...

Einfache Lösung: Reset-Flag, um das Verhalten des LBS umzuschalten, wobei das aktuelle Verhalten der default bleibt, Wenn gesetzt, dann leeren bei missmatch.

Universeller: Statt Reset-Flag ein Reset-Content: Wenn leer = default = Verhalten, wie bisher. Wenn irgendwie gesetzt (z.B "na") wird bei Missmatch "na" ausgegeben. Allerdings wünsche ich mir für meinen Fall auch überhaupt keine Ausgabe (kein Telegram) bei Missmatch. Da braucht es vielleicht zwei Optionen als Spezial-Ausprägung für das Feld "<clear>" (leeres Telegram) und "<noout> (kein Telegram)

just my 2 cents...manchmal denk' ich allerdings auch zu kompliziert.... daher: Ich bin gespannt, wie Deine Lösung aussehen wird - sofern Du es überhaupt anpassen möchtest.

[jonofe]

Allerdings wünsche ich mir für meinen Fall auch überhaupt keine Ausgabe (kein Telegram)

Aber das ist doch genau so, wie es aktuell funktioniert. Der Ausgang wird nicht geupdated und bleibt also beim letzten Wert. Oder hab ich da jetzt was falsch verstanden?

[saegefisch]

hm, im oben Screenshot oben sieht es für mich im nachgelagerten LBS so aus, als wenn der Ausgang noch die MAC enthält. Sollte ich den Live-View falsch interpretiert haben?
Wo ich so drüber nachdenke - Du hast recht, für meinen Zweck ist kein Telegramm keine Option, weil das KO oder LBS danach unverändert bleibt - genau das zeigt ja der Screenshot. Sorry, Also ja: ich brauche <clear>, also ein leere Ausgabe und <noout> ist bereits der default.

[jonofe]

Genau, in der Liveansicht siehst du ja immer solange den Wert, bis was neues ausgegeben wird und das ist ja genau dein Problem. Der LBS gibt es nur einmal aus, danach bleibt es aber stehen und somit im nachgelagerten iKO. Also wäre mein Plan jetzt wie folgt:

1. Neuer Eingang E12 "Reset-Content"
2. Wenn Reset-Content nicht gesetzt, dann kein Reset der Ausgänge (Default)
3. Wenn Reset-Content gesetzt, dann Reset der Ausgänge mit dem String des Reset-Content Eingang
4. Wenn Reset-Content = '<clear>', dann Reset der Ausgängen mit leerem String ' ' (ohne Leerzeichen)
5. Default Belegung des Reset-Content Eingang: leer (unbelegt), somit würde beu Update das aktuelle Verhalten nicht geändert und der LBS wäre abwärtskompatibel

Dein beschriebenes Szenario würdest du dann mit <clear> an E12 lösen. Einverstanden?

[saegefisch]

Das hört sich passgenau für unterschiedliche Szenarien an...perfekt!

Aber keine Eile wegen mir, ich kann kann wunderbar an tausend anderen Stellen meines edomi-Neubaus weiter machen..

[jonofe]

Aber keine Eile wegen mir

Wenn ich solche Kleinigkeiten nicht sofort mache, dann geraten sie wieder in Vergessenheit.
Einfach mal die v0.3 ausprobieren. Ich habe nur kurz getestet. Falls es Probleme gibt, einfach hier melden.

[saegefisch]

Klasse! Bin allerdings im Hotel unterwegs...geht erst am Mittwoch Abend...

[saegefisch]

Hallo André,

endlich getestet: V0.3 funktioniert wunderbar mit <clear>. Danke!

VG, Carsten