Senden und Hören auf GAs - ein KO auf verschiedene GAs hörend?

[gbglace]

Keinen 6. Aktorkanäle, nur ein sechstes Set an GA was eben diese Lichtgruppe abbildet. Und diese Set an GA wird eben zusätzlich an alle 5 Aktoren verteilt. Aber natürlich nicht die Status GAs da muss man immer mit einer Aggregationslogik oder einer der 5 Einzelmeldungen als Gruppenreferenz sich den Status künstlich zusammenbauen.

Das Deine Logik/Visu nicht alles kann kann ja nicht zu einer generellen generischen GA Struktur führen. Dann sollte man eher empfehlen besser eine andere Logik/Visu sich zu suchen als unnötige Komplikationen zu bauen.

Aktoren kann man auch irgendwie verketten, führt aber auch zu ungleichmäßige Beleuchtungsänderung und ist nicht wirklich intuitiv.

[Flubber]

Ach ja und die Formulierung mehrere KO auf eine GA ist auch verwirrend.

Ja, da gebe ich dir recht.

Naja so lange man eben generisch Funktionsbasiert seine GAs anlegt, ist es ja egal wie das System ist. Wichtig ist eben nur, dass man halt das Licht Küche über 5 Aktorkanäle verteilt, ebenso mit allen GAs im Gewerk Beleuchtung mit anlegt. Dann lässt sich da natürlich auch die Funktion Sperre für ein Licht als Funktion mit vorsehen und verbindet diese GA dann mit den betroffenen Aktorkanälen am jeweiligen Sperrobjekt.

Das verstehe ich allerdings nicht wirklich. Einem Gewerk kann ich doch nur Geräte zuordnen. Und was meinst du damit das Licht über 5 Aktorkanäle zu verteilen? Dass man einen extra Kanal hat, der parallel zum eigentlichen Kanal für das Licht den Status für die Sperre ausgibt damit man diesen mit der GA für Sperren verknüpfen kann? Das wäre aber sehr verschwenderisch.
Meine Überlegung war gerade das jeweils zusätzliche invertierte KO eines Aktorkanals zu aktivieren und dieses als Freigabeobjekt und nicht als Sperrobjekt zu nutzen. Meine Aktoren könnte ich somit sperren bzw. freigeben, aber leider können meine Spacelogics das nicht. Die verstehen nur Sperrobjekte. Die könnte ich allerdings mit der integrierten Logik wieder invertieren. Dann wird es aber auch irgendwann unübersichtlich...

[gbglace]

Naja so lange man eben generisch Funktionsbasiert seine GAs anlegt, ist es ja egal wie das System ist. Wichtig ist eben nur, dass man halt das Licht Küche über 5 Aktorkanäle verteilt, ebenso mit allen GAs im Gewerk Beleuchtung mit anlegt. Dann lässt sich da natürlich auch die Funktion Sperre für ein Licht als Funktion mit vorsehen und verbindet diese GA dann mit den betroffenen Aktorkanälen am jeweiligen Sperrobjekt.

Ach ja und die Formulierung mehrere KO auf eine GA ist auch verwirrend. GA sind reine Verbindungen von verschiedenen KO, das ist nix wo man was rauf oder rein legen kann und im Bus auch nix rauf oder rein schreiben kann. Und eine GA welche an nur einen KO verbunden ist, ist im Sinne KNX eine sinnlose GA. Für eine gescheite Funktion sind GA also immer mit mehreren KO verbunden.

Mehrere GA an ein KO verbunden geht, aber in dem Gedanken das ein KO mehrere GA senden kann funktioniert natürlich nicht, denn ein Event = 1 Telegramm = 1 GA als Inhalt des Telegramm.

[Flubber]

Naja das ist dann aber eher ein Beitrag in den Threads wo GA-Strukturen ausdiskutiert werden.

Hier ist das eher OT

Es ging mir hier hauptsächlich um den Umgang mit den GAs zum Sperren und meiner Fragestellung dazu. Und das hängt unweigerlich mit dem Thema mehrere KOs auf verschiedene GAs. Die Struktur hatte ich nur zur Verdeutlichung der Problemstellung erläutert.

[gbglace]

Naja das Projekt darf dann halt nicht so groß werden das es mehr als 55 Lampen je Objektbereich (8MG) gibt.

[DerStandart]

Meinungen/Vorschläge?

0/2/0 Küche Licht 1 an/aus
0/2/100 Küche Licht 1 Status
0/2/200 Küche Licht 1 Sperren

Und was mache ich dann bei 0/2/56?

Meine Meinung: Das Konzept der Hauptgruppen und Mittelgruppen finde ich perfekt (von den Großbuchstaben mal abgesehen). Den Rest mit den Offsets finde ich eine Katastrophe da aus meiner Sicht nicht erforderlich.

[gbglace]

Naja das ist dann aber eher ein Beitrag in den Threads wo GA-Strukturen ausdiskutiert werden.

Hier ist das eher OT.

[Flubber]

Hallo zusammen,

ich würde gerne diese Thema nochmal aufgreifen und um den Anwendungsfall "Sperrobjekte" erweitern.

Hat da etwa wer ein GA-System streng nach Aktor gebaut und kommt jetzt mit einigen Gruppenaktionen nicht mehr klar?

Ich denke zwischen der hier zitierten Struktur der GAs und einer rein funktionsorientierten gibt es auch noch gute Mittelwege. Ich versuche die GAs so zu strukturieren, dass ich anhand der Nummer schon entsprechende Zuordnungen zur Funktion, Gewerk und dem Gebäudeteil machen kann. Für mich macht es das zumindest in einem großen Projekt übersichtlicher. Das sieht für ein dimmbares Licht z.B. so aus.

0/2/0 Küche Licht 1 an/aus
0/2/100 Küche Licht 1 Status
0/2/200 Küche Licht 1 Sperren
1/2/0 Küche Licht 1 rel. Dimmen
2/2/0 Küche Licht 1 Dimmen Wert
2/2/100 Küche Licht 1 Wert Rückmeldung
3/2/0 Küche Licht 1 RGBW Wert
3/2/100 Küche Licht 1 RGBW Rückmeldung

Wobei die Hauptgruppe die Funktion und die Mittelgruppe den Gebäudeteil entspricht.
image.png


Dabei habe ich aber auch für Sperrobjekte eigene Gruppenadressen erstellt. Wenn ich jetzt einen Aktorkanal A sperren möchte, wenn ein andere Kanal B eingeschaltet wird, dann kann ich den Status von Kanal B nicht in die GA des Sperrobjekts Kanal A (z.B. 0/1/200) senden. Nun könnte ich zwar das Sperrobjekt von Kanal A mit der GA zur Rückmeldung Kanal B verknüpfen, in einem großen Projekt verliert man da aber mMn schnell den Überblick.

Habt ihr dazu Meinungen/Vorschläge? Ich bin sehr gespannt...

Grüße,
Marc

[bavarianhias]

Ich denke du hattest irgendwo anders den Wurm drin, denn wenn es mit den Komfort - Sollwerten klappt, dann klappt es auch so wie in #14

image.png

Zudem kann ich folgendes nicht vertreten:

Bei einer FBH macht das Wechseln der Betriebsart bekanntlich keinen Sinn.

Ich mache es nämlich genau so wie #37 und schalte auch bei der FBH bei Abwesenheit in den Standby.
Und auch bei Räumen über Nacht macht das durchaus Sinn. Bei mir schalten die Kinderzimmer über nacht am späten Nachmittag in den Standby (fester Sollwert = 19°C - damit schließen die Ventile) denn in der Nacht brauch ich da keine Wärmeenergie, die mir wo anders dann zur Verfügung steht. Am frühen Morgen fahren die Ventile dann wieder auf. Und das macht meine FBH schön mit.
Selbstverständlich muss man aufpassen, dann keinen hydr. Kurzschluss zu erzeugen. Aber es sind bei mir immer noch genug Ventile offen.

[Fidelis]

Da kann ich ja auch zentral die WP auf einen anderen Modus umstellen und den dann per KNX übernehmen

Was genau erwartest du von den Geräten, wenn du "auf einen anderen Modus umstellst"? Also wie sollen diese reagieren?

• Die WP wird vermutlich ihre Soll-Vorlauftemperatur anpassen. Wobei ich nicht weiß, ob unterschiedliche WP dies unterschiedlich in der Praxis umsetzen - Heizkurve verschieben, feste VL-Temp wählen, irgendwas anderes?
• Was soll der Aktor in dem Fall machen? Wenn du diesem eine neue Soll-Raumtemperatur vorgibst, weißt du ob die WP das Wasser dazu passend erwärmt? Oder soll der Aktor einfach alle Ventile komplett öffnen, sodass sich eine "zufällige", aber niedrigere Raumtemperatur durch die abgesenkte VL-Temperatur ergibt? Das würde zumindest der WP entgegenkommen...

[gbglace]

Und versuche nicht immer den Zitat-Knopf als Antwort zu missbrauchen. Einfach ein bissel weiter runter scrollen und die Antwort tippen.

[knxPaul]

Der AKH beherscht keinerlei uhrzeitgesteuerte Automatik. Eine externe Logik, beispielsweise mit ZSU, PM oder von Tastern gesteuert, muss das gewünschte automatische Umschalten zwischen den genannten Betriebsarten realisieren. KNX ist ein dezentrales System, bei dem Funktionsblöcke in verschiedene Geräte verteilt arbeiten.
Bei einer FBH macht das Wechseln der Betriebsart bekanntlich keinen Sinn.

[jayw82]

genau nur wenn man die anderen Betriebsarten nicht verwendet. Wenn ich aber mal ein paar Tage Außer Haus bin ist genau das was ich da nur noch dran rumstelle. Ein Knopf und schon switchen alle Kanäle von Komfort auf einen anderen Modus.

Da kann ich ja auch zentral die WP auf einen anderen Modus umstellen und den dann per KNX übernehmen.... Da gibts allerdings auch noch Ungereimtheiten, MDT versteht den Mode 0 (Automatik) nämlich nicht. Bei 0 schaltet der auf Standby.

Auszug von Stiebel:
image.png
Spezifikation von knx.org:
image.png
MDT behauptet:
image.png
Die 0 taucht in der Doku bei MDT entsprechen auch nicht auf:
image.png
Automatik bedeutet bei Stiebel, dass die Anlage Warmwasser, Lüftung und Heizung uhrzeitgesteuert umschaltet.
Vielleicht hat hier ja auch einer ne Idee... per Logik 0 in 1 umwandeln oder sowas?

[gbglace]

genau nur wenn man die anderen Betriebsarten nicht verwendet. Wenn ich aber mal ein paar Tage Außer Haus bin ist genau das was ich da nur noch dran rumstelle. Ein Knopf und schon switchen alle Kanäle von Komfort auf einen anderen Modus.

[jayw82]

OK die verbinden das Taster intern, weil der Regler dafür kein Ausgangs-KO hat.
Und die Sollwertverschiebung dann offensichtlich nur für den Komfort-Wert gilt und nicht für einen ggf. gerade anstehenden Standby-Modus.
Bedeutet Du bist im Standby-Modus mit aktueller SOLL-Temperatur 19° und siehst aber am Taster 22° und bedienst dann was neues für die 22°.
Dann änderst das am Taster auf 25°, damit ändert der Regler intern den Soll-Wert für den Modus Standby von 19 auf 22 und es ist Dir nen halben Tag später langsam warm genug. Irgendwas tickt dann aber nochmal um und der Modus wechselt dann wieder regulär auf Komfort und damit springt dann auch im Regler das SOLL auf 25 und noch nen halben Tag später sitzt da und schwitzt und denkst die Heizung spinnt.

Wäre mir zu viel Potential an Inkonsistenzen. Daher gibt es hier auch gar keine Verstellung der SOLL-Temperaturen an den Tastern.
ich habe einmal je Raum in die ETS getippt und seit dem läuft das.

Bei mir läufts jetzt auch endlich wie gewünscht, der "Aktuelle Sollwert" des AKH folgt anscheinend auch immer schön der Vorgabe des "Sollwert Komfort"
image.png
image.png
So wie ich es verstanden habe, geht das auch nur, wenn man die anderen Betriebsarten nicht verwendet (Standby, Nacht etc)