[Featurewunsch] KNX-Modul auf INBOUND beschränken können

[saegefisch]

Hallo Christian,

Mal wieder etwas für 'uff die Liste, gaert : Es wäre für DEV-Instanzen, Fallback-Instanzen, System-Umzüge auf neue HW/VM und andere Zwecke sehr hilfreich, wenn man den KNX-Verkehr von edomi nicht nur ganz an/ausschalten könnte, sondern wahlweise auch nur den OUTBOUND. Damit würde eine Fallback-Instanz zB auf dem aktuellen Stand gehalten werden können aus dem Backup der aktiven, aber nur lesend KNX erhalten, doch nie etwas senden, dennoch prüfbar mit allen Eingangswerten funktionieren. Das wäre schön transparent/sichtbar/wohlfühlbarer. Im Fall eines Problems der Aktiven könnte man mit einem Handgriff die Fallback-Lösung in Betrieb nehmen, ggf. sogar völlig automatisch

Ich habe keine Ahnung, wie kompliziert oder einfach das ist; vielleicht ist's ja einfach. Dann wär's was hilfreiches für irgend ein nächstes Release.

Integration: Was ich mir vorstellen könnte, wäre in der Basis-Konfig zum KNX-Modul einen weiterem Parameter "OUTBOUND unterdrücken":
0 = nicht unterdrückt/Regelbetrieb (default)
1 = unterdrückt
2 = per System-KO gesteuert (weiteres System-KO: 0=nicht unterdrückt | 1 = unterdrückt)
3 = per System-KO und integriertem Watchdog (wenn das weitere System-KO nicht regelmäßig 1 erhält, dann automatisch 0 nach x Sekunden)

Wobei 2 und erst recht 3 schon Kür wäre; hilfreich zweifellos, aber vermutlich deutlich aufwändiger.

Um das ganze gleich etwas zu entspannen...zugegeben kein must-have, denn...Für DEV geht auch eine leere Instanz mit allen GA; dann sendet da auch keine Logik. Und für einen Umzug schaltet man bei der alten halt das KNX-Modul ganz ab, bevor man die neue startet. Aber für ein fast nahtloses Fallback... auch dazu wurde hier in den letzten Jahren immer wieder mal diskutiert, wie man das lösen könnte mit aktueller Technik. Aber das war immer aufwändiger, zum Teil mit HW gelöst.

Danke, viele Grüße und einen guten Start in 2022 wünsche ich Dir,
Carsten

[saegefisch]

Und bis dahin direkt die Nachfrage in die Runde: Kann man das nicht per Firewall auch hinbekommen? Einer IP den KNX-Verkehr nur in eine Richtung zu erlauben? Ich hab's versucht, aber leider nicht erfolgreich mit meinem MikroTik-Router. Entweder kam in beiden Richtung nix oder inkl. OUTBOUND. Bin da wohl möglich noch nicht über die erforderliche Option gestolpert. War da jemand schon weiter?

[starwarsfan]

Hallo miteinander

Kann man das nicht per Firewall auch hinbekommen? Einer IP den KNX-Verkehr nur in eine Richtung zu erlauben?

Bin jetzt kein Firewall-Spezialist aber das geht sicher. Nur wird das dann wohl zu einer Unmenge an Errors im Edomi-Log führen, da ja aus Edomi-Sicht ein "Problem" mit der Kommunikation vorliegt. Edomi weiss ja nicht, dass da noch eine Firewall davor ist. Von daher wäre das über eine entsprechende Option natürlich sehr schick...

[tobiasr]

Sollte man das ganze anfassen, wäre aber eine Trennung zwischen Ausgehend und Eingehend praktisch und die aktuelle Funktion "alles deaktivieren" wäre erfüllt, wenn Ein- und Ausgehend deaktiviert ist. Jetzt fragt mich nicht nach dem speziellen Fall, in dem die eingehende Unterdrückung alleine sinnvoll wäre. Aber er kommt garantiert kurze Zeit nachdem es aufwändig umgebaut wurde.

[saegefisch]

tobiasr : hat für mich so was von "kleinem Finger, ganze Hand"... entweder KNX-Modul aus oder nur hörend. Nur schreibend ohne hörend? Sorry, dafür fehlt mir die Fantasie... egal... sollte Christian da dran gehen, wird er das wie immer sehr durchdacht einbauen. Auch gerne mal über meine Fantasie hinaus...

starwarsfan : ist das tatsächlich so? Bekommt edomi nicht vom IP-Interface sein ACK oder erwartet edomi tatsächlich eine Bestätigung des Aktors? Bin da gerade nicht so tief drin... hab's daher wohl möglich nicht vollends durchdacht... im letzteren Fall hast Du natürlich recht... da wird das Log schnell größer als das Kamera-Archiv...

[vento66]

Gähn:

https://knx-user-forum.de/forum/proj...us-unterbinden
https://knx-user-forum.de/forum/proj...as#post1364661
https://knx-user-forum.de/forum/proj...98#post1371998

[saegefisch]

naja, zum Teil richtig, zum Teil verliefen die Fragen aber auch im Sande... es bleibt meines Erachtens eine spannende und wünschenswerte Funktion.
Aber im Sinne von "Christian nicht nerven mit Fragen wiederholen" - was ich ja auch gerne mal bei anderen ins Feld führe: Da hast Du recht.

Daher gähne ich mal zur Hälfte mit, die andere Hälfte ist noch damit beschäftigt, aus den ganzen Threads eine für mich nutzbare Lösung heraus zu arbeiten. Für DEV kein Thema, da habe ich für mich seit Jahren eine prima Lösung mit leere VM. Aber für Fallback sehe ich weiterhin keine gute Lösung und die treibt mich durchaus um, weil ich versuche, Komplexitäten aus meiner gesamt-IT zu nehmen, aber auch Ausfallsicherheit für meine Familie zu erreichen, wenn ich mal wieder beruflich unterwegs bin. Und da lese ich in der Vergangenheit keine für mich sinnvollen Lösungen. Diese hier wäre eine solche Lösung.

Wenn FW keine alternativ sinnvolle Lösung ist (siehe oben) und Christian dies nicht für sich als sinnvolle Erweiterung aufnimmt, wird es auch hier im Sande verlaufen - wie bei den anderen Threads auch. Dann ist das halt so.

[philipp900]

Ich habe mir mal die entsprechenden Teile im Code angesehen.
Zumindest das reine Blockieren des Sendens, so dass ACK usw. trotzdem noch funktioniert, lässt sich relativ einfach umsetzen.
Jegliches Schreiben, sowie InitSend würden blockiert werden.

Die Frage ist noch, wie man mit dem InitScan und Requests verfahren soll.
Denn das sind im Grunde auch schreibende Befehle auf den Bus.
InitScan müsste man vermutlich trotzdem erlauben.

Blockieren in der Firewall wird nicht funktionieren, da der Tunnel immer eine bidirektionale Verbindung braucht.

[saegefisch]

Dank' Dir für Deine Erkenntnisse und Einordnung auch der FW-Idee. InitScan hatte ich noch nicht bedacht; klar, das muss eigentlich erlaubt werden und schließt den FW-Ansatz umso mehr aus. Ebenso Read-Requests. Gehört ja inhaltlich auch zum Lesen, technisch/formal natürlich aber zum Senden.

Mal schauen, ob und was davon irgendwann in ein Release einfließt.

[saegefisch]

Frage zum Umzug einer produktiven edomi-Instanz (Beide Systeme auf exakt gleichem Stand CentOS/edomi, aber bewusst unterschiedliche IP) - den ich gerade vor mir habe und in den letzten Tagen in diversen Threads behandelt wurde:

1. Quelle: Backup machen
2. Quelle: KNX-Modul abschalten
3. Ziel: Manuelle Installationen durchführen für diverse LBS
4. Ziel: Backup einspielen
5. Ziel: IP in Basis-Konfig auf Ziel-IP ändern (mit der auch CentOS installiert wurde)
6. Ziel aktivieren

Aber nun: Jedes Backup enthält einerseits die IP, aber auch ein aktives KNX-Modul. Wenn man dies regelmäßig im Fallback-System einspielen möchte, muss man jedes Mal in der Basis-Konfig IP ändern und KNX-Modul deaktivieren, richtig? Habe ich Weiteres übersehen?

---

Wäre fast noch ein Featurewunsch: Beim Einspielen eines Backups ("Wiederherstellung") Teile der Basis-Konfig ausschließen, z.B. IP-Adresse (oder alternativ noch besser aus BS auslesen und übernehmen) und alle Modul-Status festlegbar, also z.B. KNX- und eMail-Modul inaktiv einspielen, obwohl im Backup beide aktiv sind.

[givemeone]

Ein kurzer Einwurf :
Experimentiere gerade mit einem sehr ähnlichen Problem.
um das umzusetzen, binde ich im Moment knx komplett nur per mqtt ein. Das knx Modul in Edomi habe ich dann deaktiviert. Somit kann ich das über jonofes Bausteine steuern. Geht eigentlich kocht schlecht bisher, ob ich es so belasse, habe ich noch nicht entschieden.

[jonofe]

binde ich im Moment knx komplett nur per mqtt ein

So habe ich es auch schon gemacht, um einen EDOMI Server an einem anderen Standort zu syncen.
Im Moment ist das aber mangels zweitem Standort nicht mehr aktiv.
Hatte in dem Zuge auch überlegt die MQTT Server LBS mit einem entsprechenden Sync-Feature auszustatten.

[saegefisch]

Da ist ja mal eine verwegene Lösungs-Idee… aber hat was…