Wetterstation - Daten auf den KNX Bus bringen

[TorstenE]

Hallo Mitstreiter,

ich beziehe mich mal auf das Thema "KNX Bus Zeit sync mit NTP Binding".
Wenn ich die Uhrzeit auf den KNX-Bus bekomme, dann sollte ich doch die
Wetterdaten über den gleichen Weg (angepasste Items/Things) auf
den KNX-Bus bekommen.

Dann kann ich mir im ersten Schritt doch eine "teure" Wetterstation
sparen.

Hat das schon jemand realisiert ?

Danke

Torsten

[udo1toni]

Welche Wetterdaten willst Du denn haben? Ich nutze das z.B. für die Außentemperatur.
Es ist natürlich so, dass ein Sensor am eigenen Haus besser ist, als öffentlich von irgendeiner Wetterstation in der Nähe zur Verfügung gestellte Messwerte, aber die Sensoren müssen nicht zwingend knx Geräte sein

[TorstenE]

Ich habe die ECOWITT Wlan Wetterstation funk mit Außensensor HP2561, 7 in 1 WiFI Solarbetrieb letztes Jahr zum Rumtesten gekauft. Hier das entsprechende Binding dazu Fine Offset Weather Station Binding Die reicht mir derzeit vollkommen aus. Zum Einstieg in die KNX-Welt würde ich diese einfach weiter betreiben und die Werte auf den Bus schicken, so der Plan. Zu einem späteren Zeitpunkt oder wenn das Teil kaputt ist, kann ich immer noch ein andere kaufen.

[TorstenE]

Mir war klar, dass die beiden Channel über das Item miteinander verbunden sind. Mir war nur nicht klar was das Profil "follow" auf dem KNX-Channel sein sollte. Habe inzwischen die Einstellung gefunden und die Wetterdaten (Temperatur) kommen auf dem KNX-Bus (Gruppenadresse) an.

[udo1toni]

Ah. Es gibt beim knx Binding eine Besonderheit, die es von allen anderen Bindings unterscheidet.
Zunächst mal ist Kommunikation fast immer gerichtet, über einen Kanal (nicht Channel!) kommen Nachrichten nach openHAB, über einen anderen Kanal gehen Nachrichten aus openHAB in Richtung der Hardware.
Im Thing werden gewöhnlich beide Richtungen zu einem Channel zusammengefasst. Beispiel mqtt: da gibt es ein stateTopic und ein commandTopic (getrennte Wege rein/raus), der Channel selbst ist aber sowohl für Befehle als auch für die Status zuständig.
Weiterhin wird grundsätzlich ein von außen kommendes "Datenpaket" als Status gewertet, ein abgehendes Datenpaket wird grundsätzlich durch einen Befehl ausgelöst - entsprechend den beiden Methoden .postUpdate() für den Status und .sendCommand() für den Befehl.
"Grundsätzlich" heißt aber, dass es Ausnahmen gibt. Bei verschiedenen Bindings (z.B. mqtt) kann man einen Channel dann als Command markieren (isCommand=true), das heißt, ein ankommender "Status" wird nun als Befehl weitergeleitet. Bei anderen Bindings läuft es über spezielle Event Channel, die dann als Event in Rules verwendet werden können.
In knx ist es so, dass man jeden Channeltyp zweimal hat, einmal "normal", einmal als "control" Variante. Es gibt also z.B. switch und switch-control.
Bei switch-control wird ein kommendes Datenpaket dann als Befehl gewertet und auch so an den internen Bus weitergeleitet - das verlinkte Item wird per .sendCommand() angesprochen. Zusätzlich werden bei knx Statusänderungen - also was per .postUpdate() im Item landet - an die *.control Channel weitergeleitet.
Auf diese Weise ist es möglich, z.B. eine mqtt Schaltsteckdose direkt mit einem knx Wandtaster anzusteuern - mitsamt Rückmeldung des Schaltzustands, ohne eine einzige Zeile Code.
Mit dem Profile "follow" kann man einen Channel dazu bewegen, jede Statusänderung eines Items als Befehl zu werten (und somit an die angebundene Hardware weiterzuleiten). Das funktioniert für alle Bindings, ob sie das nun von Haus aus unterstützen oder nicht.
Für die Weiterleitung von externen Messwerten auf den knx Bus ist aber die control-Variante die saubere Wahl.
z.B. (wie immer als Text Definition):
Things:

Code: Alles auswählen

Thing ntp:ntp:local [ ... ]

Bridge openweathermap:weather-api:api "OpenWeatherMap Account" [ ... ] {
    Thing weather-and-forecast local "Local Weather And Forecast" [ ... ]

Bridge knx:ip:bridge [ ... ] {
    Thing device virtuell "GA ohne Device" {
    Channels:
        Type dateTime-control : time [ ga="10.001:15/7/1" ]
        Type   number-control : temp [ ga="15/7/2" ]
    }
} 

Item:

Code: Alles auswählen

DateTime Zeit        "Zeit"      { channel="ntp:ntp:local:dateTime", channel="knx:device:bridge:virtuell:time" }
Number   Temperatur "Temperatur" { channel="openweathermap:weather-and-forecast:api:local:current#temperature", channel="knx:device:virtuell:temp" }

Mehr braucht es nicht, um Zeit und Temperatur auf den Bus zu bringen. Da ich auf der Arbeit bin, sind die Things ausgedacht, aber es geht ja auch nur ums Prinzip

[TorstenE]

Guten Morgen Udo,

erst mal Danke für ein "tieferes Grundverständnis in OH".

Das in einem Thing der Kanal sozusagen "aufgeteilt" werden kann,
war mir bisher neu, zumindest war es mir nicht so bewusst.

Grüße

Torsten

[udo1toni]

Was meinst Du mit "aufgeteilt"?

[TorstenE]

Ich kenne das mit dem "stateTopic" und "commandTopic" in den MQTT-Bindings schon.
Ich dachte das sind nur "Abfrageparameter" bzw. "Sendparameter" für MQTT.

Das dies aber komplett eigenständige Kommunikations-Wege innerhalb eines Kanales sind war mir nicht bewusst, wenn
man das so formulieren kann.

[udo1toni]

Ja, das eine ist halt die Senderichtung, das andere die Empfangsrichtung. Und auch im Item sind die beiden Teile grundsätzlich voneinander unabhängig (wenn man den Parameter autoupdate="false" setzt). Nur wird man gewöhnlich eine zum gesendeten Befehl passende Antwort bekommen (passend in dem Sinne, dass sie mehr oder weniger identisch ausfällt).

[TorstenE]

Ja, das eine ist halt die Senderichtung, das andere die Empfangsrichtung. Und auch im Item sind die beiden Teile grundsätzlich voneinander unabhängig (wenn man den Parameter autoupdate="false" setzt). Nur wird man gewöhnlich eine zum gesendeten Befehl passende Antwort bekommen (passend in dem Sinne, dass sie mehr oder weniger identisch ausfällt).

Kannst Du hier bitte ein Beispiel geben, wie man das macht und für was es eingesetzt wird ?