rtrbt

It seems like the MQTT out node sends either to the wrong topic or to the wrong broker. Can you try again, but with mosquitto_sub -v -t '#' instead of mosquitto_sub -v -t 'tinkerforge/#' This will print everything published to the broker.

Can you post the output of mosquitto_sub -t tinkerforge/# and the debug output from the bindings for both cases? (Changing the color via the terminal and with a MQTT out node) Also, the debug node outputs differ: If you use the terminal, the payload is a string, with the node, it is an object. Maybe you have to convert the JSON object to a string before publishing it?

You have to subscribe to the [...]/response/[...] topic, instead of the [...]/request/[...] topic. So in your case mosquitto_sub -t tinkerforge/response/rgb_led_v2_bricklet/Jng/get_rgb_value If you then run mosquitto_pub -t tinkerforge/request/rgb_led_v2_bricklet/Jng/get_rgb_value -m '' in another shell, you will see the color. For debugging purposes, you can start the bindings with tinkerforge_mqtt --debug The response paths are then printed to standard out. Also you can subscribe to tinkerforge/# to see all traffic.

Moin, Der Generator ist dieser hier. Er erzeugt die API-Bindings für alle unterstützten Programmiersprachen und jetzt auch für openHAB. Den kannst du theoretisch bei dir ausführen, aber zur Zeit ist es noch etwas Handarbeit, die openHAB-Bindings zu kompilieren. Erik

Zur Erklärung dazu: Die Konfigurationen der Bricklets hat jetzt ein openhab-Dictionary, darin werden die Channels und Konfigurationsparameter spezifiziert. Das ist im Moment nicht so generisch wie ich es gerne hätte (damit auch andere Sachen wie der Data-Logger das verwenden können), aber erstmal hinreichend. Der Generator nimmt die Informationen und erzeugt daraus aufgebohrte Java-Bindings, die dann von einem generischen DeviceHandler usw. benutzt werden.

Ist inzwischen hier.

Hm, ich glaube, dass du dir das zu kompliziert machst: Falls die Bindings einen nicht fatalen Fehler finden, schreiben sie ins Log und laufen weiter. Beispiele dafür sind nicht-parsebare Topics oder Timeouts usw.. Falls ein fataler Fehler auftritt, d.h. einer bei dem die Bindings nicht weiterlaufen können, dann ist das entweder ein Problem des Rechners auf dem sie laufen, z.B. RAM voll, Abhängigkeiten nicht installiert, defekte Hardware oder sowas. Dann wird der Fehler ausgegeben, es ist aber immer Nutzerinteraktion nötig, um das Problem zu lösen. Oder es ist ein Bug in den Bindings, dann fixen wir den. Automatische Neustarts führen dann nur dazu, dass Probleme versteckt werden. Die Null-Topics gibt es nur für den Zustand der Bindings, Brickd-Status bekommst du wie bei allen anderen API-Bindings über die Callbacks der IP-Connection und get_connection_state. Der MQTT-Status ist ein interessantes Problem: Wenn der nicht "okay" ist, dann können die Bindings das auch nicht mitteilen. Sie sind aber robust dagegen, dass die Verbindung zum Broker mal wegbricht. Für den Binding-Status habe ich drei Topics gebaut, anstelle von einem mit Payload, weil 1. das restart-Topic vor den anderen existierte, d.h. das rückwärtskompatibel zu ändern ist nicht drin. 2. sind das ja eher Trigger, auf die andere Software reagieren soll. Wenn das einzelne Topics sind, kann man sich dann auf das registrieren, was einen interessiert. (So wie es die Bindings selber mit restart machen um Kollisionen mit anderen Bindings-Instanzen zu erkennen) Du kannst dich natürlich auf tinkerforge/callback/bindings/+ registrieren, dann hast zu ein Verhalten, das sehr ähnlich zu einem Topic mit Payload ist.

Moin, Hier die erste Beta der generierten openHAB-Bindings. @Theo: Das ganze hat, wie angekündigt, etwas länger gedauert. Danke nochmal für den Aufwand, den du dir mit deinen Bindings gemacht hast.

Moin, Ich habe die letzten Monate daran gearbeitet, unseren Binding-Generator so aufzubohren, dass auch openHAB-Bindings generiert werden können. Die 24. Beta findet sich hier. Edit: Beta 24 mit folgenden Änderungen: - Reset-Action für Koprozessor-Bricklets hinzugefügt - Simple Mode für NFC hinzugefügt - Neue API als Actions durchgereicht - I2C-Modus für Barometer Bricklet hinzugefügt - Unterstützung folgender Bricklets hingefügt: Industrial Dual AC Relay Industrial PTC IMU 3.0 - Frame Started Channel von LED Strip Bricklets abschaltbar gemacht - Clear Error LED Channel für Bricklets mit Error LED hinzugefügt - Binärinputs von Switch auf Contact gewechselt - Work-Around für nicht funktionierende Actions nach Neustart eines Addons hinzugefügt - Firmware-Updates repariert - Heartbeat-Mechanismus für mehr als 4 Brick Daemons repariert - Die Bindings kompilieren gegen die Java-Bindings 2.1.26. Das heißt, dass zur Installation die Jar mit den Java-Bindings aus der Zip neben die neue openHAB-Bindings-Jar in das addons-Verzeichnis gelegt werden muss. - Online-Dokumentation (vorerst nur auf Englisch) Hier der Inhalt der README: Installation: Die Bindings benötigen eine openHAB 2.5.0 Installation. Zum Installieren reicht es, die beiden JARs in das addons-Verzeichnis zu kopieren. Nachdem openHAB das Addon geladen hat (das kann einen Moment dauern), kann über die Inbox ein Brick Daemon hinzugefügt werden. Konfiguration: Nachdem der Brick Daemon hinzugefügt wurde, werden angeschlossene Geräte automagisch in die Inbox gelegt. Sowohl Geräte als auch Channels können Konfiguration haben: Channels typischerweise die Aktualisierungsrate (Default: 1s). Die Brickletkonfiguration kann Channels anzeigen/verstecken, z.b. erzeugt die Pinkonfiguration der IO-4/16 Input/Output-Channels je nachdem, ob ein Pin auf Input oder Output konfiguriert wurde. Die PaperUI braucht manchmal eine Aktualisierung per F5, damit neue Channels angezeigt werden. Es kann nur Konfiguration gesetzt werden, die im RAM des Geräte gespeichert wird. Persistente Konfiguration muss extern (z.b. mit dem Brick Viewer) gesetzt werden, da openHAB diese jedes Mal schreiben würde, wenn openHAB startet, oder die Verbindung zum Brick Daemon wiederhergestellt wurde usw. Das kostet zu viele Flash-Schreibzyklen. Weitere Dokumentation: Findet sich hier: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab (vorerst nur auf Englisch) Actions in Rules: Es werden für alle unterstützten Geräte Actions zur Verwendung in Rules zur Verfügung gestellt. Um in einer Rule auf die Actions eines Gerätes zuzugreifen, müssen diese zunächst mit var devActions = getActions("tinkerforge", "tinkerforge:[Gerätetyp]:[Device UID]") geladen werden. Danach können sie mit devActions.[actionname]([parameter]) verwendet werden. Zum Beispiel zeigt die folgende Rule auf einem LCD 128x64 Bricklet mit der UID "HQ6" eine graphische Oberfläche an: rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") lcdActions.brickletLCD128x64ClearDisplay() lcdActions.brickletLCD128x64RemoveAllGUI(); lcdActions.brickletLCD128x64SetGUIButton(0, 0, 0, 60, 20, "button"); lcdActions.brickletLCD128x64SetGUISlider(0, 0, 30, 60, 0, 50); lcdActions.brickletLCD128x64SetGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y"); lcdActions.brickletLCD128x64SetGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15)); lcdActions.brickletLCD128x64SetGUITabConfiguration(3, false); lcdActions.brickletLCD128x64SetGUITabText(0, "Tab A"); lcdActions.brickletLCD128x64SetGUITabText(1, "Tab B"); end Funktionen, die Arrays erwarten, können in openHAB-Regeln auch mit Listen verwendet werden, wie dies im Beispiel von setGUIGraphData gezeigt wurde. Rückgabewerte werden als eine Map<String, Object> zurückgeben, diese kann wie folgt verwendet werden: rule "otherrule" when Item Enx_Button changed to OFF then val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") pixels = lcdActions.brickletLCD128x64ReadPixels(0, 0, 127, 63).get("pixels") val inverted = pixels.map[p | !p] lcdActions.brickletLCD128x64WritePixels(0, 0, 127, 63, inverted) end Die Rule wird ausgelöst, wenn das Item Enx_Button auf OFF geändert wird (d.h. wenn der zugehörige RGB LED Button losgelassen wird). Sie liest gesamten Pixel des LCD Bricklets aus, invertiert diese und zeichnet die invertierten Pixel wieder auf das LCD. Über Actions kann fast die gesamte API der Geräte genutzt werden. Actions die den Zustand von Channels ändern, aktualisieren diese automatisch. Nicht unterstützt werden Operationen, die EEPROM- oder Flash-Speicher der Geräte schreiben würden. Auch hier sollen unnötige Schreibzyklen vermieden werden. Display-Bricklets: Text wird auf folgende Weise gesetzt: [line],[position],[text]. Weitere ',' nach den ersten beiden werden als Teil des Textes behandelt. Der Text kann mit \x[zwei Hex-Ziffern] das Character-Set des Displays verwenden. Zusätzlich werden Unicode-Zeichen so gut es geht auf das Display-Character-Set abgebildet, wie das auch in den Code-Beispielen passiert, siehe z.B. hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/LCD20x4_Bricklet_Java.html#unicode Beispielsweise gibt 1,2,Hallo, opεnH\xE0B! auf einem LCD 20x4 in Zeile 1, Spalte 2 aus: Hallo, opεnHαB! Das kleine Epsilon wurde von Unicode in das LCD-Character-Set übersetzt, 0xE0 (224) entspricht dem kleinen Alpha. Die PaperUI scheint Leerzeichen am Rand des Commands abzuschneiden. Um (Teile) einer Zeile zu löschen kann also nicht ein Befehl wie 1,2,[Leerzeichen] verwendet werden. Stattdessen kann 1,2,\xFE\xFE\xFE benutzt werden um in Zeile 1, Spalte 2 drei Zeichen zu löschen. Fehlende Features: Channels akzeptieren nur einen CommandTypen, d.h. z.B. LED des RGB LED Button Bricklets nimmt nur HSBType an, nicht die anderen, die von openHAB erwartet werden (wie PercentType wenn die Brightness geändert wird) Bekannte Bugs: Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL. PaperUI zeigt die Description von Channel(Typen) und Konfigurationsparameter-Gruppen nicht an. Unbekannte Bugs: Falls ein anderer Bug auftritt, bitte das openHAB-Log mit anhängen. Das Log findet sich im userdata/logs-Verzeichnis der openHAB-Installation. Falls der Bug reproduzierbar ist, kann mit log:set TRACE org.openhab.binding.tinkerforge (in der Karaf-Konsole) das LogLevel erhöht werden, dann erscheinen eventuell weitere hilfreiche Informationen im Log. Außerdem hilfreich ist log:exception-display. Falls Fehler in der PaperUI angezeigt werden, können diese mit der Netzwerkanalyse der Web-Entwickler-Tools untersucht werden. Dann mit laufender Analyse die Seite neuladen und die Antworten von Anfragen mit Statuscode 500 ansehen. Eventuell hilft hier auch log:exception-display.

Brauchst du die externe Restartlogik für die Bindings oder dein Programm, dass mit dem Bindings MQTT spricht? Den KeyboardInterrupt kannst du mit Strg-C auslösen, oder indem du SIGINT schickst. Ich habe gerade mal noch eingebaut, dass SIGTERM und SIGQUIT auch funktionieren. Edit: Durch das sinnvollere Signal-Handling kann man die Bindungs auch als systemd-Service verwenden, ein Beispiel-Service-File habe ich mal angehangen. tinkerforge_mqtt_bindings_2_0_8_beta2.zip tinkerforge_mqtt.service

Moin, Ich habe für die nächste Version der MQTT-Bindings mal einiges gefixt: Das stimmt. Das Problem war, dass zuerst die IP-Connection aufgebaut wurde, danach die Verbindung zum Broker. Das passiert jetzt andersrum. Das Init-File unterstützt jetzt eine zweigeteilte Syntax in dieser Form: { "pre_connect": { "tinkerforge/register/ip_connection/connected": {"register": true}, "tinkerforge/register/ip_connection/enumerate": {"register": true} }, "post_connect": { "tinkerforge/request/ip_connection/enumerate": "" } } Mit diesem Beispiel-Init-File werden vor dem Verbinden der IP-Connection die Callbacks registriert und direkt nach dem Connect wird ein Enumerate ausgelöst. Der Disconnected-Callback meldet den Verlust der TCP-Connection zum Brick Daemon. Wenn du das Netzwerkkabel rausziehst, wird die aber nicht geschlossen. Wenn du den Brick Daemon beendest, sollte der Callback auslösen. Detektieren, ob die Netzwerkverbindung an sich unterbrochen ist, können aktuell keine Bindings. Langfristig ist dafür aber eine Lösung geplant. Das kannst du aktuell auch haben, indem du tinkerforge/# subscribst und nachsiehst ob "_ERROR" im Payload ist. Eigentlich sollte es nicht nötig sein, die Bindings neuzustarten. Hast du das Verhalten bei Verbindungsproblemen mit den aktuellen Bindings getestet? Ich hatte für Version 2.0.7 einiges am Verhalten geändert, damit es saubere Reconnects zum Broker und Brick Daemon gibt. Falls du mit der angehangenen Version in der Richtung noch Probleme hast, gib nochmal Bescheid. Die Bindings schicken wie gehabt "null" nach tinkerforge/callback/bindings/restart und mit der neuen Version auch nach tinkerforge/callback/bindings/shutdown, wenn sie normal beendet werden oder nach tinkerforge/callback/bindings/last_will, falls sie abgeschossen wurden oder die Verbindung weg ist. Ich habe die aktuelle Version mal angehangen. tinkerforge_mqtt_bindings_2_0_8_beta.zip

Für die Updatesuche und Firmwaredownloads ist das immer https://download.tinkerforge.com

Ist aktuell nicht geplant, sorry.

Moin, Kannst du das ganze mit einer älteren Brick Viewer Version (2.4.6 oder älter) testen? Wir haben mit der 2.4.7 alle Verbindungen auf https umgestellt, eventuell macht das bei dir Probleme.

Moin, Führst du den Brick Viewer aus Source aus? Die Pfade im Callstack sehen so aus. Da wir vor kurzem Teile der UI geändert haben, musst du nochmal build_src.py in brickv/src ausführen, damit die neuen UI-Elemente in Pythoncode gegossen werden.

Moin, Das funktioniert nicht out-of-the-Box, da müsste man einen eigenen Kerneltreiber schreiben. Ein Seriell-USB-Wandler + USB-Hub ist da einfacher. Alternativ kannst du ein GPS-Bricklet und dieses Programm benutzen.

Moin, Das sollte mit 2.4.9 gefixt sein.

Dafür musst du die Teile in dem Datumsstring auch durch Platzhalter ersetzen, die du dann mit String.Format einsetzt, z.B so: myProcess.StartInfo.Arguments = String.Format("/bin/date -s \"{0:00} {1} {2:0000} {3:00}:{4:00}:{5:00}\"", jahr, monat, tag, stunde, minute, sekunde); Den Monat musst du als String reingeben, also z.b. AUG oder SEP. Alternativ kannst du dir mal die anderen Formate ansehen, die date versteht, die sind z.B. hier dokumentiert.

Das sieht schon mal besser aus. Jetzt wäre wieder dmesg interessant. Außerdem kannst du mit lsusb -t nachsehen, ob überhaupt einer und wenn ja, welcher Treiber geladen wird.

Ah, manchmal ist man einfach betriebsblind, sorry dafür. Das Problem ist, dass StartInfo den Namen der ausführbaren Datei und die Argumente getrennt will, da ja auch keine Shell benutzt wird (deshalb optionalerweise UseShellExecute = false). So funktioniert es bei mir: using (Process myProcess = new Process()) { myProcess.StartInfo.FileName = "/usr/bin/sudo"; myProcess.StartInfo.Arguments = String.Format("/bin/date -s \"22 AUG 2019 {0:00}:{1:00}:{2:00}\"", stund, minut, sekund); myProcess.Start(); }

Was für eine Fehlermeldung bekommst du, wenn du myProcess.Start(); aufrufst?

Was gerade noch aufgefallen ist: Datum/Zeit zu setzen geht nur mit Root-Rechten. Du kannst aber dem Standarduser (also tf) erlauben, das ohne Root-Passwort zu tun, in dem du auf der seriellen Konsole des RED-Brick einmalig folgenden Befehl ausführst: echo 'tf ALL=(root) NOPASSWD: /bin/date' | sudo tee -a /etc/sudoers Wenn du dann in deinem Programm /bin/date durch /usr/bin/sudo /bin/date ersetzt, sollte es klappen.

Process kannst du verwenden, wie hier beschrieben. In deinem Fall müsste myProcess.StartInfo.FileName = "C:\\HelloWorld.exe"; stattdessen myProcess.StartInfo.FileName = String.Format("/bin/date -s \"22 AUG 2019 {0:00}:{1:00}:{2:00}\"", stunde, minute, sekunde); (o.Ä.) sein.

Am einfachsten mit Etcher, hier wird erklärt wie das geht. Damit wird allerdings alles auf der Micro-SD-Karte überschrieben, d.h. du solltest ein Backup von Daten, die du auf dem alten Image geändert hast, ziehen, oder alternativ eine andere Micro-SD-Karte benutzen.

Der Befehl heißt lsusb mit kleinem L nicht großem i. Abgesehen davon solltest du dein Image mal auf 1.14 aktualisieren (oder zumindest damit mal testen).