Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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.
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 : 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.
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ätoder "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,...)
Zuletzt geändert von saegefisch; 17.01.2018, 21:58.
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 .
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.
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ätoder "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
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,...)
Zuletzt geändert von saegefisch; 18.01.2018, 12:24.
Grund: Nachtrag
"Was aber, wenn ich unterschiedliche MC Akteure habe, wie zB SONOS das im VLAN20"
Da muss man sehr genau hinsehen. SONOS benutzt z.B. mDNS was eine Local Link Multicast Gruppe benutzt mit einem festen TTL von 1, was also per se gar nicht routebar ist.
Vielleicht hilft dir der obere Hinweis zum Thema SONOS, den ich erhalten habe ...?
Der Tipp mit dem TTL von 1 ist gut, die Beduetung des TTL war mir so nicht bewusst - egal ob Sonos oder nicht. Das muss ich mal im Hinterkopf behalten für das MC-Thema. Aber andererseits ist Sonos derzeit der einzige MC, der bei mir derzeit ganz gut geroutet wird zwischen VLAN 10 und 30, also funktioniert...
Was derzeit nicht geht bei Sonos und mag aber genau mit Deiner Info zusammen hängen: Das Aufnehmen neuer Geräte geht derzeit nur, wenn mein Controller im selben Netz hängt - was ja per per WLAN kein Problem ist, da ich alle VLAN auch im WLAN anbiete. Aber perfekt ist es noch nicht. Es gibt da also noch irgend ein Traffic bei Sonos der noch nicht geroutet wird. Steht das Sysystem, klappt aber die Bedienung seit der Installation von PIM wunderbar.
Aus anderer Quelle weiß ich auch, dass STP für das ZUsammenspiel von CAPsMAN und VLAN besser nicht aktiviert wird, sondern besser "none" gewählt wird. Macht ja bei <3 Switchen auch üblicherweise wenig Sinn. Bei Sonos auf den Supportseiten hingegen steht, dass STP verwendet/benötigt/sinnvoll ist. Vermutlich, weil die Geräte ja zumeist per WLAN UND LAN angeschlossen werden können und damit wohl die Gefahr von Schleifen besteht. Ich habe bei mir STP auf allen Bridges komplett ausgeschaltet. Das obige Thema mag damit auch zusammen hängen.
Soweit mein empirischer Erkenntnishorizont zu Sonos und MC und mit Bezug zu Deiner Info...
Bleibt auch die Frage: Kann nur der MC-Sender den TTL fest legen oder kann mein Router den bei Bedarf auch überstimmen ("Herr im eigenen Haus")? Oder werde ich "for my convenience" und eine "bessere Nutzererfahrung" (was nerven mich diese Floskeln...) von einem "bewahre-den-Kunden-vor-Wissen-und-speziell-sein"-amerikanischen Produkt eingeschränkt, ohne Option auf Experten-Modus und um die Supportkosten dort zu senken?
So, habe mir n hex POE bestellt und gehe die ganze Geschichte nochmal neu an. Vorteil jetzt ist, dass ich auch neben der laufenden Installation spielen kann
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
.
Kommentar