MikroTik über LBS steuern | Edomi

[saegefisch]

Dann macht der Router ggf. mehr Smarthome als Routing.

hihi...ja, der Gedanke kam mir auch schon. Aber mit etwas drüber Nachdenken werden wir sicher einen sinnvollen Kompromiss finden. Ich vermute daher auch eher, ich möchte Ereignis-gesteuert mal in niedriger Frequenz, mal in hoher Freuqenz (z.B. wenn der Haustürsensor eine Öffnung bemerkt) Daten aus dem MT in edomi aus Abfragen bekommen und die Logik besser in edomi machen. Aber dafür braucht es einen sinnvollen Weg, Log-Daten oder Script-Ergebnisse per API aus dem MT geliefert zu bekommen.

Wunderbar...derlei ist ja genau das, wofür wir hier im Forum sind...
aber morgen ist ein neuer Tag. Ich muss jetzt erst einmal die für den LBS übergangene letzte Nacht nachholen...
------
Nachtrag:

Im Moment gar nicht. Ich weiss nicht, ob die MT API das hergibt, dass man die Ausgabe des gesamten Skripts zurück bekommt.

Die Ausgabe schient "plain" oder als array (Beipspiel inside) zu gehen. Gerade für die Weiterverarbeitung in edomi könnte array ja gut sein - aber dann wohl eher im PHP eines spezifischen LBS, weniger als Ausgabe Deines tendenziell generischen API-LBS. Dafür müsste man sich mal ein Stück PHP-Code vielleicht als Kopiervorlage einer function entwicklen für Login und ausführen per API in eigenen LBS. Muss mir dazu mal Dein coding anschauen...

Vielleicht 1x täglich holt man sich mit einem Service-LBS die DNS und DHCP-Namen zu den MAC-Adressen und vielleicht noch andere Dinge nach edomi. Dann ruft man in bedrafgerechter Frequenz mit anderen LBSen die anderen Fragestellungen auf, macht in edomi den lookup für die Namen und baut sich seine Ausgabe für die Visu zusammen (angemeldetet Geräte, angemeldet wireless,...)

[jonofe]

[QUOTE=saegefisch;n1183252]

• Noch habe ich die E10-E13 noch nicht ganz verstanden, aber werde mir der Hilfe noch veruschen, Anwendungsfälle dafür zu entwicklen und zu testen.

Enable/Disable sind zum aktivieren/deaktivieren von Menüeinträgen, z.B. bestimmte FW-Regeln
Mit Set kann man bestimmte Werte in Menüeinträgen setzen und mit Get bestimmte Menüeinträge abrufen, die dann an A13 angezeigt werden.
Beim Get gibts aber noch einen Exception Fehler, wenn die Get Abfrage nicht richtig konstruiert ist. Das muss ich mir noch mal anschauen.
Für so eine wie von Dir beschriebene highly sophisticated Anwesenheitserkennung ist der LBS allerdings derzeit nicht geeignet. Dafür wären auch sicher viele verschiedene Abfragen in kurzer Zeit notwendig. Das kann dann auch schon mal schnell auf die CPU Last im MT gehen.

• Kann ich auch auf dem MT vorhandene Scripte auf dem MT ausführen? Sollte wohl klappen mit " /system script run <Scriptname>" an E9, oder?

Ja, so sollte das funktionieren.

• Wie bekommt man Ergebnisse z.B. aus einem Script an edomi? Kommt das auf A10, wenn ich in E9 ein Script ausführe?

Im Moment gar nicht. Ich weiss nicht, ob die MT API das hergibt, dass man die Ausgabe des gesamten Skripts zurück bekommt.

Genau wie andere schon anmerkten, wäre noch interessant:

• Traffic

Welchen Traffic genau? Interessant wären hier die Consolen Statements, die die entsprechend gewünschte Ausgabe erzeugen.

• angemeldete Geräte -> aus ARP, nicht aus DHCP; am beste aber mit aufgelöstem Namen per MAC aus 1.DNS und wenn erfolglso aus 2. DHCP: Klartext ist in edomi einfach netter...
• am CAPsMAN registrierte Geräte; ebenfalls am besten mit aus MAC aufgelöstem Active Host Name. Zusätzlich mit Rx-Signal und TX/Rx-Rate
• bestimmt gibt's da noch mehr...

ARP ist ja die Auflösung von IP Adressen in Ethernet Adressen. Und wenn ein Eintrag in der ARP Tabelle ist, dann bedeutet es, dass der MT in der ARP-Timeout Zeit (default 30s, aber in /ip settings einstellbar) mit dem Client versucht hat zu kommunizieren. Ob das jetzt die besser Quelle für eine An/Abwesenheit ist, müsste mal prüfen.

Zu den Themen ist immer die Frage: Ob und wie das zu lösen ist; teilweise vorbereitet mit Scripten auf dem MT oder komplett dort oder komplett in edomi und hier wieder im LBS oder per Logik?

Da habe ich derzeit auch keine Antwort drauf, außer, dass es immer eine Abwägung zwischen Aufwand und Nutzen ist.
Gleiches gilt für die Toleranzzeit, welche du übrigens über E16 einstellen kannst. Wenn an E16 eine 30 steht, dann bedeutet dies, dass ein neuer An-/Abwesenheitszustand nur dann signalisiert wird, wenn dieser für mindestens 30 Sekunden besteht. Ein ständiges An-/Abmelden kann ich bei unseren Android Devices nicht beobachten, auch nicht nachts. Aber es macht vermutlich Sinn diese Toleranzzeit nur für die Änderung von anwesend zu abwesend zu berücksichtigen, denn wenn es einen connect gibt, dann weiss man sofort, dass das Gerät tatsächlich da ist.

Zur Anwesenheitserkennung ganz allgemeine Gedanken für eine sinnvolle Erkennung aus meiner Sicht. Da ruhende Geräte meist alle 5-15 Minuten sich kurz wieder anmelden, braucht es da Toleranz. Zudem gibt es das Thema Flugmodus; zumindest das iphone ist in der ARP-Liste noch zu sehen (im Status "D", nicht mehr "DC" = "not completed"), aber nicht mehr im CAP. Ebenso sind für die Anwesenheit vor allem wichtig:

• ist irgend jemand daheim - das darf und muss vermutlich auch ein wenig Toleranz haben (s.o.)
• Kommt jemand (als erstes) nach Hause - das will man sehr schnell wissen, auch wenn es die Jüngste ist, die auch mal ohne Mobilgeräte weg war: Dafür daher BWM im Flur hinter Eingangstür bzw. Fingerprint an Hasutür (da weiß man sogar, wer)
• Spannend ist auch das Gehen im Vergleich zum daheim vergessenen Gerät oder "auf dem Sofa eingeschlafen". Da wäre es spannend, die bis zum Max. fallende Rx-Signal-Stärke zu erkennen im Vergleich zu einem Gerät, dass sich alle x Minuten kurz mal meldet - ohne (= liegt) oder mit eher leichten Schwankungen in der Signalstärke (= wird im Haus bewegt). Der Fade-out der SIgnalstärke - ggf. mit Validierung gegen Entfall aus ARP-Liste - scheint mir eigentlich ein starkes Indiz für "Person verlässt das Haus". Im Zweifel bleibt das Haus lieber einmal zuviel aktiv, als einmal zu früh in standby zu gehen.
• Mir persönlich geht es weniger um konkerte Personen an konkreten Orten im Haus; mir geht es vor allem um das herunter fahren des Hauses, wenn wirklich(!) niemand mehr da ist (also nicht, wenn man auf dem Sofa eingeschlafen ist oder die Geräte nachts im Flugmodus sind) möglichst ohne false-psoitiv-Erlebnissen. Das nach-Hause-kommen ist für mich bereits gelöst.
• Personenbezogene und oder ortsbezogene Aktionen sind für mich eher nebensächlich - aber irgendwann sicher auch spannend; andere haben da auf jenden Fall andere Fragestellungen (waren da nicht eine Frage mit ein paar AP im Garten?).

Bin gespannt auf den Diskurs mit Euch zum Thema: Sinnvolle Erkennung des Gehens und Kommens im Verglich zu alltäglichen Situationen (schlafen, liegen lassen), aber auch zur Frage, wie und wo man das am besten technisch löst (MT, LBS,...)

Man kann natürlich beliebig spezielle Situationen versuchen abzubilden, allerdings ist auch dies eine Aufwands/Nutzen Abwägung. Was passiert z.B. wenn ein Telefon ausgeschaltet wird oder der Akku leer ist? Wenn man abfallende Signalstärke betrachten will, dann ist die Überwachungsfrequenz schon ziemlich hoch und das dann noch für 4 oder 5 Geräte. Dann macht der Router ggf. mehr Smarthome als Routing.

Weiteres Feedback gerne hier und dann können wir das mal in eine priorisierte Reihenfolge bringen

[stonie2oo4]

• Kann ich auch auf dem MT vorhandene Scripte auf dem MT ausführen? Sollte wohl klappen mit " /system script run <Scriptname>" an E9, oder?

Hab ich ehrlich gesagt auch nicht hinbekommen. Hab's dann kurzerhand anderst gelöst.
Neuer User "edomi" in Mikrotik angelegt. Ebenso neue Gruppe mit Rechten für ssh und test. Warum auch immer test, ohne gings nicht .
Zugriff für ssh unter Services nur für den edomi Server erlaubt.

Dann unter Edomi per ssh ein Public Key erstellt und diesen im Mikrotik importiert. Nun kann ich einfach über die Edomi Shell Befehle ausführen, ohne Passworteingabe.
Momentan nutze ich es für Wake on LAN. Da dies nicht über die VLANs hinweg funktioniert.
Hat wahrscheinlich auch was mit Multicast zu tun. Unter anderem les ich deswegen hier auch sehr interessiert mit

Wäre aber auch dran interessiert es über den LBS zum laufen zu bekommen, alleine schon wegen einer möglichen Antwort vom Mikrotik. Weiß zwar momentan noch kein Anwendungsfall, aber find bestimmt was .

[saegefisch]

Script Funktion ist in der aktuellen Version 0.7 verfügbar.

Hi André,
heute bin ich endlich dazu gekommen, Deinen LBS zu installieren. Ein erste Rückmeldung - darum ging es eigentlich in diesem Threat:

• Die Erkennung von Anwesenheiten klappte auf Anhieb. Werde mir aber für den edomi-Zugang noch einen edomi-User mit beschränkten Rechten auf dem MT anlegen; admin war mir dann doch zu viel des guten.
• Noch habe ich die E10-E13 noch nicht ganz verstanden, aber werde mir der Hilfe noch veruschen, Anwendungsfälle dafür zu entwicklen und zu testen.
• Kann ich auch auf dem MT vorhandene Scripte auf dem MT ausführen? Sollte wohl klappen mit " /system script run <Scriptname>" an E9, oder?
• Wie bekommt man Ergebnisse z.B. aus einem Script an edomi? Kommt das auf A10, wenn ich in E9 ein Script ausführe?
• Genau wie andere schon anmerkten, wäre noch interessant:
  • Traffic
  • angemeldete Geräte -> aus ARP, nicht aus DHCP; am beste aber mit aufgelöstem Namen per MAC aus 1.DNS und wenn erfolglso aus 2. DHCP: Klartext ist in edomi einfach netter...
  • am CAPsMAN registrierte Geräte; ebenfalls am besten mit aus MAC aufgelöstem Active Host Name. Zusätzlich mit Rx-Signal und TX/Rx-Rate
  • bestimmt gibt's da noch mehr...

Zu den Themen ist immer die Frage: Ob und wie das zu lösen ist; teilweise vorbereitet mit Scripten auf dem MT oder komplett dort oder komplett in edomi und hier wieder im LBS oder per Logik?

Zur Anwesenheitserkennung ganz allgemeine Gedanken für eine sinnvolle Erkennung aus meiner Sicht. Da ruhende Geräte meist alle 5-15 Minuten sich kurz wieder anmelden, braucht es da Toleranz. Zudem gibt es das Thema Flugmodus; zumindest das iphone ist in der ARP-Liste noch zu sehen (im Status "D", nicht mehr "DC" = "not completed"), aber nicht mehr im CAP. Ebenso sind für die Anwesenheit vor allem wichtig:

• ist irgend jemand daheim - das darf und muss vermutlich auch ein wenig Toleranz haben (s.o.)
• Kommt jemand (als erstes) nach Hause - das will man sehr schnell wissen, auch wenn es die Jüngste ist, die auch mal ohne Mobilgeräte weg war: Dafür daher BWM im Flur hinter Eingangstür bzw. Fingerprint an Hasutür (da weiß man sogar, wer)
• Spannend ist auch das Gehen im Vergleich zum daheim vergessenen Gerät oder "auf dem Sofa eingeschlafen". Da wäre es spannend, die bis zum Max. fallende Rx-Signal-Stärke zu erkennen im Vergleich zu einem Gerät, dass sich alle x Minuten kurz mal meldet - ohne (= liegt) oder mit eher leichten Schwankungen in der Signalstärke (= wird im Haus bewegt). Der Fade-out der SIgnalstärke - ggf. mit Validierung gegen Entfall aus ARP-Liste - scheint mir eigentlich ein starkes Indiz für "Person verlässt das Haus". Im Zweifel bleibt das Haus lieber einmal zuviel aktiv, als einmal zu früh in standby zu gehen.
• Mir persönlich geht es weniger um konkerte Personen an konkreten Orten im Haus; mir geht es vor allem um das herunter fahren des Hauses, wenn wirklich(!) niemand mehr da ist (also nicht, wenn man auf dem Sofa eingeschlafen ist oder die Geräte nachts im Flugmodus sind) möglichst ohne false-psoitiv-Erlebnissen. Das nach-Hause-kommen ist für mich bereits gelöst.
• Personenbezogene und oder ortsbezogene Aktionen sind für mich eher nebensächlich - aber irgendwann sicher auch spannend; andere haben da auf jenden Fall andere Fragestellungen (waren da nicht eine Frage mit ein paar AP im Garten?).

Bin gespannt auf den Diskurs mit Euch zum Thema: Sinnvolle Erkennung des Gehens und Kommens im Verglich zu alltäglichen Situationen (schlafen, liegen lassen), aber auch zur Frage, wie und wo man das am besten technisch löst (MT, LBS,...)

[coliflower]

... doch andere Multicast aus anderen VLANs dann nicht mehr (da meines Wissens nach auf 1 Upstrem begrenzt).

Das stimmt leider ... Aber momentan brauche ich - hoffe ich - keine anderen Multicasts aus anderen Quellen/VLANs.

[saegefisch]

WagoKlemme : Danke für Deine Rückmeldung, das freut mich sehr, dass es Dir geholfen hat. Bin auch selber weiterhin vom Vorgehen mit den Scripten überzeugt...

Da gerade in meinen Firewall-Regeln mittlerweile auch eine Menge Arbeit drin steckt: Ich will versuchen, ein Update dazu am WE zu liefern.

[saegefisch]

Ich habe dann auch die FW-Regel für das VALN10-Interface angepasst (PASS), danach flossen die Information via Multicast von VLAN10 an VLAN50, dh, der IGMP scheint zu funktionieren.

Das ist ja auch eine gute Nachricht!
Aber nach meinem Verständnis geht das genauso gut und einfach mit PIM. Bei IGMP-Proxy dürfte damit jedweder multicast aus VLAN10 damit möglich sein, doch andere Multicast aus anderen VLANs dann nicht mehr (da meines Wissens nach auf 1 Upstrem begrenzt).

[WagoKlemme]

Hallo Carsten ( saegefisch ),

heute ist mein RB3011 gekommen und als Initialsetup habe ich deine Scripte eingespielt. Abgesehen vom Gemecker bzgl. Line 1 und verschiedenen Anfängerproblemchen mit Winbox, hat alles auf Anhieb richtig gut funktioniert. VLANs, Bridges, NAT, FW arbeiten bisher wie erwartet. An meiner Infrastruktur muss ich noch was ändern, ansonsten TOP.
Der Setup über Scripte hat mich vollends überzeugt. Schneller geht nicht.

Vielen Dank für diese ausgezeichnete und durchdachte Arbeit, da stecken viele Stunden drin !!!!

Am Freitag kommen auch noch ein hap ac und ein hex POE, somit kann ich auch noch WLAN in Aktion bringen.
Der RB3011 ist schon ein cooles Teil für den Preis. Mit dem USB-Anschluß kann man auch noch nette Sachen machen, sehr schön. Auch das LCD, schick.

[coliflower]

Hallo Dariusz,

auch in der ETS5 werden die Schnittstellen normalerweise automatisch erkannt.
Zumindest wenn Multicast nicht geblockt ist.

Gruß, Klaus

Hallo Klaus,

erlaube mir noch eine Verständnisfrage, dh, dass die ETS5 ein Empfänger des Multicast ist und das KNXnet/IP-GW der Sender ?

Danke vorab, Dariusz

[coliflower]

saegefisch
Grundsätzlich zum Multicast - quick and dirty habe ich mal das IGMP.Proxy "aktiviert" und für VLAN10 den UPstream (Sender of Multicast, mit der Adresse des KNXnet/IP-Routers) und für VLAN50 den DOWNstream (Receiver of Multicast für das VLAN50net) zugewiesen ..
Gleich danach konnte ich die neu geblockten Pakete an der Firewall sehen, nämlich, Interface = VLAN10, Source = 10.0.10.2 (GW), Destination 224.0.23.12:3671.
Ich habe dann auch die FW-Regel für das VALN10-Interface angepasst (PASS), danach flossen die Information via Multicast von VLAN10 an VLAN50, dh, der IGMP scheint zu funktionieren.

[Janncsi]

Jetzt hat es mich doch mal übermannt und ich hab mir gerade die Möglichkeiten bzgl. des CRS in Verbindung mit Multicast angeschaut.

Ich habe nämlich ebenfalls einige Probleme, die ich mir bisher nicht erklären kann, die aber wunderbar zu den hiesigen Fehlerbeschreibungen passen (bspw. die nicht Erreichbarkeit meines Denon Heos von einem anderen Vlan, die Verbindungsabbrüche in der ETS, etc.)

Nun las ich gerade das in dem Manual:CRS features:

CRS125 switch-chip supports up to 1024 entries in MFDB for multicast forwarding. For each multicast packet, destination MAC or destination IP lookup is performed in MFDB. MFDB entries are not automatically learnt and can only be configured.

Jetzt muss ich das ganze nur noch verstehen, damit ich weiß, was ich da machen kann...:-D

[saegefisch]

Für den Fall wären wohl zwei PIM-Interfaces nötig: 10.0.10.0/24 und 10.0.50.0/24. bzw. eher deren vlan-bridges Dazu ein RP, vermutlich 10.0.10.1. Die FW braucht einen Forward-Regel für 224.0.23.12. Dazu zwei forward-Regel für hin und zurück --> da ist der/die Ports erforderlich und das/die Protokolle.

[coliflower]

Unabhänging vom Problem das ich habe ... Ich würde es gerne versuchen zu verstehen.

oder Schicht 3 (als IP-Broadcasts mit Adressierung ueber IP-Adressen) - KNX-Multicasts sind IP-basierend und gehoeren daher zu Schicht 3 (Vermittlung).

Multicast läuft von 224.0.0.0 bis 239.255.255.255 ...
Reserviert für KNXnet/IP ist die 224.0.23.12

Sendet jetzt die ETS5 ein Multicast von 224.0.23.12 ins LAN und warte auf eine Antwort von KNXnet/IP-Router um diesen als "erkannt" in der ETS5 darstellen zu können ?
Wenn ja, was hindert dann die ETS5 im VLAN50 das GW im VLAN10 zu finden ... ist das dann die 224.0.23.12 die nicht zwischen den zwei privaten Netzwerken 10.0.10.0/24 und 10.0.50.0/24 "flutschen" kann ?

[wintermute]

OK, danke, ich dachte es irgendwo so gelesen zu haben, da ein VLAN doch auf L2 aufbaut (hoffentlich irre ich mich auch hier nicht, da L1 Bits sind).

Ja, im siebenschichtigen Modell arbeitet ein VLAN in Schicht 2 (weil es da um Ethernet-Frames geht), Broad- & Multicasts gibt es entweder in Schicht 2 (als Ethernet Broadcasts, also mit Adressierung per MAC-Adresse) oder Schicht 3 (als IP-Broadcasts mit Adressierung ueber IP-Adressen) - KNX-Multicasts sind IP-basierend und gehoeren daher zu Schicht 3 (Vermittlung).
(Ich bin uebrigens ein Verfechter des 4-schichtigen Modells wenn es um IP geht aber ich will hier niemanden verwirren )

[coliflower]

Hier habe ich einen Tip von einem Netzwerker und einen Link zum Thema Multicast:

Ja, Multicast geht ohne weiteres nicht über geroutete Interfaces. Dazu musst du PIM Routing aktivieren, was die pfSense aber kann.
Auch ist es sehr wichtig WELCHE Multicast Gruppe hier verwendet wird !!
Es gibt Gruppen die nur ein lokales Multicasting zulassen. Dort ist der TTL Wert (Time To Live = ein Hopcounter) fest auf 1 gesetzt. Solche MCs können gar nicht geroutet werden...sollten sie auch nicht. Dazu gehört z.B. mDNS (Bonjour), VRRP und einige andere.
Da musst du dann einen Proxy einsetzen, wie z.B. HIER.
Also mal den Wireshark nehmen und belauschen mit welcher MC Gruppe deine KNXe da reden.
Eine super Quelle MC zu verstehen ist auch hier:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Zieh dir mal die ersten 3 Teile rein, dann bist du schlau ! MC ist kein Hexenwerk.