MikroTik über LBS steuern | Edomi

[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]

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.

[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

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

[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]

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]

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

[saegefisch]

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

[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]

Oh je, Du hast natürlich recht - ich habe schlicht das JSON falsch gelesen. Wenn man Dinge nicht ganz regelmäßig macht, verliert man manchmal den "auf den ersten Blick"-Blick... Aaaargh! sorry. Und danke für Deine Mühe.

---

Etwas ganz anderes, André,

meinen kompletten Neuanfang mit edomi 2.0 ohne Migration 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".
Nur habe ich aus 100% Überzeugung kein PayPal und werde es auch wohl nie haben. Wir kann ich Dir auf anderem Wege einen monitären Dank zukommen lassen?

VG, Carsten

[jonofe]

Heißt das, dass die Eingänge kaskadiert (also in der JSON-Struktur aufeinander aufbauend) betrachtet werden und nicht jeder für sich disjunkt (also jeder vom von der Wurzel ausgehend)?

Nein. Jeder separat. Aber dein JSON sieht so aus:

json.PNG

1 und count sind beides Elemente auf oberster Ebene des JSON.

Als Array sieht das so aus (Annahme in $json ist dein JSON in Array Notation)

$json['count'] = 1 

$json[1] = array('mac-address' => 'AA:BB:CC:1D:EE:FF') 

$json[1]['mac-address'] = 'AA:BB:CC:1D:EE:FF' 

Und so sieht es dann äquivalent im LBS aus:

E1 = {"count":1,"1":{"mac-address":"AA:BB:CC:1D:EE:FF"}}
E2 = count ergibt 1 an A2
E3 = 1 ergibt {"mac-address":"AA:BB:CC:1D:EE:FF"} an A3
E4 = 1|mac-address ergibt AA:BB:CC:1D:EE:FF an A4

[saegefisch]

Mit der v1.2 hat E14 auch die ID, welche dann bei der Antwort an E11 im JSON als Index verwendet wird.

Du bist unglaublich, André! Danke!

So als allgemeiner Hinweis für jeden der nach einem anderen Trenner sucht, der optisch der Pipe etwas ähnlich ist, aber (fast) im allgemeinen Leben (außerhalb Spaniens) nicht vorkommt, wie ! oder ; oder # --> da hilft z.B. ALT+0161 = ¡

[saegefisch]

In dem Fall muss E3 = 1|mac-address sein, da die 1 ja auf derselben Ebene wie count steht.

ah - versuche in nachher mal.

Heißt das, dass die Eingänge kaskadiert (also in der JSON-Struktur aufeinander aufbauend) betrachtet werden und nicht jeder für sich disjunkt (also jeder vom von der Wurzel ausgehend)? Wenn dem so ist, dann konnte ich das zumindest nicht aus der Hilfe zum LBS herauslesen und ein entsprechender Hinweis wäre dort gelegentlich sicher hilfreich.

[jonofe]

wenn ich meine Filter-Ausprägung ein "|" aka. "pipe" enthält und das nun aber auch der Trenner für die Paramneter an E12, E13 oder E14 ist: Wie muss ich das | maskieren? Setzen in "" (des gesamten Filterwerts inkl dem |) hat zumindest nicht geholfen...

Dann werde ich wohl die SSID zumindest meines Gastnetzes mal umbennenen gehen...

Nicht nötig, mit der v1.2 kann man jetzt über E19 den Separator festlegen, der an den Eingängen E10-E15 verwendet wird. Default ist | (pipe)

Und eine zweite Frage: Bei E13 ("GET") kann man eine ID setzen, um die Antworten unterschiedliche Anfragen unterscheiden zu können. Da ich leider mit mancher Frage bei E13 erfolglos bin und bei E14 beantwortet bekomme: Wie unterscheidet man dort die Antworten mehrerer Fragen?

Mit der v1.2 hat E14 auch die ID, welche dann bei der Antwort an E11 im JSON als Index verwendet wird.

ACHTUNG: Wer die Query Funktionalität in der v1.1 oder früher benutzt, muss nach dem Update auf v1.2 die Logik anpassen:

• E14 muss jetzt mit einer ID oder dem Separator an E19 starten
• A11 erzeugt jetzt ein JSON der Form { ID : Query-Result } und nicht mehr { Query-Result }

[jonofe]

In dem Fall muss E3 = 1|mac-address sein, da die 1 ja auf derselben Ebene wie count steht.
Aber Die Fehlermeldung zeigt, dass ich diesen Fehler noch abfangen muss.