Seite 3 von 3

Re: Feedback zur Knowledge Base

Verfasst: Mo Mär 16, 2020 9:07 pm
von brinchi
@StefanW: Wie schaut es jetzt nach der abgesagten L&B aus? Kannst Du schon abschätzen, wann Ihr Gelegenheit haben werdet, anhand der erstellten Tabelle die 1W-Sensorfunktionen so zu beschreiben, dass man die GAs richtig sauber und vollständig, d.h. inkl. aller "Kommunikationsobjekte" mit DPT, aufsetzen kann?

Oder wäre Euch zum Abschluss des Themas damit geholfen, wenn Euch noch anderweitig zugearbeitet würde, und wenn ja, wie?

Merci und viele Grüsse

Re: Feedback zur Knowledge Base

Verfasst: Mo Mär 16, 2020 10:36 pm
von StefanW
Sorry, ich bin gerade in ganz anderen Themen drin.

Also ich kenne das Ticket mit der Tabelle, aber irgendwie ist immer was anderes wichtiger gewesen. Ich verstehe nicht, woran es scheitert, die 1-Wire Objekte zu nutzen und auf KNX zu mappen. Bitte nochmal das Problem erklären, weil ich bin gerade in DMX, MODBUS, MQTT, REST-API unterwegs...

Stefan

Re: Feedback zur Knowledge Base

Verfasst: Mo Mär 16, 2020 11:34 pm
von brinchi
StefanW hat geschrieben: Mo Mär 16, 2020 10:36 pm Bitte nochmal das Problem erklären, weil ich bin gerade in DMX, MODBUS, MQTT, REST-API unterwegs...
Vereinfacht gesagt, verstehe ich nicht, was die im TWS erwähnten und unten gelb markierten 1W-"applications" bzw. -"Anwendungen" wie beispielsweise "Air Quality Heating" genau machen. Auch einige einzusetzende Grenzwerte und Umrechnungen erschliessen sich mir (aus der Maxim- und TWS-)Dokumentation nicht
Die korrekte Zuordnung der richtigen DPTn setzt jedoch dieses Verständnis voraus.

Anbei gelb markiert die zu beantwortenden und höchstwahrscheinlich für Euch trivialen Fragen aus dem oben verlinkten Beitrag:

[*]Luftqualitätssensor V3.0 (VOC-Sensor)
  • Anwendung ("Application"): Air Quality (ppm)
    • DPT: 9.008 Teile/Million [ppm]
  • Anwendung: Air Quality heating (s)
    • Unklar: Ist die verstrichene Zeit seit dem Anfang des Heizvorgangs gemeint? Wenn ja, dann DPT 8.005 Zeitdifferenz (s)
  • Anwendung: Air Quality heating (min)
    • Unklar: Ist die verstrichene Zeit seit dem Anfang des Heizvorgangs gemeint? Wenn ja, dann DPT 8.006 Zeitdifferenz (min)
  • Anwendung: Air Quality heated up
    • Unklar: Ist hier der Status gemeint? Wenn ja, dann DPT 1.011 Status
  • Anwendung: Air Quality calibrated
    • Unklar: Ist hier der Status gemeint? Wenn ja, dann DPT 1.011 Status
  • Anwendung: Versorgungsspannung VDD (V)
    • DPT: 9.020 Spannung (mV)
      • Unter den 1W-Regeln bei "Offset" mit 1000 multiplizieren bevor man den Wert an den KNX-Bus sendet.
        • Empfehlung: Wert nicht an den KNX-Bus senden, sondern in den 1W-Regeln über "Funktion -> Treshold Upper (XXX mV) und Lower (XXX mV) abgreifen und dann über "Invert: false" einen 1-Bit Störungsstatus erzeugen (DPT 1.011)
  • Anwendung: Versorgungsspannung VDD (mV)
    • DPT: 9.020 Spannung (mV)
      • Empfehlung: Wert nicht an den KNX-Bus senden, sondern in den 1W-Regeln über "Funktion -> Treshold Upper (XXXmV) und (XXX Lower mV) abgreifen und dann über "Invert: false" einen 1-Bit Störungsstatus erzeugen (DPT 1.011)



[*]Aufputz Umgebungslicht-Multi-Sensor Outdoor (AP-Licht Multi-Sensor)
  • Anwendung: relative Luftfeuchtigkeit external (%)
    • Hinweis: "External" bezieht sich auf den ausserhalb des Gehäuses angeordneten Sensor.
    • DPT: 9.007 Feuchtigkeit (%)
  • Anwendung: Absolute Luftfeuchtigkeit external (g/m3) (Vorzugsanwendung)
    • DPT: 9.029 absolute humidity (g/m3)
  • Anwendung: Absolute Luftfeuchtigkeit external (kg/m3)
    • DPT: 9.029 absolute humidity (g/m3)
      • Unter 1W-Regeln bei "Offset" mit 1000 multiplizieren bevor man den Wert an den KNX-Bus sendet.
    • Anwendung: Beleuchtungsstärke internal (lux)
      • DPT: 9.004 lux (lux)



[*]Adv. Multi-I/O 6-fach (6-fach Multi-IO mit Analog IN 0…10V und Anschluss eines analogen Umgebungslichtsensors)
  • Anwendung: Elektrische Spannung (mV)
    • Unklar: Wie bestimmt sich daraus der Lux-Wert bei einem angeschlossenen Umgebungslichtsensor (rein linear)? Für die Spannung an sich wäre die DPT 9.020, für die Lichtstärke 9.004.
    • Anwendung: ch0 input pio 1 (pio = programmable in-/output)
      • DPT: 1.011 Status



[*]Hülsentemperaturfühler 100 mm (HTF 100)
  • Anwendung: Temperatur (einstellbare Auflösung 9, 10, 11 oder 12 bit) (°C)
    • DPT: 9.001 Temperatur (°C)
  • Anwendung: Temperatur (einstellbare Auflösung 9, 10, 11 oder 12 bit) (°F)
    • DPT: 9.027 Termperatur (°F)
  • Anwendung: Temperatur (einstellbare Auflösung 9, 10, 11 oder 12 bit) (K)
    • DPT: 9.001 Temperatur (°C)
      • Der TWS gibt bei dieser Einstellung nicht die Temperaturdifferenz, sondern die Absoluttemperatur in K aus, daher ist in den 1W-Regeln folgender Offset einzustellen: -273,15

Re: Feedback zur Knowledge Base

Verfasst: Di Mär 17, 2020 8:19 am
von gbglace
@brinchi

Ich gehe einfach mal alle Angaben der Reihe nach durch.

- ja
- ja
- ja
- ja

XXX-Markierungen:
sind ein Platzhalter für einen nummerischen Wert in mV der Dir als Grenzwert genehm ist, hätte ggf auch NNN oder nnn sein können. Du kannst auch direkt die mV oder mV mal 1000 auf den Bus geben, aber diese Information ist meist von weniger Interesse, meist bietet es sich dann halt an direkt eine 1-wire Regel zu implementieren, die eine Schwellwertauswertung macht, ehe man das erst in einer KNX oder TWS-Logik macht. Das schont auch den Bustraffic weil so ein mV-Wert sich oft ändern kann.

Eine direkte Erfassung von LUX wirst nicht hinbekommen. Dazu müsstest entweder in den Regeln oder einer TWS-Logik den gemessenen V-Wert in LUX umrechnen. Ein analoger Sensor der 0-10V generiert hat einen definierten Messbereich, insofern hast für die Umrechnungen schon mal die obere und untere Wertgrenze. Danach braucht es noch eine Angabe ob der Spannungsverlauf linear zum Messwert ist oder irgendwie anders. Das sollte sich aus den Datenblättern des jeweiligen analogen Sensors ergeben. Die notwendige Funktion kann dann in einer TWS-Logik hinterlegt werden. Dann kannst mit den 0-10V in die Logik rein und mit LUX raus gehen und auf ein KNX-Objekt verknüpfen.