rtrbt

Kurze Bestandsaufnahme: Damit meinst du, dass die Wallbox auf der das Lastmanagement läuft, die zweite Wallbox nicht mehr erreichen konnte. An welcher von beiden hattest du das Auto angeschlossen? (Das Lastmanagement schaltet sicherheitshalber alle Boxen ab, wenn eine nicht erreicht werden kann) Warst du auch auf dem Webinterface der anderen Box? War da etwas suspekt, hast du eventuell Ereignis-Logs? Das heißt, dass der Ladecontroller selbst noch lebt und nur der ESP32 auf dem das Webinterface läuft Probleme macht (oder die Kommunikation zwischen den beiden oder zwischen den Wallboxen) Dann können wir schonmal Netzwerkprobleme ausschließen (es sei denn die Wallbox selbst hat nicht bemerkt dass sie nicht mehr im WLAN ist o.Ä.) Mir ist unklar, was du damit meinst. Hast du es mehr als einmal geschafft, dass das Lastmanagement blockiert und es ist egal welche Box du neustartest, damit es wieder funktioniert? Hoffentlich nicht ;) Ich halte ein reines Speicherleck für unwahrscheinlich, da würde es bei dir nicht > einen Monat problemlos laufen, soviel RAM hat der ESP nicht. Falls du das Problem nochmal erzeugen kannst würde mich folgendes interessieren: Kannst du das Webinterface beider Wallboxen noch erreichen? Falls ja: Ein Ereignis-Log und einen Debug-Report beider Wallboxen (im Debug-Report ist u.A. auch der aktuelle Zustand des Lastmanagers) Wie lange bleibt der Zustand so? Reicht es eine Box neuzustarten damit es wieder funktioniert? Wir haben hier einen Lastmanagement-Verbund aus vier Wallboxen, der lief aber meines Wissens noch nie länger als zwei bis drei Wochen, weil man immer irgendwelche Dinge testet. Ich bin aber nächste und übernächste Woche im Urlaub und habe meinem Kollegen mal bescheid gesagt, dass er aufpassen soll, dass niemand die Boxen neustartet. Ich habe mir die aktuelle RAM-Auslastung der vier Boxen notiert, für den Fall, dass es wirklich ein Speicherleck ist. Eventuell wissen wir dann Anfang Oktober mehr.

Moin Thomas, Teste bitte mal die Lastmanagement-Beta. Ich habe ein paar Fälle gehabt, bei denen sich der (alte) Webserver und der MQTT-Client auf den Füßen standen. MIt dem neuen Webserver sind die Probleme dann verschwunden. Achtung: Falls du den Login des Webinterfaces aktiviert hast, musst du u.U. deinen Browser nach dem Update neu starten, die Beta unterstützt den Loginprozess nicht.

Die Getter zu benutzen ist die einfachste Variante, du könntest aber alternativ auch die Callback-Frequenz runterdrehen auf etwas, dass du auf dem ESP verarbeiten kannst. Das hätte den Vorteil, dass weniger Traffic erzeugt wird. (Der Unterschied ist aber im Vergleich zu Stacks über USB nicht so stark). Da die Temperatur typischerweise eher träge ist solltest du mit z.B. 50 ms Callback-Interval noch gut hinkommen.

Aus Sicht der Wallbox sind Schlüsselschalter, Taster und dein Relais alle identisch. Da der Taster einen Ladeabbruch auslöst, beginnt die Wallbox nicht wieder mit dem Laden, bis du das Auto abgezogen und wieder angesteckt hast. Das Auto ist nachdem du den Taster loslässt ja noch angeschlossen. Die Wallbox ignoriert dann Auto-Start bis auf irgendeine Weise (dazu gleich mehr) eine Ladung beginnt oder du das Auto abziehst und wieder ansteckst. Du kannst das auch im Webinterface beobachten: Auf der Ladecontroller-Unterseite springt die Ladefreigabe von "Automatisch" auf "Manuell", wenn du den Taster drückst und loslässt. Anstatt dass du das Auto abziehst, kannst du auch über das Webinterface eine Ladung starten: Sobald die Ladefreigabe auf manuell steht und das Auto noch angeschlossen ist, solltest du auf der Status-Seite "Start" drücken können. Wenn du das automatisieren willst (z.b. über die selbe Steuerung die dein Relais schaltet?) kannst du die HTTP- oder MQTT-API verwenden und evse/start_charging aufrufen.

You are using the STM32F0-HAL? It looks like the HAL only initializes the SPI peripherals that are configured to be used. So if you only use SPI0_INSTANCE or SPI1_INSTANCE in your port configuration, the other one should be left unmodified.

Das Industrial PTC Bricklet ist neuer als die letzte Bindings-Beta. Wirf mal die beiden Dateien im Anhang in den bindings-Ordner. bricklet_industrial_ptc.c bricklet_industrial_ptc.h

So wird es funktionieren, ja. Die Tag-IDs bekommst du auch per MQTT, aber (noch) nicht die Kopplung welches Tag gerade jetzt den Ladestart ausgelöst hat. Das geht auch, es wird (voraussichtlich ;) ) die API nfc/seen_tags geben, wo Tag-Typ, -ID und die Zeit wann es zuletzt erkannt wurde, enthalten sind.

Moin Stefan, Das ist kein Problem, wundert mich warum ich das nicht schon gemacht hatte. Ich setze es mal auf die TODO-Liste. Habe gerade keine funktionsfähige Umgebung um das Binding zu bauen, sonst hätte ich das gleich gemacht.

Bindings: Rust 2.0.19 Fix compilation issues caused by yanked dependency Add set/get_display_driver functions and DISPLAY_DRIVER constants to E-Paper 296x128 Bricklet API Add simple_get_tag_id function and NFC_BRICKLET_MODE_SIMPLE constant to NFC Bricklet API Download: Rust

Bindings: Rust 2.0.19 Kompilierfehler durch zurückgezogene Abhängigkeit behoben set/get_display_driver-Funktionen und DISPLAY_DRIVER-Konstante zu E-Paper 296x128 Bricklet API hinzugefügt simple_get_tag_id-Funktion und NFC_BRICKLET_MODE_SIMPLE-Konstante zu NFC Bricklet API hinzugefügt. Download: Rust

Moin Niels, Mit etwas Bastelei sollte das gehen. Habe spontan das hier gefunden: https://community.home-assistant.io/t/multi-sensor-using-same-mqtt-topic/172552/3 Der Teil mit dem "data demultiplexer" sieht nützlich aus. In diesem Fall wäre es sinnvoller, aber so funktionieren die Bindings nicht. Die Bindings mappen 1:1 auf die Python-API und in der sind die Sensor-IDs ein Rückgabewert. Das ist immer das Problem bei "generischen" MQTT-Bindings, wenn es ein reines HA-Binding wäre, sähe das anders aus. Hast du die Bindings auf dem Pi als Debian-Paket installiert? Falls ja kannst du deine cmdline-Datei nach /etc/tinkerforge_mqtt.cmdline packen bzw. mit der Datei zusammenlegen. Falls du die Bindings von Hand heruntergeladen hast kannst du die .service-Datei aus dem Zip bearbeiten und --cmdline-file daemon-cmd-args einfügen.

Hm kaputte Jumperkabel hatte ich bei der Binding-Entwicklung auch. (Mein Aufbau sah übrigens sehr ähnlich aus ;) ) Wegen der Robustheit solltest du die Ports, die du nicht benutzt wieder in die Konfiguration aufnehmen, zumindest wenn du Bricklets angeschlossen hast: Das HAT hat Trennerchips, die sicherstellen, dass SPI nur an das selektierte Bricklet geht. Wenn du dann die Enable-Leitung der Chips floating lässt (das ist einfach das Chip-Select-Signal) könnten sich komische Effekte ergeben.

Außer dem Zähler brauchst du noch die entsprechenden Kabel. Statt dem Klemmenblock in der Smart kann dann der Zähler eingebaut werden. Wir planen in nächster Zeit die ganzen internen Kabel usw. als Ersatzteile zu verkaufen. Siehe hier:

Mit genau dem Commit, ja. Jetzt verstehe ich aber die Verwirrung: getDeviceInfo() ruft tf_hal_get_device_info auf, das erzeugt aber keine Kommunikation, sondern fragt nur die Informationen ab, die der HAL ganz am Anfang gesammelt hat. Was in tf_hal_create bzw. tf_hal_common_prepare (was von _create aufgerufen wird) passiert, ist dass der HAL an allen verfügbaren Ports abfragt, welche Devices angeschlossen sind. Mit tf_hal_get_device_info kannst du die abgefragten Daten dann auslesen. Wenn du permanent Kommunikation auf allen Ports erzeugen willst, kannst du entweder tf_hal_callback_tick verwenden, dann ist es aber nur unidirektional, weil die Bricklets vermutlich nichts antworten werden (es sei denn du hast eins der Bricklets mit nicht deaktivierbaren Callbacks die auslösen z.B. ein RGB LED Button den du immer mal drückst) oder du baust dir etwas in die Richtung: TF_Unknown unknown; for(int i = 0; i < port_count; ++i) { tf_unknown_create(&unknown, "1", hal, (uint8_t)i, 0); int rc = tf_unknown_get_identity(&unknown, nullptr, nullptr, nullptr, nullptr, nullptr, nullptr); tf_unknown_destroy(&unknown); } (ungefähr geklaut aus tf_hal_common_prepare) Das gute am Unknown Bricklet ist, dass es einen Konstruktor hat, bei dem du explizit den Port angeben kannst. UID "1" ist Broadcast. Nein die includes brauchst du nur, wenn du mit dem Bricklet kommunizieren willst, der HAL verwendet intern nur bricklet_unknown und includet das selbst. Mit PlatformIO: pio run -e esp32-poe -t upload -t monitor Das benutze ich sowieso für die Wallbox-Firmware (falls du spionieren willst: https://github.com/Tinkerforge/warp-charger/tree/master/software) Wenn das HAT bei dir aufschlägt, funktioniert die Kommunikation prinzipiell. Siehst du auf der seriellen Konsole dann auch folgendes? Found device XYZ of type 112 at port E

Ich habe den Code so wie du ihn hast mal mit einem NodeMCU getestet. Musste dafür nur im HAL den MISO_PIN von 16 auf 12 setzen. Damit funktioniert es aber. Die Bilder sind die Anfrage der Bindings, mit dem sie abfragen was an dem Port angeschlossen ist und die Antwort des One Wire Bricklets. Wenn das funktioniert müsstest du die Ausgabe auf der seriellen Konsole sehen: Hello World! Found device GGU of type 2123 at port A Get Device Info: {"devices": [ {"UID":"GGU", "DID":2123, "port":"A"}]} So wie dein Code da steht, gibt es nur kurz Kommunikation, wenn du die Bindings startest, du könntest aber in die Loop noch tf_hal_callback_tick aufrufen, dann prüfen die Bindings permanent, ob die Bricklets Daten schicken wollen. Der Bus sollte mit 1,4 MHz laufen. Alles bis 2 MHz verstehen die Bricklets. Edit: Bilder als Anhang, damit man sie auch lesen kann. Edit2: Das Forum wehrt sich. Klickst du hier: https://imgur.com/a/6mQ0OYF

Liest du SPI zwischen dem ESP und dem HAT oder zwischen HAT und Bricklet? Noch eine Sache die mir auffällt: Dein Beispiel schreibt Daten per SPI an einen Slave, vom Logic-Analyzer-Bild her ist das Pinmapping D0 MISO D1 MOSI D2 CLK D3 CS Jetzt sehe ich da aber Daten auf MISO, nicht auf MOSI. Das scheint falsch herum zu sein. Oder hast du das nur in Sigrok falsch zugeordnet?

Die Verkabelung sieht soweit ich das erkennen konnte richtig aus. Falls du einen Saleae Logic Analyzer hast kannst du dir unseren HLA ansehen: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/Saleae_High_Level_Analyzer.html Ich habe nochmal in deinen HAL gesehen: Es fehlt auf jeden Fall die Zeile hal->hspi = SPIClass(HSPI); vor hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN); Ich bin mir gerade nicht mehr sicher, ob der SPIClass-Konstruktor außer dem Pin-Mapping noch mehr tut, eventuell war die Zeile wichtig ;)

openHAB kann sich auch zu WiFi Extensions verbinden. D.h. openHAB3 <--> openHAB2 <--> Stack mit Master + Wifi Extension funktioniert auch ohne RED Brick, wenn du die openHAB2-Instanz auf dem selben Rechner laufen lässt wie die openHAB3-Instanz.

Da der Wunsch nach der NFC-Aufrüstung schon mehrfach kam: Ich will nichts versprechen, aber theoretisch sollte NFC mit Einschränkungen auch mit WARP 1 funktionieren. Was nicht gehen wird ist der Ladestop per Tag, weil der Knopf bei WARP 1 nicht deaktiviert werden kann.

Die Doku zu den Remote-openHAB-Binding sagt zumindest, dass es genau für solche Fälle da ist. Ich habe aber keine Ahnung wie viel Aufwand es ist das Binding einzurichten. Im RED-Brick-Image ist aber vermutlich auch eine ältere openHAB-Version, die müsstest du von Hand aktualisieren. Eventuell wäre folgendes einfacher: Die Tinkerforge-Bindings selbst können sich zu einem Brick Daemon verbinden, der nicht lokal läuft, sondern über das Netzwerk. D.h. du könntest da, wo OH3 bei dir läuft, OH2 daneben installieren, dich mit dem Binding zum RED-Brick verbinden (auf dem dann nur der Brick Daemon läuft) und es sollte funktionieren. Ich würde auch erwarten, dass die Performance dann besser ist: Der RED-Brick ist immerhin nur so schnell wie ein Pi 1, openHAB läuft auf dem Brick eher gemächlich.

Moin Stefan, Du meinst die Pins die nicht Chip-Select sind? Die musst du im HAL selbst umbiegen, ja. Du kannst dir in hal_arduino_esp32.cpp in folgendem Block: if (uses_hspi) { hal->hspi = SPIClass(HSPI); hal->hspi.begin(); } if (uses_vspi) { hal->vspi = SPIClass(VSPI); hal->vspi.begin(); } die Pins in den Begin-Aufruf reinpatchen, z.B. so: hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN); wenn du nur HSPI oder VSPI umbiegst, musst du dann in deiner ports.h alle Ports auf das entsprechende SPI setzen. Das HAT Zero (übrigens auch das große HAT) sind im Endeffekt eine Schaltung + ein Bricklet. Es gibt einen Select-Pin am HAT-Stecker mit dem du mit dem Microcontroller auf dem HAT reden kannst (B-CS4 im Schematic, das ist Pin 22 bzw. GPIO 25 am Pi). Wenn du diesen Pin als normalen Port in deine ports.h packst, funktioniert das alles automagisch, du kannst dann also über tf_hal_get_device_info u.A. die UID abfragen. Weniger zur Codestruktur und mehr ein allgemeiner Hinweis: Du kannst dir die esp32-lib mal ansehen, da sind noch ein paar hilfreiche Konstrukte enthalten, wenn du z.B. Devices nach der Device-(Typ)-ID suchen willst oder Firmwares flashen o.Ä.. Die Lib ist aber darauf ausgelegt in einer Firmware wie der für unsere Wallbox eingesetzt zu werden, da musst du eventuell Zeug rauspatchen für Konstrukte die du nicht hast. Grüße, Erik

Bei WARP 1 reicht es das automatische Laden abzuschalten. Der Taster kann das Laden nur abbrechen, nicht starten.

Moin, Das ist leider garnicht so einfach: Die Wallbox weiß Stand jetzt nicht, wie spät es ist. Für ein paar der geplanten Features müssen wir NTP zur Zeitsynchronisierung implementieren, aber das ist noch Zukunftsmusik. Deshalb kann ich erstmal nicht versprechen, dass es den Rückstellzeitpunkt so geben wird, geschweige denn wann. Ich behalte die Idee aber mal im Hinterkopf und komme darauf zurück, falls es sich ergibt.

Hi, This is indeed possible with the C/C++ bindings for microcontrollers. However those are not finished yet. You can find the latest beta here : Documentation is available here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_uC.html and here for the Voltage/Current Bricklet 2.0: https://www.tinkerforge.com/en/doc/Software/Bricklets/VoltageCurrentV2_Bricklet_uC.html Links to the Bricklet-specific documentation are not generated yet, however you can use the documentation for the "normal" C bindings and then add a u before the last C like this: https://www.tinkerforge.com/en/doc/Software/Bricklets/AirQuality_Bricklet_C.html becomes https://www.tinkerforge.com/en/doc/Software/Bricklets/AirQuality_Bricklet_uC.html

Damit ich das richtig verstehe: Du benutzt bereits die Python-Bindings für unsere Hardware, willst jetzt aber die MQTT-Bindings benutzen? Im Endeffekt funktioniert das wie folgt: Die MQTT-Bindings machen nichts anderes als auf MQTT-Nachrichten zu warten und dann selbst die Python-Bindings aufzurufen. Deshalb müssen die MQTT-Bindings permanent als Programm laufen. Wenn du dann z.B. mit paho-mqtt folgendes machst: mqttc.publish("tinkerforge/request/lcd_128x64_bricklet/AbC/get_identity", "") legen die MQTT-Bindings intern eine Instanz von BrickletLCD128x64 an und rufen darauf .get_identity() auf. Das Ergebnis bekommst du auf das Topic tinkerforge/response/lcd_128x64_bricklet/AbC/get_identity zurückgegeben. Die Topics entsprechen 1:1 den Python-Bindings-Funktionsaufrufen.