Brick MQTT Proxy mit Outdoor Weather Station

[riro]

Hallo Forum!

 

auf einem Raspberry läuft der Brickdaemon und kann die Werte des per USB angeschlossen Masterbricks und dessen Outdoor Weather Bricklet (Es8) auslesen:

 

./tinkerforge call outdoor-weather-bricklet Es8 get-sensor-data 24

Ausgabe auf der Konsole:
temperature=258
humidity=33
last-change=23

 

Mit Hilfe der Doku https://www.tinkerforge.com/de/doc/Software/Brick_MQTT_Proxy.html konnte ich Mosquitto installieren und bekomme auch einen Output:

 

mosquitto_sub -v -t tinkerforge/enumerate/available/#
Ausgabe:
tinkerforge/enumerate/available/brick/master [{"_timestamp":1530606396.92745,"uid":"6wVYa1","hardware_version":[2,0,0],"device_identifier":13,"connected_uid":"0","position":"0","firmware_version":[2,4,8]}]
tinkerforge/enumerate/available/bricklet/outdoor_weather [{"_timestamp":1530606397.065804,"uid":"Es8","hardware_version":[1,0,0],"device_identifier":288,"connected_uid":"6wVYa1","position":"a","firmware_version":[2,0,0]}]

 

Bisher findet das brick_mqtt Script folgende Werte und veröffentlicht diese auch:

 

python brick-mqtt-proxy.py --brickd-host localhost --brickd-port 4223 --broker-host localhost --broker-port 1883 --update-interval 5 --debug

DEBUG:root:Subscribing to tinkerforge/bricklet/outdoor_weather/Es8/get_station_data/set
DEBUG:root:Subscribing to tinkerforge/bricklet/outdoor_weather/Es8/get_sensor_data/set
DEBUG:root:Subscribing to tinkerforge/bricklet/outdoor_weather/Es8/_update_interval/set

 

MQTTfx empfängt folgendes:

 

tinkerforge/bricklet/outdoor_weather/Es8/sensor_identifiers
mit dem "Payload": {"sensor_identifiers":[24],"_timestamp":1530608493.82582}

 

 

Die Wetterstation besteht aus zwei Teilen: der großen Station (station_identifiers) und dem kleinen Outdoor Sensor (sensor_identifiers). Der kleine Sensor hat die Nummer "24" (oder [24]) und dessen Werte würde ich gerne veröffentlichen. Es gelingt mir aber nicht, den richtigen Befehl abzusetzen:

 

mosquitto_pub -t tinkerforge/bricklet/outdoor_weather/Es8/sensor_data/set -m '[24]'

 

Damit erhalte ich natürlich nur den Payload '[24]', aber nicht die Sensordaten.

 

Für mich ist die Doku hier zu spärlich:

 

sensor_identifiers

    sensor_data/set (calls get_sensor_data with the parameters provided by the get_sensor_data/set topic and the output of the getter being published to the sensor_data topic)

 

Kann mir da jemand bitte weiterhelfen?

 

Vielen Dank!

 

 

 

[photron]

Die jetzige Implementierung erwartete da folgendes:

 

mosquitto_pub -t tinkerforge/bricklet/outdoor_weather/Es8/get_sensor_data/set -m 24

 

Das Vorgehen ist aber inkonsistent zum restlichen Verhalten des MQTT Proxies. An anderen Stellen wo wir solche Getter haben die ein Parameter haben ruft der MQTT Proxy intern den Getter mit allen möglichen Parameterwerten ab und erstellt daraus dann eine Message.

 

Das habe ich jetzt auch für das Outdoor Weather Bricklet so abgeändert. Mit der aktuellen git Version kommt dann da sowas bei heraus (formatiert für bessere Übersicht):

 

tinkerforge/bricklet/outdoor_weather/Fax/station_data {
    "_timestamp":1530613201.561859,
    "241":{
        "wind_speed":0,
        "temperature":265,
        "wind_direction":255,
        "gust_speed":6,
        "rain":120,
        "humidity":31,
        "last_change":1526,
        "battery_low":false
    },
    "149":{
        "wind_speed":0,
        "temperature":262,
        "wind_direction":15,
        "gust_speed":0,
        "rain":969,
        "humidity":32,
        "last_change":38,
        "battery_low":false
    }
}

tinkerforge/bricklet/outdoor_weather/Fax/sensor_data {
    "_timestamp":1530613201.572538,
    "179":{
        "last_change":37,
        "temperature":253,
        "humidity":38
    }
}

 

Ich empfange hier zwei Stationen (241 und 149) und einen Sensor (179).

[riro]

Danke!

 

Und ich wunderte mich schon, warum ich nicht weiterkam.

 

Wo kann ich das aktuelle Binding beziehen? Und was muss ich auf dem Raspberry austauschen?

 

 

[photron]

Du kannst hier die aktuellste Version der brick-mqtt-proxy.py Datei herunterladen

 

https://raw.githubusercontent.com/Tinkerforge/brick-mqtt-proxy/master/brick-mqtt-proxy.py

 

und deine Version damit ersetzen. Dass sollte dann schon alles sein.

[riro]

Dankeschön!

 

Auf welchem Channel hast Du die Antwort vom Sensor erhalten?

 

Und mit welchem Befehl startest Du den Publish der Daten?

 

Ich nutze MQTTfx - und da tauchen keine Wetterdaten auf. Nur eben die allgemeinen Daten zur Firmware, Spannung, Stationsnummer usw.

[photron]

Ich starte brick-mqtt-proxy.py auf dem PC an dem auch das Outdoor Weather Bricklet angeschlossen ist und der Mosquitto Broker läuft:

 

python brick-mqtt-proxy.py

 

Und dann laufen da unter

 

tinkerforge/bricklet/outdoor_weather/<UID>/station_data

tinkerforge/bricklet/outdoor_weather/<UID>/sensor_data

 

die Daten ein:

 

mosquitto_sub -v -t tinkerforge/bricklet/outdoor_weather/#

[riro]

Danke! Jetzt geht es! Und ich habe da so rumprobiert.

 

Wie kann man diese Info in der Tinkerforge Doku ergänzen, damit der Nächste nicht auch so raten muss?

(Wenn ich nur das Script

python brick-mqtt-proxy.py

starte passiert (?) nichts. Erst wenn ich

python brick-mqtt-proxy.py --brickd-host localhost --brickd-port 4223 --broker-host localhost --broker-port 1883 --update-interval 5

kann ich die Daten empfangen.

Führte

mosquitto_sub -v -t tinkerforge/bricklet/outdoor_weather/#

dazu, das alle Channel vom Weather Bricklet "subscribed" werden? Wird damit die Tinkerforge "Seite" mit dem Mosquitto Broker verbunden?)

 

Welcher MQTT Broker bietet sich an, diese Daten zu veröffentlichen (an einen Nachbarn)? Oder einfach nur eine Portfreigabe und Weiterleitung zu dem Broker auf dem Raspberry Pi?

Tinkerforge verwendete mal Xively, das ging zu Google über.

[photron]

Das ist komisch, dass du da die Parameter beim Starten alle angeben musst. Denn du gibst da jeweils exakt die Standardwerte an, außer beim Update Intervall, das ist standardmäßig 3 Sekunden.

 

Beim Subscribe kennt MQTT # und * als Platzhalter im Topic. Dabei steht # für beliebig viele Element im Topic und * für exakt ein Element im Topic. Wenn du also  das hier ausführst

 

mosquitto_sub -v -t tinkerforge/bricklet/outdoor_weather/#

 

dann sendet mosquitto_sub eine Subscribe Anfrage an den Broker für das tinkerforge/bricklet/outdoor_weather/# Topic. Der Broker vergleicht dann alle eingehenden Nachrichten mit dem Topic und sendet dann an mosquitto_sub alle die übereinstimmen.

 

Der mosquitto_sub hat aber keinen Einfluss darauf was das brick-mqtt-proxy.py Script tut. So funktioniert MQTT nicht.

 

MQTT arbeitet nach dem Publish/Subscribe Modell. Clients (mosquitto_sub, mosquitto_pub, brick-mqtt-proxy.py, etc) kommunizieren nicht direkt miteinander, sondern immer nur mit einem Broker der dann die Nachrichten zwischen den Clients weiterleitet.

 

brick-mqtt-proxy.py verbindet sich mit dem Broker und sendet (Publish) im Update Intervall Nachrichten über die Bricks und Bricklets an den Broker. Das ist völlig unabhängig davon, ob noch anderen Clients verbunden sind, die die Nachrichten empfangen können, oder nicht.

 

mosquitto_sub verbindet sich mit dem Broker und teilt diesem mit (Subscribe), dass es gerne Nachrichten unter dem angegebenen Topic empfangen würde. Der Broker schaut sich die Topics der eingehenden Nachrichten an (z.B. von brick-mqtt-proxy.py). Wenn eine Übereinstimmung mit einer Subscription vorliegt, dann wird die Nachricht an den entsprechenden Client weitergeleitet. Wenn sich keiner für die Nachricht interessiert wird sie im Broker verworfen.

 

Du kannst dir das als stille Post mit 3 Personen vorstellen. Der Broker sitzt in der Mitte und brick-mqtt-proxy.py flüstert dem Broker was von links ins Ohr. Der Broker flüstert dann die Nachrichten weiter an mosquitto_sub auf der rechten Seite, aber nur die Nachrichten mit einem Topic das mosquitto_sub dem Broker vorher genannt hat.

 

Wenn es nur darum geht deinem Nachbarn Daten weiterreichen zu können, dann ist wahrscheinlich eine einfache Portfreigabe des Broker Ports am einfachsten.