Wetterstation - Daten auf den KNX Bus bringen

[udo1toni]

Beim Item?
Man könnte z.B. ein String Item verwenden, um in Empfangsrichtung ein JSON Objekt mit dem Status eines Geräts zu empfangen und das Item gleichzeitig dazu verwenden, Befehle an das Gerät zu senden.
Der Punkt ist, dass Status und Befehl zwei unterschiedliche Aspekte des Items sind, die nicht zwingend immer gleich sind.

Ich kann an ein Dimmer Item den Befehl ON senden, woraufhin der Dimmer einschaltet. Meine Dimmer sind so konfiguriert, dass sie bei ON auf 80 % Helligkeit dimmen. Die Rückmeldung als Status ist dann also 80.
Sende ich an ein Color Item INCREASE, so wird die Gesamthelligkeit erhöht. Als Konsequenz bekomme ich aber einen HSBType zurückgeliefert, in dem neben der Helligkeit auch Farbe und Sättigung enthalten sind.

[nw378]

Falls nicht schon gelöst, so schicke ich die Außentemperatur (vom Sensor der Heizung) auf den KNX-Bus:

knx.things:

Code: Alles auswählen

Bridge knx:ip:bridge  [  
    type="TUNNEL", 
    ipAddress="192.168.178.111", 
    portNumber=3671, 
    localIp="192.168.178.60",
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
]{
    Thing device virtuell "KNX virtuelles Gerät" {
        Type datetime-control : Zeit "Zeit" [ ga="10.001:0/1/0" ]
        Type number-control   : aussentemp  [ ga="9.001:0/2/0"  ]
        
        }

items:

Code: Alles auswählen

Number:Temperature    Aussentemp   "Außentemp [%.1f °C]"          <selftemp>        {channel="exec:command:Heizungsdaten:output"[profile="transform:JSONPATH",function="$..[?(@.command=='getTempA')].value"], channel="knx:device:bridge:virtuell:aussentemp"}

[TorstenE]

Schon gelöst ja, aber trotzdem ist es immer Klasse, wenn das Items-File immer gleich mitgeliefert wird.
Ich weiß es gehört nicht ganz hier dazu, aber wenn ich
Items und Things über ein File definiere, wie werden dann die System State Channel Types genutzt?

Ich glaube ich muss hier nicht erwähnen, dass ich froh bin, OH gefunden zu haben.
Das Teil ist einfach klasse und kann so viel und ein großer Anteil daran trägt Udo.

D A N K E

Torsten

[udo1toni]

Das ist Teil der Developer Dokumentation, da geht es darum, was man nutzen soll, wenn man ein Binding entwickelt.
Z.B. beim knx Binding (was lange vor diesem Teil der Dokumentation entstanden ist) ist kein einziger dieser Channeltypen vorhanden (allerdings einige, die in ähnlicher Form vorhanden sind, z.B. brightness), stattdesssen gibt es switch, dimmer, rollershutter, contact, number, string und datetime (jeweils noch als -control Variante - mit 4.0 gibt es noch offiziell den color Channel, eigentlich dachte ich der wäre schon längst drin...).
Das knx Binding orientiert also stark am Item Modell. Ich gehe davon aus, dass knx eines der ersten Protokolle überhaupt war, welches in openHAB implementiert wurde. Es kann also auch gut sein, dass die Items ursprünglich vom knx (v1) Binding vorgegeben wurden.

[TorstenE]

Das ist Teil der Developer Dokumentation, da geht es darum, was man nutzen soll, wenn man ein Binding entwickelt.
Z.B. beim knx Binding (was lange vor diesem Teil der Dokumentation entstanden ist) ist kein einziger dieser Channeltypen vorhanden (allerdings einige, die in ähnlicher Form vorhanden sind, z.B. brightness), stattdesssen gibt es switch, dimmer, rollershutter, contact, number, string und datetime (jeweils noch als -control Variante - mit 4.0 gibt es noch offiziell den color Channel, eigentlich dachte ich der wäre schon längst drin...).
Das knx Binding orientiert also stark am Item Modell. Ich gehe davon aus, dass knx eines der ersten Protokolle überhaupt war, welches in openHAB implementiert wurde. Es kann also auch gut sein, dass die Items ursprünglich vom knx (v1) Binding vorgegeben wurden.

Langsam wird es immer spannender je weiter es in die "Tiefen" von OH geht.