MQTT / 4x7-segment

[duaw]

Hallo!

 

Ich bin jetzt erst dazu gekommen, mit dem Bindung erste Schritte zu machen.

 

Und schon beim Nachvollziehen komme ich ins Straucheln:

 

--rgb_led_button geht, allerdings dauert es ganz schön lang, bis ein

 

mosquitto_pub -t tinkerforge/request/rgb_led_button_bricklet/Enx/get_color -m '' -h 192.168.1.18

 

im MQTT.fx eine Reaktion liefert.

 

Und dort kommt auch

{"red": "{", "green": "\"", "blue": "r"}

an,  obwohl ich vorher

{"red":0, "green":255, "blue":255}

geschickt habe und das auch ankam ...

 

-- Vor lauter Betriebsblindheit habe ich nicht gemerkt, dass  das Beispiel nach "Auch aufgetretene Fehler werden unter 'response'-Topics gepublisht, ..." GAR NICHT FEHLERHAFT IST ... Dazu hätte es natürlich so etwas gebraucht:

 

mosquitto_pub -t tinkerforge/request/rgb_led_button_bricklet/D3P/set_color -m '{"red":0, "green":255}' -h 192.168.1.18

{"_ERROR": "The arguments ['blue'] where missing for a call of set_color of device D3P of type rgb_led_button_bricklet."}

 

An der Stelle möchte ich noch mal betonen, dass es gerade für Anfänger absolut wichtig ist, eine vollständige, korrekte, hilfreiche Doku zu haben! Die Doku darf nicht von der Nerd- oder Profi-Warte aus geschrieben sein! Sie muss auch sprachlich, orthografisch und was die Interpunktion  angeht, sich auf akzeptablem Niveau bewegen! Da sehe ich Luft nach oben.

 

-- Es gelingt mir partout NICHT die Segmente eines 4x7 zu setzen:

 

mosquitto_pub -t tinkerforge/request/segment_display_4x7_bricklet/wNX/set_segments -m '{"segments": [102, 91, 91, 79], "brightness": 7, "colon": false}'  -h 192.168.1.18

 

(Das Abfragen der Segmente aber schon!)

 

Gruß, Uwe

[rtrbt]

Moin,

 

die Bindings sollten eigentlich, abgesehen von der Netzwerklatenz, nicht langsam sein. Sind die Reaktionen auch verzögert, wenn du das ganze lokal testest?

 

{"red": "{", "green": "\"", "blue": "r"}

Das sieht kaputt aus. Die Zahlen sollten nicht als Zeichen interpretiert werden. Ist das Ausgabe von MQTT.fx?

 

Das falsche (oder richtige, je nach dem ) Beispiel habe ich mal repariert, es dauert aber noch etwas bis es sichtbar wird.

 

Bezüglich des 4x7 Displays, teste bitte mal ob das mit der angehangenen Variante der Bindings auch auftritt.

 

Gruß und schönes Wochenende,

Erik

 

Edit: Du kannst übrigens testen ob die Bindings deine Nachrichten verstehen, indem du den --show-payload Parameter beim Starten mitgibst. Wenn die Bindings dann keine Fehlermeldungen mit dem Payload als string ausgeben, haben sie dich verstanden, wenn es dann nicht klappt, sind die Bindings kaputt.

tinkerforge_mqtt_bindings_2_0_3.zip

[rtrbt]

Bezüglich des Zeichenproblems: Sieht die Antwort auch so aus wenn du sie mit

mosquitto_sub -t 'tinkerforge/#' -h 192.168.1.18

abholst?

[duaw]

Hallo!

 

Neue Version,

-- keine seltsame Ausgabe mehr, keine Verzögerungen (Komisch. Was war das? Es gab nach start_counter über den Brickv auch alle paar Zahlen eine kurze Verzögerung ...)

-- Der Aufruf

mosquitto_pub -t tinkerforge/request/segment_display_4x7_bricklet/wNX/set_segments -m '{"segments": [102, 91, 91, 79], "brightness": 7, "colon": false}' -h 192.168.1.18 

mündet im tinkerforge_mqtt in

Traceback (most recent call last):
  File "/usr/local/bin/tinkerforge_mqtt", line 6138, in on_message
    response = self.dispatch_call(request_type, device, uid, function, msg.payload, response_path)
  File "/usr/local/bin/tinkerforge_mqtt", line 6475, in dispatch_call
    return self.device_call(device, device_class_name, uid, fnName, fnInfo, json_args)
  File "/usr/local/bin/tinkerforge_mqtt", line 6544, in device_call
    args = [symbols[data] if data in symbols else data for symbols, data in zip(reversed_symbols, args)]
  File "/usr/local/bin/tinkerforge_mqtt", line 6544, in <listcomp>
    args = [symbols[data] if data in symbols else data for symbols, data in zip(reversed_symbols, args)]
TypeError: unhashable type: 'list'

 

Gruß, Uwe

[rtrbt]

Dass die Verzögerungen weg sind, kann ich dir spontan nicht erklären, vielleicht ist das Netzwerk weniger ausgelastet?

 

Bist du dir sicher, dass du die Version ausführst, die ich angehangen habe? Diese Fehlermeldung kann von der neuen Version eigentlich nicht erzeugt werden, weil die Codezeilen, die ausgegeben werden, so nicht mehr vorkommen. In der neuen Version der tinkerforge_mqtt-Datei steht in Zeile 23

from collections.abc import Hashable

Wenn das fehlt, hast du die falsche.

[duaw]

Uppps ... geht!

 

(Vorschlag: Eine Sub-Versionsnummer im Dateinamen -- 2_0_3_1 -- und in der Datei hätte mir das deutlich gemacht ... )

 

 

Sorry.

 

Wie weit habt ihr denn das schon selbst getestet?

 

Gruß (und einen schönen -- arbeitsfreien!  -- Sonntag) Uwe

 

[duaw]

Nachtrag:

 

Die kurzen Verzögerungen (0,2s schätze ich) waren an localhost / Brickv bemerkbar. Spielt da das Netzwerk eine Rolle??? Und die Kiste ist alles andere als ausgelastet. Kann ich aber nicht mehr reproduzieren.

 

Uwe

[rtrbt]

Die kurzen Verzögerungen (0,2s schätze ich) waren an localhost / Brickv bemerkbar. Spielt da das Netzwerk eine Rolle???

 

Hm vielleicht hingen da noch Pakete im Buffer vom Brick Daemon. Im Normalbetrieb sollte das nicht passieren, es sei denn du versuchst mehr als 1000 Nachrichten pro Sekunde an die Bricklets zu schicken. Z.B. wenn du den Counter vom Segment Display auf 1ms konfigurierst und parallel noch andere Sachen machst.

[rtrbt]

Der Fix ist in der Version 2.0.4 der Bindings enthalten, falls du wieder auf eine "offizielle" Version wechseln willst.