Hallo Alexander, On 25.02.2018 16:26, [email protected]<mailto:[email protected]> wrote: Hallo
was für einen input type verwendet man am sinnvollsten für einen Rauchmelder (NEST protect) dessen API für Rauch und CO jeweils getrennt die Werte „ok“, „warn“ „alert“ liefert? Wenn ich Binary inputs (mit extended value, da die API 3 statis liefern kann) verwende, kann ich als sensor function nur 7 = Smoke detector verwenden, dann zeigt aber die DSS GUI auch für den CO Wert „Kein Rauch“ an. Für CO gibt es keine passende Sensor function. Der angezeigte Text scheint harcoded vorbelegt zu sein für jede sensor function? Wenn ich sensor input verwende könnte ich sensorType = 5 verwenden, macht aber auch keinen Sinn da ich den „CO concentration in ppm Wert“ von der NEST API nicht erhalte, sondern nur „ok“, „warn“ oder „alert“ (mappe ich aktuell auf 0, 1, -1 als binary iput extended value) da hast du vollkommen Recht, einen CO Melder kann man derzeit noch nicht als Device im digitalSTROM System abbilden. Es gibt weder die Sensorfunktion für den "Binary Input", noch gibt es die dazugehörige Apartmentszene als Alarm. Einzige Möglichkeit ist zur Zeit die Sensorfunktion "0 - App Modus" zu wählen, und dann via Event Responder eine Aktion ausführen zu lassen. Auf der Liste der einzuführenden Sensorfunktionen stehen: Wassermelder, Gasmelder und CO-Melder. Und dazu gehören dann die Apartment Szenen, die als korrespondierende Systemaktion ausgelöst werden: Wasseralarm, Gasalarm (brennbare bzw. explosive Gase), Erstickungsgefahr (durch Rauchgase, CO). Auch für z.B. einen Binary Input Wert 0 / 1 dessen Bedeutung „gerät ausgeschaltet / gerät eingeschaltet“ ist find ich nichts passendes. Wenn ich hier sensor function 0 verwende dann seh ich in den DS Apps „Kontakt geschlossen /Kontakt offen“, vermutlich auch ein default hardcoded Wert. Kann man den Text customizen? Binary inputs haben nur boolean oder integer, sensor inputs nur double als value type. Vermisse so etwas wie einen „string value“, in dem ich selber an DSS schicken kann was der aktuelle Wert bedeutet (eingeschaltet / ausgeschaltet / online / offline / …) und dieser in den Apps angezeigt wird und ich darauf aufbauend scene responder / benutzerdefinierte Zustände setzen kann. Du kannst allgemeiner auch "Device States" mit dem Property "deviceStatesDescriptions" abbilden, und eine Zustandsänderung als "deviceStates" Property versenden. Das kann dann auch als Trigger in den Addons im DSS verwendet werden. Ein Problem hier sind die Übersetzungen, solche Device States benötigen zur Zeit eine eigene GTIN für das Device und ein PO File auf dem DSS. Das ist das gleiche Problem wie bei deiner Frage nach den Custom Actions für Single Devices... Irgendwie ist das Modell mit den sensorTypes / sensorFunctions sehr low level, recht unflexibel und für immer mehr kommende single devices nur so mittelmässig gebrauchbar . Oder gibt’s da noch irgendwas was ich übersehe? Die "Binary Inputs" sind natürlich entstanden durch existierende Sensoren und Signalgeber mit einem Relais als Schaltausgang. Sicherlich gibt es die Anforderung noch mehr Zustände zu ermöglichen, wie bspw. ja auch schon bei dem Fenstergriff verwendet (geschlossen, geöffnet, gekippt). Da ist sicher noch Nachbesserungsbedarf in einer v4 der VDCAPI, mit einer Vereinheitlichung der Binary Inputs und State Inputs. Grüße Michael [1] http://developer.digitalstrom.org/Architecture/vDC-API-properties.pdf#1c
_______________________________________________ dss-developer mailing list [email protected] http://forum.digitalstrom.org/cgi-bin/mailman/listinfo/dss-developer
