Anfängerfrage KNX2 Binding und Integration anderer Bindigs (Netatmo)

[haegar80]

Hallo zusammen,

ich bin blutiger Anfänger und mache gerade meine ersten Schritte mit Openhab 2.3 und diversen Bindings.

Ich möchte Openhab nutzen um, unterschiedliche Schnittstellen und Protokolle zu integrieren.
z. B. KNX und meine Netatmo Wetterstation

Die jeweiligen Bindings habe ich zum laufen gebracht:
- Netatmo Wetterstation liefert Daten
- Ich kann in Openhab Licht meiner KNX Installation Aus/Einschalten

Nun versuche in mich erfolglos an der Integration KNX und der Wetterstation.
Konkret will ich die Netatmo Termperatur auf den KNX Bus schicken.

Das sollte doch eigentlich direkt in der Items Konfiguration möglich sein?

KNX Thing
Thing device KNX [address="1.1.1", fetch=true, pingInterval=300, readInterval=3600]
{
Type number : TemperaturAussen "Außentemperatur" [ ga="9.001:5/5/10" ]
}


Temperatur Item
Number Netatmo_Outdoor_Temperature "Temperatur [%.2f °C]" <temperature> (Netatmo_Outdoor) { channel = "netatmo:NAModule1:02b894f3:0200002ad7fe:Tempe ratu re", channel="knx:device:bridge:KNX:TemperaturAussen" }

Kann mir jemand auf die Sprünge helfen?

Danke + Gruß
Sascha

[udo1toni]

Also Du hast ein knx Device mit der physikalischen Adresse 1.1.1, in dem eine GA 5/5/10 mit dem DPT 9.001 konfiguriert ist?

Das Thing gehört zwingend zu der knx Bridge. Wenn Du hier Code postest, empfehle ich Dir, den Code auch als Code zu kennzeichnen, damit die Forensoftware nicht automatisch irgendwelche Leerzeichen einfügt oder anderes...

[haegar80]

Ja ich habe ein Device mit der physikalischen Adresse 1.1.1 mit einer GA 5/5/10 und DPT 9.001 konfiguriert.

Natürlich gibt es eine Bridge, da grundsätzlich KNX über Openhab funktioniert, habe ich nur einen Ausschnitt geposted.

Hier komplett die KNX Config:

Bridge knx:ip:bridge [
  ipAddress="192.168.10.10",
  portNumber=3671,
  localIp="192.168.10.12",
  type="TUNNEL",
  readingPause=50,
  responseTimeout=10,
  readRetriesLimit=3,
  autoReconnectPeriod=1,
  localSourceAddr="1.1.1"]
  {
     Thing device KNX [address="1.1.1", fetch=true, pingInterval=300, readInterval=3600]
    {
      Type number : TemperaturAussen "Außentemperatur" [ ga="9.001:5/5/10" ]
    }
  }

[udo1toni]

Gut, nur um sicher zu gehen, dass dass es sich nicht um einen simplen Konfigurationsfehler handelt

Versuch doch mal spaßeshalber, ob sich etwas ändert, wenn Du number-control verwendest:

Type number-control : TemperaturAussen "Außentemperatur" [ ga="9.001:5/5/10" ]

[haegar80]

Versuch doch mal spaßeshalber, ob sich etwas ändert, wenn Du number-control verwendest:]

Das bringt leider nichts! Liegt das Problem in den Items das die Werte der Watterstation nicht auf den KNX Bus weitergegeben werden:

Number Netatmo_Outdoor_Temperature "Temperatur [%.2f °C]" <temperature> (Netatmo_Outdoor) [B]{ channel = "netatmo:NAModule1:02b894f3:0200002ad7fe:Temperature", channel="knx:device:bridge:KNX:TemperaturAussen" }[/B]

Danke
Sascha

[udo1toni]

Unterstützt Netatmo schon UoM? dann wird das vielleicht der Grund sein, warum das nicht funktioniert. dann müsstest Du eine Rule schreiben, die den Zahlenwert aus dem Netatmo Item extrahiert und in ein eigenes knx Item schreibt.

[haegar80]

Unterstützt Netatmo schon UoM? dann wird das vielleicht der Grund sein, warum das nicht funktioniert. dann müsstest Du eine Rule schreiben, die den Zahlenwert aus dem Netatmo Item extrahiert und in ein eigenes knx Item schreibt.

Was bedeuted die Unsterstützung von UoM (unit of Measure)?
Wie kann so eine Rule aussehen?

Danke
Sascha

[udo1toni]

openHAB bekommt grundsätzlich erst mal nur Zahlen von verlinkten Addons. Jetzt ist es aber aus Anwendersicht lästig, wenn man a) überall Einheiten drankleben muss und b) auch noch selbst Umrechnungen einbauen muss, wenn ein Wert von einem Sensor nicht so angeliefert wird, wie man es bräuchte. Hier kommt UoM ins Spiel.
Das Weather Underground Binding ist zum Beispiel schon komplett auf UoM ausgelegt. In der Folge wird eine Temperatur automatisch mit °C angezeigt, falls in openHAB das metrische System ausgewählt ist. Ist das imperiale System ausgewählt, wird aber °F angezeigt - wohlgemerkt, der korrekt umgerechnete Wert(!) obwohl weather Underground weiterhin °C liefert.
Möchte man die Windgeschwindigkeit lieber in Knoten statt m/s haben, gibt man im Label nur die passende Unit an, schon purzelt die korrekt umgerechnete Zahl heraus.
Das hat aber einen Haken, plötzlich sind Status nicht mehr einfach Zahlen, sondern sie beinhalten auch die Einheit (das kann man z.B. in VSCode direkt in der Itemliste sehen, wo ja immer der aktuelle Status mit ausgegeben wird). Wenn man nun einen einheitenbehafteten Status hat und diesen an ein anderes Addon weitergibt, das mit UoM (noch) nichts am Hut hat, gibt es Kuddelmuddel.
Bisher habe ich damit zum Glück keine Probleme im englischen Forum gab es, glaube ich, schon Beispielrules, um dieses Problem zu umschiffen.

[Milhouse]

Ob das direkt in der Item-Konfiguration geht, weiss ich nicht. Aber genau den Anwendungsfall "Netatmo Werte auf den KNX Bus senden" habe ich mit openhab1 erfolgreich in Betrieb gehabt mittels einer einfachen Rule:

/* Forward Netatmo temperatures to KNX */
rule "forward Netatmo to KNX"
 when
  Item Netatmo_Eltern_Temp received update
 then
  logInfo("Rule_forward_Netatmo", "execute")
  
  temp = (Netatmo_Eltern_Temp.state as DecimalType).doubleValue
  sendCommand(KNX_temp_Eltern, temp)
  
  temp = (Netatmo_Balkon_Temp.state as DecimalType).doubleValue
  sendCommand(KNX_temp_Balkon, temp)

end

Ich nehme an das wird auf openhab2 auch gehen, dort bin ich allerdings gerade noch in der Einarbeitung und habe noch nichts mit Rules gemacht.

[MUCKNXer]

Das bringt leider nichts!

udo1toni scheint da wie so oft auf dem richtigen Weg zu sein. Ich hatte das gleiche Problem wie haegar80, und durch Empirie wie folgt gelöst.

1) number-control, nicht number (man kann ja Netatmo nicht vom KNX-Bus aus beeinflussen).

knx.things:

Thing device NetatmoKNX "Netatmo KNX GW" {
    Type number-control : cT_Balkon [ ga="9.001:6/1/64" ]
}

2) **KEINE** UoM benutzen (also nicht "Number:Temperature T_Balkon usw.). Die Erkenntnis hat mich Stunden gekostet.

netatmo.items:

Number T_Balkon "Außentemperatur Balkon (Netatmo) [%.1f °C]" <temperature> [ "CurrentTemperature" ] {
    channel="netatmo:NAModule1:home:NAbalkon:Temperature",
    channel="knx:device:bridge:NetatmoKNX:cT_Balkon"
}

Und dann läuft es. Sichtbar im Logfile

2018-08-05 20:01:07.410 [vent.ItemStateChangedEvent] - T_Balkon changed from 29.6000003814697265625 to 29.5

(off-topic: wie kriegt man eigentlich dort die Nachkommastellen unter Kontrolle?)

und die Außentemperatur steht auf den KNX-Anzeigen / Visus - habe gerade keinen Zugriff auf den ETS Monitor.

Ach ja, danach openHAB einmal durchbooten schadet nicht.

[haegar80]

udo1toni scheint da wie so oft auf dem richtigen Weg zu sein. Ich hatte das gleiche Problem wie haegar80, und durch Empirie wie folgt gelöst.

1) number-control, nicht number (man kann ja Netatmo nicht vom KNX-Bus aus beeinflussen).

knx.things:

Thing device NetatmoKNX "Netatmo KNX GW" {
Type number-control : cT_Balkon [ ga="9.001:6/1/64" ]
}

Sauber!!! Danke

Es läuft seit dem ich die Parameter für das KNX Device weggenommen habe:

Thing device KNX [S][address="1.1.1", fetch=true, pingInterval=300, readInterval=3600] [/S]

Interessant, Aber Hauptsache es läuft!!!

Danke nochmal
Viele Grüße
Sascha

[haegar80]

Hallo,

ich muss das Thema nochmal ausgraben. Weiterleitung der Daten von der Wetterstation auf die GA vom KNX läuft soweit. Aber jetzt schreib openhab ca. 100x je Sekunde den Wert, was zu extremer Buslast führt.

So sieht mein KNX thing aus:

Bridge knx:ip:bridge [
ipAddress="192.168.1.2",
portNumber=3671,
localIp="192.168.1.3",
type="TUNNEL",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="0.0.0"
] {
Thing device Wetter "KNX Wetterwerte" {
Type number-control : KNX_TemperaturAussen "Außentemperatur" [ ga="9.001:5/5/10" ]
}
}

Danke
Sascha

[Milhouse]

Bis die Ursache dafür geklärt ist, kannst du auch einfach meine Rule nutzen. Dann hast du es viel besser selber im Griff, wann der Wert geschickt werden soll.