Einbindungsvarianten Visu/Logik in ETS (ETS vs. Dummy)

[Mikelop]

Ich dann gehe ich noch etwas ins Detail:

Licht kann auch noch getriggert werden von z.B. folgenden Stellen + weitere unbegrenzte Möglichkeiten:

- Präsenzmelder
- Logik (Abwesenheitssimulation)
- Logik (Signalisierung bei lauter Musik, Türgong)
- Helligkeitsgesteuert
- Urlaubsmodus
- usw.

Wir haben öfter den Fall das z.B. Nachts in der Garage das Licht an geht, obwohl kein "Mensch" in der Garage ist.
Wahrscheinlich wirds der Präsenzmelder sein, der irgend einen Luftstrom erkennt und somit durch Wärme schaltet.

Oder das Licht bleibt öfter eingeschaltet im Kinderzimmer.
Beschattung ist unten -> Raum dunkel -> Jemand geht rein -> Präsenzmelder schaltet Licht -> während der Nachlaufzeit geht Rollo hoch -> Präsenzmelder schaltet Licht nicht mehr aus -> Licht muss man von Hand ausschalten. Hier muss ich auch noch was umstellen/Fehler finden.

Bei so "Situationen" würde ich gerne am Montior das nachstellen und anschauen. Wäre jetzt die Visu "unsichtbar" dabei beteilgt, bzw. deren Logik (bei Edomi z.B.), dann wäre das für mich verwirrend.

[gbglace]

Die Tunneladresse, die man über ETS am Interface einstellt, ist dann die Quelladresse.

Bis auf Enertex kannst bei keinem Interface genau definieren welche IP-Adresse (Visu-Rechner) welchen Tunnel und damit welche PA auf der TP-Linie bekommt. Solange nur ein solches "Gerät" werkelt ist es aber natürlich egal. Hat er aber diverse solcher IoT-Mediatoren parallel am Start dann ist das nicht mehr eindeutig.

Danke. Sache ist mir nun klarer.

Das bezweifle ich noch, denn viertel Sunde später schreibst sowas.

Bei so "Situationen" würde ich gerne am Montior das nachstellen und anschauen. Wäre jetzt die Visu "unsichtbar" dabei beteiligt, bzw. deren Logik (bei Edomi z.B.), dann wäre das für mich verwirrend.

Verwirrend wird es wenn jeder Befehlsgeber im Projekt eine eigene GA bekommt und mehre aber einfach nur die gleiche Funktion antriggern. Warum sollen 3 Lichtschalter die alle ausschließlich eine die selbe Lampe AN/AUS triggern eine eigene GA bekommen?

Eine GA repräsentiert eine Funktion einen Befehl, wer die GA sendet ist den Geräten am Bus egal. An einem Busmonitor kannst Du aber bei den Telegrammen immer sehen welche PA dieses Telegramm gesendet hat und wenn ein solcher Busmonitor auch die ETS-Projektdaten kennt, dann schreibt der nicht nur Zahlen in die Tabelle sondern auch Namen.

Kannst Du mit RPI usw. umgehen, und dir eigene Busmonitore bauen bzw. zumindest den Telegrammverkehr in Datenbanken auswertbar weg schreiben?
Weil wenn man merkt es stimmt was nicht will man ja auch nicht erst die ETS auf dem PC starten und warten bis wieder was passiert.

Du solltest daher auch nach einem Logikserver suchen der solche Aufgaben für Dich mit übernimmt und das leicht zu bedienen vorhält.

Logikserver die nur mit KNX-KO und GA-Verknüpfungen in der ETS arbeiten aber sonst mit nem modernen Webfrontend zu bedienen sind gibt es ja.

[meti]

> Bis auf Enertex kannst bei keinem Interface genau definieren welche IP-Adresse (Visu-Rechner) welchen Tunnel und damit welche PA auf der TP-Linie bekommt.

Es sei denn du nutzt IP-Secure. Dann machst du das implizit über die Userid/Passwort Kombi, nicht über die IP Adresse.

Theoretisch könnte die Visu bei non-Secure auch eine spezifische Tunneladresse beantragen nach dem Connect - so wie ETS das macht. Ob das irgendwer auch implementiert hat weiß ich aber ned.

[Mikelop]

Das bezweifle ich noch, denn viertel Sunde später schreibst sowas.

Stimmt so nicht. Hab ja geschrieben, falls die Visu unsichtbar wäre im Busmonitor, dann wäre es für mich verwirrend. Aber es wurde mir ja mitgeteilt das man im Monitor erkennen kann, wenn die Visu was sendet. Daher verständlich.

Warum sollen 3 Lichtschalter die alle ausschließlich eine die selbe Lampe AN/AUS triggern eine eigene GA bekommen?
.

OK dann habe ich die ETS-Kurse irgendwie falsch verstanden. Ihr hängt also z.B. die gleiche Gruppenadresse, an mehrere Taster-KOs und Präsenzmelder und Logikausgang. Und die gleiche GA an den Aktorausgang? Dachte ich muss mehrere GAs anlegen und diese am Aktor mehrfach verknüpfen mit Komma dazwischen. Wieder was gelernt. Dachte ich hätte das schon Mal so gemacht und da ging es nicht. Trotz sauberer Aktorrückmeldung an alle Taster, Präsenz, Logik zurück.

Und zwecks ETS muss erst eingeschaltet werden. Man könnte die ETS auch im Hintergrund mit Monitor länger laufen lassen bzw. es gibt doch Zusatzprogramme die sowas in eine Datenbank sichern oder Geräte mit Puffer. Also so Umständlich finde ich es nicht den Monitor als Diagnose-Mittel zu verwenden.

[vento66]

EDOMi loggt bei Bedarf eh die Buskomunikation mit, das hat er nur noch nicht rausgefunden. Damit ist das geglaubte Alleinstellungsmerkmal voin seinem Timberwolf auch wieder weg. (jetzt kommt dann gleich, das er das aber in Grafana schon aufbereitet bekommt )

[DerStandart]

OK dann habe ich die ETS-Kurse irgendwie falsch verstanden.

Definitiv, ja!

Ihr hängt also z.B. die gleiche Gruppenadresse, an mehrere Taster-KOs und Präsenzmelder und Logikausgang. Und die gleiche GA an den Aktorausgang?

Ja

[Mikelop]

Logikserver die nur mit KNX-KO und GA-Verknüpfungen in der ETS arbeiten aber sonst mit nem modernen Webfrontend zu bedienen sind gibt es ja.

Die da waren?

Das war ja eigentlich meine Anfangsfrage hier im "Anfängerforum".

Auf die weiteren Kommentare werd ich jetzt besser nicht mehr weiter eingehen. Ich werd's mir in Zukunft wieder verkneifen Fragen zu stellen. Besser nur lesen im Forum oder selber testen. Danke für die sonstige konstruktive Hilfe.

[vento66]

Was aber gerne verschwiegen wird, das alle weitere Konfiguration nicht über die ETS geht, und auch dort die GA importiert und exportiert werden müssen, weil die eigentliche Visu dann in einem Docker container läuft.

[Beleuchtfix]

Für die GAs, denke in Funktionen. Also Licht Decke an/aus und nicht vom Sensor (Tasten oben links). Damit benötigst du für eine Funktion nur eine GA, egal von wie vielen Stellen es bedient wird. Aber Licht Raum an/aus ist dann eine andere Funktion, auch wenn die Decke wieder mit geschaltet wird.

Gruß Florian

[gbglace]

Was aber gerne verschwiegen wird, das alle weitere Konfiguration nicht über die ETS geht

Was ja grundsätzlich nicht verkehrt ist solange man nicht wie früher bei den Plug-Ins mit streng ans OS und wenig Updatefähigkeit an eine spezielle Software gebunden ist.

Der Kritikpunkt der Visufähigkeit von dem Server ist gekauft.

Aber nachdem er ja nun hoffentlich gelernt hat wie der Bus funktioniert und wie man es mit ETS-KO's und ohne ETS-KO's realisieren kann kann er ja einfach einen der vielen Threads zum Thema was ist der beste Logikserver, was ist die beste Visu lesen und sich dann was kaufen / installieren.

Ich werd's mir in Zukunft wieder verkneifen Fragen zu stellen. Besser nur lesen im Forum oder selber testen.

Man darf schon fragen, nur nicht in Hektik und Eile, weil man darf gut und gerne davon ausgehen, bei einem System, welches über 30 Jahre nach den gleichem Funktionsprinzip stabil läuft schon viele andere vor dem gleichen Missverständnis standen und dies dann in 15 Jahren dieses größten KNX-Forums auch mal einer davon schon gefragt hat und kompetente Antwort bekommen hat.
Wer selbst aber zu kleinkariert nur sein Problemchen als hochgradig individuell betrachtet stellt dann die Fragen die immer mal wieder kommen. Die Häfte des Problembeitrages mal auf die eigentliche Frage reduziert und in die Suche oder bei google eingetippt bringt da bestimmt auch immer ne Lösung.

Und gerade das meiste solcher Fragen und Probleme sind einfach Missverständnisse zu den Grundlagen der Funktion des KNX. Die eigentlich absolut simpel sind. Man muss sie nur mal lesen und verstehen und nicht nur klicki bunti auf die ETS-Knöpfe schauen.