rtrbt

16 hours ago, Tipsy Tinker said:

Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen.

Vielleicht hat jemand ne Idee, woran das liegen könnte?!

Das war ein Firmware-Bug, mit der frisch veröffentlichten 2.0.15 geht es bei mir. Hintergrund war, dass die Größe des Antwortpakets zu groß war (copy-paste-Fehler, es hat die Größe des AngularVelocityCallbacks benutzt). Die Bindings prüfen die Länge von Callback-Paketen und ignorieren zu kurze und zu lange Pakete, deshalb kam bei dir nichts an.

16 hours ago, Tipsy Tinker said:

Gefühlt gibt es ein Performance-Unterschied zwischen:

• Alle Werte per Callback erheben, diejenigen die ich benötige loggen

zu:

• Nur diejenigen per Callback erheben und loggen, die ich benötige

 

liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ?

Da gibt es tatsächlich Unterschiede: Die Bricks und Bricklets laufen mit einer Tickrate von 1 kHz. Pro Tick kann nur ein Paket erzeugt werden. Wenn du also Werte aus zwei Callbacks brauchst, kannst du jeden Wert nur noch mit 500 Hz auslesen. Aus Brick-Kommunikationssicht ist es also tatsächlich sinnvoller, das AllData-Callback zu benutzen und die Werte wegzuwerfen, die du nicht brauchst. Wenn du über ein Netzwerk gehst kann das natürlich anders aussehen, aber wir reden hier immer noch von sehr kleinen Datenmengen (z.b. beim AllData-Callback 54 kB/s).

Das OLED kann von sich aus nur die eine Textgröße darstellen. Die großen Zahlen für das Beispielvideo werden als Bild gezeichnet:

https://github.com/Tinkerforge/oled-128x64-bricklet/blob/master/software/examples/python/example_draw_servo_poti.py

Etwas ähnliches müsstest du dann auch machen. Du könntest dir zum Beispiel eine Bitmap-Font suchen oder Text mit einer Graphikbibliothek rastern und dann die Pixel auf das Display schieben.

Moin,

Das Voltage/Current kann nur positive Spannungen messen. Du kannst alternativ aber das Industrial Dual Analog In 2.0 Bricklet verwenden, wenn es dir reicht die Spannung zu messen. Wenn du auch den Strom brauchst wird es schwierig.

Hi,

You are correct, this is a leftover from the Motion Detector 1.0.

Fixed here: https://github.com/Tinkerforge/generators/commit/00d5353862f06851fae593b603d4948fed0c1b5c The change will show up in the documentation when we build it the next time.

For the Motion Detector 2.0, you indeed have to control the indicator LEDs yourself.

17 hours ago, bs. said:

[16:16:43] Local modules not found in ~/warp-charger/software/esp32-brick/software/modules/backend/authentication/login_page_ignored
[16:16:43] Try running: npm install

Ah das ist das Problem. Geh mal in den Ordner ~/warp-charger/software/esp32-brick/software/modules/backend/authentication/login_page_ignored und führe npm install aus. Da die Login-Seite separat vom Rest gebaut wird, braucht sie auch eine eigene Installation des ganzen Javascript-Haufens. Ich teste hier mal, ob es eine gute Idee ist den Befehl über das prepare-Script immer auszuführen oder ob das den Build-Prozess unnötig verlangsamt.

Die anderen Typescript-Fehler kannst du ignorieren, da ist die Typprüfung nicht ganz zufrieden, das funktioniert aber.

Hast du davor noch mehr Fehlerausgabe? Das Authentication-Modul im esp32-brick bringt eine eigene Login-Seite mit, die in genau diese Datei gepackt werden sollte. Eventuell ist das bei dir schiefgegangen.

Falls du das debuggen willst: Der Prozess ist etwas kompliziert. Ich benutze die pio_hooks.py um mich in den PlatformIO-Buildprozess reinzuhängen und die konfigurierten Module nach src/modules zu kopieren (Sowohl die aus warp_charger/software/modules als auch die aus dem esp32-brick). Wenn in einem Modul eine prepare.py liegt führe ich die davor aus, um damit z.B. die Loginseite zu erstellen.

Ich meinte damit folgendes: Du kannst die MQTT-Bindings von uns (hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html) benutzen und die Werte mit der oben verlinkten MQTT-Sensor-Integration von Home Assistant auslesen. Wenn du da etwas runterscrollst kommt eine Erklärung, wie du mit JSON-Daten (das Format benutzen wir für die MQTT-Bindings) umgehen kannst.

Du musst dann noch die Callbacks der Bricks/Bricklets aktivieren, die du benutzen willst. Dafür kannst du ein init_file schreiben, das ist eine Konfigurationsdatei für die MQTT-Bindings, die initial ausgeführt wird.

Am besten experimentierst du etwas mit den MQTT-Bindings, Mosquitto mit den mosquitto_pub- und _sub-Befehlen bieten sich da an.

Wenn du wirklich eine native Home Assistent-Anbindung (also ein Binding) schreiben willst: das ist vom Aufwand her vergleichbar mit den openHAB-Bindings in die ich schon ungefähr 9 Monate Arbeit versenkt habe, da würde ich dir eher von abraten.

Ah ja, da bist du gerade auf einem Zwischenzustand, weil ich noch lokale Änderungen rumliegen habe. Die Authentication ist ja gerade in Arbeit. Folgendes sollte immer funktionieren: Ich tagge die Repositories immer (beim esp32-brick habe ich es bei den ersten Versionen vergessen, die Tags trage ich die Tage noch nach) mit der entsprechenden Firmware-Version. D.h. wenn du im esp32-brick-Git

git checkout warp-1.1.1

und im warp-Charger git

git checkout v1.1.1

ausführst, sollte der Stand zueinander passen.

Moin Thomas,

Kurz als Überblick: Die WARP-Charger-Firmware ist dreigeteilt in die esp32-lib, die grundlegende Funktionen bietet (und vorkompiliert werden kann), die esp32-brick-Firmware, aus der die WARP-Charger-Firmware einige Module für das Webinterface übernimmt (die aber auch selbst eine eigene Firmware für den Brick ist) und die warp-charger-Firmware selbst, die den ganzen WARP-spezifischen Teil enthält.

Tatsächlich lässt sich die reine ESP32-Brick-Firmware gerade nicht bauen, weil ich Änderungen in esp32-lib gemacht habe, die in die WARP-Firmware mitgezogen habe, aber die ESP32-Firmware noch nicht aktualisiert habe. Das schleift etwas, weil ich die ESP32-Firmware Stand jetzt fast nie direkt baue, wir verkaufen den Brick ja noch nicht einzeln.

Wenn du dich spezifisch mit der Wallbox-Software beschäftigen willst, musst du im esp32-brick nichts kompilieren, sondern es reicht, das warp-charger-Git zu klonen, dann in dessen software-Ordner das esp32-brick-Git zu klonen (oder zu symlinken). Die esp32-lib wird von platformio automatisch runtergeladen.

Grüße,
Erik

Moin,

Die Callback-Registrierung läuft, wie bei den meisten Bricklets zweischrittig:

1. Du musst, wie du das schon gemacht hast, den Bindings mitteilen, dass du am Interrupt-Callback interessiert bist. Dabei findet aber noch keine Kommunikation mit dem Bricklet statt.
2. Danach musst du das Callback auf dem Bricklet aktivieren. Das geht in deinem Fall mit set_interrupt. Wird im Beispiel auch so gemacht.

Teste mal bitte die Version im Anhang. Du kannst damit jetzt Strings als Zahlen übergeben (sogar mit z.b "0xCAFE", "0o777" und "0b1001" hexadezimal, oktal und binär).

Außerdem kannst du den Bindings das Argument "--int64-as-string" mitgeben, dann werden 64-Bit-Zahlen stattdessen als String in das JSON-Objekt eingefügt, damit du immer das JSON parsen kannst (und dann komfortabler damit arbeiten).

tinkerforge_mqtt_bindings_2_0_14_8f0ac4c1.zip

Den ESP32 Brick gibt es, aber wir verkaufen ihn noch nicht. Stand jetzt werden leider alle, die bereits produziert sind, für die Wallboxen gebraucht.

Der normale Weg damit umzugehen ist, dass du die Aufrufe der Brick- und Bricklet-Funktionen in try-catch-Blöcke machst. Damit kannst du dann auf TimeoutException oder andere Fehler reagieren.

In PHP wird leider die Verbindung nicht automatisch wiederhergestellt, wenn sie verloren ging, das musst du also händisch machen. Du kannst dich auf das disconnected-Callback der IPConnection registrieren und dann periodisch connect aufrufen, bis es funktioniert. Die Callback-Doku findest du hier: https://www.tinkerforge.com/de/doc/Software/IPConnection_PHP.html#callbacks

Wenn du eine Verbindung aufgebaut hast, kannst du dann den enumerate-Mechanismus benutzen um die Bricks und Bricklets wiederzufinden und zu konfigurieren. Es reicht wenn du das ganz am Anfang einmal registrierst, dann funktioniert das automagisch. Das ganze wird hier erklärt: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Rugged/Tutorial.html#tutorial-rugged-approach

Ich vermute, dass das "Brick Daemon"-Thing bei dir fehlt. Das kannst du hinzufügen, indem du in der Inbox auf das Plus klickst, dann das Tinkerforge Binding und den Brick Daemon auswählst. In dessen Einstellungen musst du dann die IP der Ethernet Extension eintragen, dann sollte es funktionieren.

Das ist in der Anleitung etwas verklausuliert formuliert mit den Sätzen

Quote

You can then connect the bindings by adding a Brick Daemon thing in openHAB's Paper UI.

Attached devices are automatically put into the inbox after adding the Brick Daemon thing.

Ich setze mir mal auf die TODO-Liste das auf der Dokumentationsseite expliziter zu erklären.

Ah das hatte ich tatsächlich genau falsch herum verstanden.

16 hours ago, cbachmann said:

Könntet ihr nicht einfach im MQTT Binding auch so einen JSON String akzeptieren?

Das sollte gehen. Ich pack es mal mit auf die Liste für das nächste Release.

Du hast vermutlich folgendes Problem: Die Identifier von search_bus sind 64-Bit-Zahlen, die die MQTT-Bindings auch ganz normal behandeln. Node-RED parst das JSON und wandelt dabei die Zahl in einen double um, mit dem Ganzzahlen nur bis 53 Bit korrekt darstellbar sind. Das passiert, weil in Javascript der Zahl-Typ immer double ist (es sei denn man benutzt BigInt, das ist aber recht neu).

Die Lösung dafür ist, Node-RED den Payload nicht parsen zu lassen, sondern händisch auf dem JSON-String zu arbeiten um dir die Zahlen rauszuziehen. Da müsstest du etwas Javascript schreiben und BigInt benutzen.

Damit das in Zukunft einfacher ist, werde ich in die MQTT-Bindings einen Javascript-Kompatibilitätsmodus einbauen, der 64-Bit-Zahlen als Strings ausgibt, die man direkt in BigInt benutzen kann. Das wird aber voraussichtlich erst nächste Woche.

Moin,

Das scheint ein Bug in den MQTT-Bindings zu sein. Funktioniert es mit der angehangenen Version der Bindings?

tinkerforge_mqtt_bindings_2_0_14_030e9ae2.zip

On 2/19/2021 at 7:21 PM, SimRa said:

über welchen Zeitraum wird hier gesprochen?

1 Woche, 1 Monat,.. ? 

Mindestens einen Monat, eher etwas länger. Der aktuelle Schlachtplan ist für die Wallbox (neben 100 kleineren Dingen) eine Zeitschaltung und Lastmanagement über OCPP zu implementieren. Wenn das weg ist und danach nicht neue dringende Featurewünsche auflaufen, kann ich vermutlich Zeit einschieben, die angefallenen aber unfertigen Projekte zu beenden, heißt openHAB- und C/C++-für-Mikrocontroller-Bindings.

Aktuell ist aber die Wallbox das was mit Abstand am höchsten priorisiert wird.

On 2/19/2021 at 7:21 PM, SimRa said:

Seit Openhab3 kann man die Installation auf Openhab2-Kompatibilität stellen. Soweit ich das richrig verstanden habe.

Das klingt interessant, gibt es da Dokumentation zu? Ich habe beim spontanen suchen nichts gefunden.

On 2/19/2021 at 7:21 PM, SimRa said:

Würde das gerne wissen, um zu entscheiden, on ich mir die Mühe machen muss, unnötige zusätzliche Hardware zwischen openhab3 und die Wetterstation einzubinden.

Bevor du da Hardware draufwirfst: Du kannst notfalls den Weg über die (Tinkerforge-)MQTT-Bindings und das (openHAB 3-)MQTT-Binding gehen. Ist nicht ganz so komfortabel wie ein natives Binding, aber immerhin.

On 2/20/2021 at 1:41 PM, Jhonny said:

ist das dann nach Implementierung auch bei der warp smart verfügbar, oder ist man in jedem Fall auf die pro angewiesen?

Die Smart bekommt das auch: Das Lastmanagement wird in jedem Fall darüber laufen, wie viel Strom man dem angeschlossenen Auto erlaubt zu laden, nicht darüber wie viel es tatsächlich zieht. (Sonst müsste man sich ja darauf verlassen, dass die Ladeelektronik nicht spontan das dreifache zieht)

Am besten installierst du die Bindings systemweit mit pip: https://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#von-pypi

Pip solltest du bereits installiert haben, wenn du ein halbwegs aktuelles Python hast (mindestens 2.79 oder 3.4).

Wenn du nochmal testest, dann am Besten mit der Firmware 1.1.0, macht ja keinen Sinn alte Bugs zu jagen. Ich hätte aber auch erwartet, dass es mit der 1.0.1 funktioniert. Falls es mit der 1.1.0 auch nicht tut, häng mal Debug-Report und Event-Log an, vom Debug-Report am besten einen bevor das Auto dransteckt und einen während das Auto dransteckt aber nicht von alleine anfängt zu laden.

Sehr gut, danke! Dann ist der Brick Viewer jetzt etwas akkufreundlicher.

Ja, das Servo Bricklet 2.0 ist recht frisch. Du brauchst dafür die Python-Bindings 2.1.28, die wir am 15.01. diesen Jahres veröffentlicht haben.