- √ - IO's beim AMS invertieren

[mivola]

Nächste Woche wissen wir mehr.

OK, dann warte ich erstmal ab..
Danke Stefan!

[mivola]

Und für jede Flanke separat zum Einstellen?

Ich habe auch noch einen Anwendungsfall für die (einzeln gesteuerten) Flanken: Wenn die Terrassentür geöffnet wird, soll der Raffstore hochfahren und die Fahrsperre aktiviert werden. Also am besten wäre es, wenn man für die 2 Flanken jeweils eine eigene GA eintragen könnte. Das wären dann 3 GAs: Flanke1, Flanke2 und zyklisch.

VG
Micha

[brandeins]

mir würde ein einfache invertieren auch enorm helfen.

Wenn die Terrassentür aufgemacht wird, soll das Raffstore hochfahren und die Automatiksperre eingeschaltet werden.

[brandeins]

Habe es jetzt mit dem Logikprozessor gelöst. Ziemlich steile Lernkurve, da ich von den ganzen "Innereien" eigentlich gar keine Ahnung habe. Fände eine Out-of-the-Box-Lösung aber dennoch super, wobei mir einfaches invertieren reichen würde...

[Dirk42]

Nach längerer Zeit noch ein +1 fürs Invertieren (beim Multi-IO): Ich habe länger gesucht, warum bei der CV meine Fenster "falsch herum" angezeigt werden. Im Webmin war's richtig - in der CV aus meiner Sicht falsch / unlogisch. 1 = offen finde ich viel intuitiver als anders herum.

Wie macht Ihr anderen das für Fenster / Türen? Arbeitet Ihr einfach mit 0 = offen - oder invertiert Ihr die Werte zB mit Logik und nutzt das dann?

[MarkusS]

Man könnte sich an den KNX-Standard halten, der definiert einen eigenen DPT dafür mit offen == 1 (auswendig DPT 1.018 oder 1.019).

[swiss]

Das würde dann natürlich folgerichtig bedeuten, dass man die Eingänge invertieren müsste. Denn in der Alarmtechnik ist im "Ruhezustand" ein Überwachungskreis immer geschlossen.

Also: Fenster geschlossen == Magnetkontakt betätigt (kontakt geschlossen) == Meldegruppeneingang auf 1

Demnach ist nun momentan ohne invertierung geschlossen = 1 und offen = 0

[StefanW]

Hallo Markus,

Man könnte sich an den KNX-Standard halten, der definiert einen eigenen DPT dafür mit offen == 1 (auswendig DPT 1.018 oder 1.019).

Jep, wäre der 1.019:

• DPT ID 1.019, Window/Door; values closed, open.

Allerdings kämen theoretisch auch andere Boolsche Werte in Frage, je nachdem was man an den Multi-IO anschließt:

• DPT ID 1.005, Alarm; values no alarm, alarm
• DPT ID 1.006, Binary value; values low, high
• DPT ID 1.003, Enable; values enable, disable
• DPT ID 1.018, Occupancy; values not occupied, occupied
• DPT ID 1.009, Open/Close; values open, close.
• DPT ID 1.010, Start; values stop, start.
• DPT ID 1.001, Switch; values off, on.
• DPT ID 1.008, Up/Down; values up, down.

und noch ein paar andere mehr.

Wie soll man das machen? Alle diese denkbaren DPTs vom Type Boolean in einer Auswahl anbieten bzw. eingebbar machen? Schließlich verwenden manche den Multi-IO auch als Leckagemelder, für Taster / Schalter, als Ausgang für Ansteuerung Relais. Was sind die gängigsten DPT aus Eurer Sicht?

lg

Stefan

[MarkusS]

Frag den Herrscher über die Datenpunktliste (Steven de Bruyne).

Man sieht ja schon an der (fortlaufenden) Nummer (1.019) dass der relativ neu ist.

Ich habe früher (als es den .019 noch nicht gab) mit dem 1.009 gearbeitet - der funktioniert aber genau andersrum (open == 0) - was doof ist weil ich diverse Taster (verschiedener Hersteller) habe die auf dem Fensterobjekt des RTR für offen eben die "1" erwarten. Ich wurde dann auf meine diesbezügliche Anfrage von der Konnex belehrt dass der 1.009 eigentlich für Ventile gedacht sei.

Am Ende des Tages ist das nur ein Bool und es bleibt ein Bool und abseits aller Sonderlocken ("undefined") kennt der nur zwei Zustände. Es sollte eigentlich reichen wenn man den Eingang per Software einfach invertieren kann, dann kann sich den jeder selbst hindrehen ob der bei "auf" eine "0" oder eine "1" schickt.

Ich beobachte in den letzten Jahren eine inflationäre Vermehrung der DPTs, Ende nicht absehbar. Da ich auch Zugriff auf den Standard habe weiss ich ungefähr was die da noch (mit stetig wachsender Tendenz) in der Pipeline haben (Proposals) - wenn davon nur die Hälfte in den Standard kommt wird die DPT-Liste bald als mehrbändiges Loseblattwerk verlegt.

Zum Teil werden da munter DPTs definiert die es im Prinzip schon gibt - prominentes Beispiel 20.102 DPT_HVACMode (um den Betriebsmodus zu setzen) und DPT_HVACStatus (der steht verschämt im Appendix und hat nichtmal eine ID bekommen und wurde auf Wunsch von Eberle eingeführt - um den Status des Betriebsmodus zu melden, natürlich etwas anders kodiert wenn auch prinzipiell gleich) - und um die Konfusion dann komplett zu machen gibt es auch noch einen 22.101 DPT_StatusRHCC der teilweise kongruent ist, das Ganze garniert mit feinster could / should / must / shall-Rabulistik wann denn nun was verwendet werden soll.

Der DPT_HVACMode hat jahrelang wunderbar funktioniert und es gab nix anderes, zig Geräte haben den implementiert und jetzt taucht der MDT-Heizungsaktor auf der den Betriebsmodus über DPT_HVACMode setzt und denselben Betriebsmodus über DTP_HVACStatus meldet -

DPT_HVACStatus == DPT_HVACMode + 0x20h

Und weil das da draussen kein Schwein versteht nehmen wir uns eine Logik und subtrahieren vom DPT_HVACStatus die 0x20h damit der wie DPT_HVACMode aussieht - das versteht jeder.

Aber glücklicherweise ist das schon wieder obsolet, weil der DPT_HVACStatus soll schon nicht mehr verwendet werden weil zukünftig soll man dafür den DPT_StatusRHCC nehmen - und das ist dann gleich ein 2 Byter (Meta-Typ PDB_BITSET16) der max. 16 Stati als konkatenierte Bools unterscheiden kann. Ich bin gespannt wann das erste Gerät damit auftaucht.

Dass dann nichtmal mehr die Konnex in ihrer eigenen Software (ETS) hinterherkommt mit der DPT-Deklaration, z.B. für den Busmonitor, ist das Sahnehäubchen oben drauf.

Wenn man es als Hersteller den Usern im Feld einigermassen leicht machen will läuft das darauf hinaus dass man grösstmögliche Flexibilität vorsieht, eben indem man E/As invertieren kann oder für einen E/A mehrere DPTs zur Auswahl anbietet - so wie das einige RTRs können (Betriebsmodus wahlweise per Byte- oder per Bit-Objekt).

[heckmannju]

Beim MDT Rolladenaktor bräuchte ich den IO genau anders rum. Siehe Bild.

[Hauke]

Am Ende des Tages ist das nur ein Bool und es bleibt ein Bool und abseits aller Sonderlocken ("undefined") kennt der nur zwei Zustände. Es sollte eigentlich reichen wenn man den Eingang per Software einfach invertieren kann, dann kann sich den jeder selbst hindrehen ob der bei "auf" eine "0" oder eine "1" schickt.

Genau so! Ob der geöffnete oder geschlossene Kontakt die "1" repräsentiert hängt letztendlich von der Art des angeschlossenen Sensors ab. Daher sollte das an dieser Stelle konfigurierbar sein.
Sahnehäubchen wäre, das für den Ausgang bei der Gelegenheit auch gleich zu machen (z.B. um Aktoren "stromlos offen" und "stromlos geschlossen" jeweils anpassen zu können).

[StefanW]

Hallo zusammen,

Es sollte eigentlich reichen wenn man den Eingang per Software einfach invertieren kann, dann kann sich den jeder selbst hindrehen ob der bei "auf" eine "0" oder eine "1" schickt...

Wenn man es als Hersteller den Usern im Feld einigermassen leicht machen will läuft das darauf hinaus dass man grösstmögliche Flexibilität vorsieht, eben indem man E/As invertieren kann oder für einen E/A mehrere DPTs zur Auswahl anbietet - so wie das einige RTRs können (Betriebsmodus wahlweise per Byte- oder per Bit-Objekt).

vielen Dank für die umfangreiche Erläuterung, hat mir sehr geholfen.

Ich bin persönlich nicht so firm, welche DPTs gängig sind und welche nicht.

Wenn mir jemand oder mehrere dazu Vorschläge liefern würden, dann würde mir das sehr helfen an die Entwickler weiterzugeben.

Sahnehäubchen wäre, das für den Ausgang bei der Gelegenheit auch gleich zu machen (z.B. um Aktoren "stromlos offen" und "stromlos geschlossen" jeweils anpassen zu können).

Ja, verstanden.

Ich kann jetzt keine Termine versprechen, weil die Liste ist mittlerweile ziemlich lang - da hat sich einiges angesammelt - aber natürlich wollen wir gängige oder kompatible Einstellungen liefern, schließlich soll unsere Technik einfach nutzbar sein und keinen Anlass für Frust liefern.

Daher sind wir für Vorschläge aus dem Kreis der Kunden auch sehr offen.

lg

Stefan

[mumpf]

Ich hab es zwar schon irgendwo geschrieben, aber ich wiederhole es nochmal - für mich wäre das Sahnehäubchen, wenn man folgendes einstellen könnte:

• Wenn der Eingang 1 ist
  Sende (nichts, 0, 1) - das sollte auswählbar sein
• Wenn der Eingang 0 ist
  Sende (nichts, 0, 1) - das sollte auswählbar sein

Damit kann man alles hin bekommen, was ich mir vorstellen kann.

Gruß, Waldemar