rtrbt

Hi, The new firmwares only fix unrelated problems, for example 2.1.5 fixes the LED issue you've found. Yeah, this does not look perfect. Are the WiFi problems also happening with the other extension? If yes, I would assume that they are not caused by bad soldering. Some questions to find out on which level this is broken: If you configure an extension to the Client + AP mode the status LED should be blinking continously. When the stack becomes unresponsive, does the LED still blink? When a stack becomes unresponsive, and you plug in a USB cable, can you still reach the stack on localhost via USB? Did you only postpone TFP connections or also pings etc? Another idea: Does this also happen if you don't connect the stack to your network at all, but instead only use its access point?

Moin, Stand jetzt funktioniert das in der Tat nicht. Androids Host-based Card Emulation API gibt leider vor, dass die IDs rotieren, siehe z.B. hier: https://stackoverflow.com/questions/19764476/host-based-card-emulation-with-fixed-card-id Eventuell können wir in der Zukunft einen Work-Around in die Wallbox-Firmware einbauen, aber das kann und will ich erstmal nicht versprechen. Damit das nicht in Vergessenheit gerät, habe ich ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/90

I'm currently trying to reproduce this. So far the WiFi connection still works. Is this just some dirt or a bit of solder? Can you scrape it away? (Just to make sure this does not short-circuit anything)

Flashing Master Bricks works with the (non-M1) Macbook, that we have here. We've ordered an M1 Macbook (sooner or later we would have to test some things with one anyway), but this will take a while.

You can use a GPIO connector like this one: https://www.berrybase.de/en/new/gpio-edge-erweiterung-gpio-adapter-f-252-r-raspberry-pi?c=2413 and plug it between the Pi and the HAT. In the HAT Bricks schematic you can see with GPIOs are not used by the HAT: https://raw.githubusercontent.com/Tinkerforge/hat-brick/master/hardware/hat-schematic.pdf (the yellow rectangle to the right is the GPIO connector). To reference the numbers to the physical position of a pin, use for example this: https://i0.wp.com/maxembedded.com/wp-content/uploads/2014/07/Raspberry-Pi-GPIO-Layout-Model-B-Plus.png

Ein Weihnachtswunder: https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip Das wird voraussichtlich die letzte Beta, bzw. falls keine kritischen Bugs darin sind ist es die "fertige" Version der openHAB-2-Bindings. Die Liste von oben ist soweit abgearbeitet. Außerdem neu ist Support für die seit der letzen Beta erschienenen Bricklets: - Industrial Dual AC Relay - Industrial PTC - IMU 3.0 sowie ein deutlich einfacherer Modus für das NFC-Bricklet (der aber nur Tag-IDs liest). Für die neuen Motor-Treiber-Bricklets gibt es keinen Support, das war zeitlich nicht drin und die Verwendung wäre ähnlich unkomfortabel wie die der alten Motor-Treiber gewesen. Wichtig: In der Zip ist eine noch nicht veröffentlichte Version der Java-Bindings enthalten. Die ist notwendig um die teilweise neue API zu verwenden. Bei einem Update von einer älteren Bindingsversion bitte die 2.1.26er Jar löschen. Mit der aktuellen Version und openHAB 2.5.9 scheint es auch zu funktionieren, die Bricks und Bricklets in einer .things-Datei zu definieren. Hier ein Beispiel: Bridge tinkerforge:brickd:laptop [host="192.168.178.147"] Thing tinkerforge:brickletmultitouch:zwL "Multitouch" (tinkerforge:brickd:laptop) [uid="zwL", proximityEnabled=false]

This seems to be the problem here. If the extension is configured only as client, the status LED stops blinking if the extension is connected. The code is event driven, so when you disable and enable the status LED, what really happens is that the connection between the WiFi events and the LED state is severed or (re)connected. The issue is now, that no event from the WiFi code is generated if the extension is already connected and when you re-enable the LED the state is never changed. Interestingly, when disabling the LED, it is then shut off manually. We've added the same work-around for the enable function (first toggle the LED on, then reconnect it to the WiFi events). This is not perfect, because if the WiFi state would cause the LED to stay off and you disable and re-enable the LED it will stay on, but I think this behaviour better fits the user expectations better, as the LED should light up when you call enable... in any case. This is another issue. Do you have any more information about this? But the LED problem should indeed be unrelated.

Irgendetwas in die Richtung haben wir geplant, es gab aber noch kein Issue. Jetzt schon: https://github.com/Tinkerforge/esp32-firmware/issues/88

Stimmt, hatte ein Zaunpfahlproblem. Noch ein Grund mehr auf der Ladecontroller-Seite nachzusehen.

Das ist ein Fehler mit dem DC-Schutzmodul. Du kannst die ganzen Fehlerzustände übrigens schöner aufbereitet auf der Ladecontroller-Unterseite sehen.

Hi, How is your extension configured? The methods work for me. Does the attached script print the same messages with your extension? (Remember to change the UID ;) ) $ ruby test.rb LED true Press key to disable LED LED false Press key to enable LED LED true Press key to exit test.rb

Ah sehr gut, das Mosquitto local-only-Problem wäre was ich spontan geraten hätte. Deshalb die Frage nach Broker und Version. Ich füge das mal der FAQ hinzu. https://github.com/Tinkerforge/esp32-firmware/issues/85 Man beachte wann ich das Issue angelegt habe, vor allem in Relation zu meinem Post weiter oben ;)

Über USB kann der Brick in der Tat nur geflasht werden, er ist im Setup-Tab des Brick Viewer nicht als Brick sichtbar und die Bricklets tauchen auch nicht auf. Das ist soweit erwartet. Er sollte aber trotzdem unter Updates / Flashing -> Brick auftauchen, wie @poohnet schon schreibt. Update mal deine Firmware, bzw baue sie gegen den aktuellen Stand des Repos neu. Das Problem mit den fehlenden Bricklets sollte gefixt sein.

Das ist soweit korrekt, die Wallboxen müssen sich über ein Netzwerk erreichen können, damit Lastmanagement funktioniert. Du kannst aber jede Wallbox in das entsprechende WLAN einbinden und dann zwischen den Wallboxen eine LAN-Verbindung ziehen (bei mehr als zwei über einen Switch). Dann musst du für das LAN-Interface jeweils statische IPs konfigurieren, oder einen Router mit dazuhängen ,der IPs per DHCP verteilt, das ist dir überlassen. Ich habe das gerade erfolgreich mit folgendem Aufbau getestet: Fritzbox A <--WLAN A--> Wallbox A <--LAN-Kabel--> Wallbox B <--WLAN B-->Fritzbox B Du musst dann aber darauf achten, dass das Netz zwischen den Wallboxen einen anderen IP-Bereich benutzt als die beiden WLANs.

Das Problem ist vermutlich das hier: Der Ladecontroller geht in einen Fehlerzustand, weil vor dem Schütz keine Spannung ist. Da du schreibst, dass die Box am Strom hängt: Ist sie eventuell falsch herum angeschlossen? Also Neutralleiter und L1 vertauscht? Ich habe bei mir einen Wallboxprototypem mit Schukostecker auf dem Tisch liegen zur Firmware-Entwicklung, wenn ich bei dem den Stecker verdreht in die Steckdose stecke, passiert genau das. Unabhängig davon ist die Prüfung, dass ein Update nur erlaubt ist, wenn der Fahrzeugzustand "kein Fahrzeug angeschlossen" ist, zu aggressiv. Ich entschärfe das mal, damit Updates auch erlaubt sind, wenn die Wallbox in einem Fehlerzustand ist.

Moin, @stomb@rifmetroid Welchen MQTT-Broker in welcher Version benutzt ihr? Schickt mir außerdem bitte beide einen Debug-Report. @floho Ging das Ereignis-Log so weiter oder hörte es danach auf? Aufgrund der Zeiten sehe ich bei dir folgendes: MQTT hat die Verbindung verloren (bei 232020682), wohlgemerkt durch ein normales schließen der Verbindung, nicht durch Netzwerkprobleme ö.Ä. Dann hat es 8 Versuche gebraucht, die Verbindung wieder aufzubauen (bis 232151062), das entspricht 130 Sekunden (Die Timestamps sind in Millisekunden). Die Verbindung bestand dann 3 Stunden und 40 Minuten (bis 245351725), konnte aber danach wieder nach einer Minute (245412100) wieder aufgebaut werden. Wenn das Log danach nicht so weiter ging, bzw. wieder größere Sprünge in den Zeiten waren sind das eventuell Netzwerkeffekte. Ich habe z.B. schon einmal beobachtet, dass bei einer bestimmten Fritzbox Nachts kurz alle WLAN-Verbindungne getrennt werden. Da hatte man dann einmal am Tag einen MQTT-Reconnect im Log. Wie sind die Wallbox und der Rechner auf dem dein Broker läuft an dein Netz angeschlossen? Häng bitte auch einmal einen Debug-Report an, da steht u.A. die Uptime drin, anhand der wir sehen können, wie lange das her ist.

Gut zu wissen, danke!

Kurzes Update: Ich habe in das Lastmanagement testweise eingebaut, dass wenn Strom übrig ist, dieser an Wallboxen zugeteilt wird, die bereits einmal geladen haben ohne dass danach das Fahrzeug abgezogen wurde. Kannst du bitte kurz mit der angehangenen Firmware testen ob nachdem du deinen Tesla normal auf 70% geladen hast (und nicht abgezogen!) der Ladestart über die App funktioniert bzw die Heizung über Wallbox-Strom? Bis auf diese Änderung ist die Firmware identisch zu 1.1.1. Edit: Veraltete Firmware entfernt.

Das klingt gut! Nur damit ich das richtig verstehe: Das war einer der RJ45-Stecker an deinem LAN-Kabel oder der Stecker in der Wallbox?

Firmware: WARP1 1.3.2 Kritisches Stromzähler-Kommunikationsproblem behoben Leere Client-IDs für MQTT verboten Download: WARP1 1.3.2

Firmware: WARP1 1.3.1 Unnötige Logmeldungen des Logins entfernt Übersetzungen überarbeitet Konfigurationspartition auf robusteres Dateisystem umgestellt Login-Probleme nach Update von Firmwares älter als 1.3.0 behoben Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert Bug der zur Anzeige eines leeren Webinterfaces führt behoben Recovery-Seite hinzugefügt Warnung vor Downgrades hinzugefügt Logmeldungen über mehr Netzwerkereignisse hinzugefügt Download: WARP1 1.3.1

Firmware: WARP2 1.1.1 Unnötige Logmeldungen des Logins entfernt Übersetzungen überarbeitet Konfigurationspartition auf robusteres Dateisystem umgestellt Modalfenster für NFC-Karten und gesteuerte Wallboxen verbessert Bug der zur Anzeige eines leeren Webinterfaces führt behoben Watchdog des verfügbaren Lastmanagementstroms zurückgesetzt wenn dieser über die API gesetzt wird. Recovery-Seite hinzugefügt Warnung vor Downgrades hinzugefügt Logmeldungen über mehr Netzwerkereignisse hinzugefügt Detektion aktiver und verbundener Phasen verbessert (durch Update auf Ladecontroller-Firmware 2.0.6) Detektion von Fahrzeugen verbessert, falls beim Start ein Fehler vorliegt (durch Update auf Ladecontroller-Firmware 2.0.6) Download: WARP2 1.1.1

Bisher kenne ich nur den einen anderen Kunden mit LAN-Problemen. Bei ihm ist es auch eine Fritzbox (7362SL) . Auf der anderen Seite haben wir aber extrem viele Kunden, Kollegen und auch die Wallboxen hier in der Firma an Fritzboxen, bei denen die LAN-Verbindung anstandslos funktioniert. In Summe bin ich davon so verwirrt wie du. Das hat sich zerschlagen, statische IPs haben auch nicht geholfen. Als letzte Idee: Hast du getestet? Wenn das nicht hilft wäre der nächste Schritt vermutlich den ESP Ethernet Brick auszutauschen, der in der Wallbox verbaut ist. Als ganz verzweifelte Idee: Besteht die Möglichkeit, dass du ein anderes LAN-Kabel ausprobierst?

Ich habe kurz mit dem Samsung-Handy von einem Kollegen getestet: Scheinbar ist die Websocket-Unterstützung des Samsung Browsers kaputt bzw. unterstützt NUR wss. Ich fürchte, da müsstest du mal den Browser wechseln. Mit Chrome und Firefox funktionierts. Eigentlich sollte sofort wenn du ein LAN-Kabel ansteckst die Verbindung aufgebaut werden. Bei dem anderen Kunden mit dem selben Problem sieht es derzeit aber tatsächlich nach einem DHCP-Problem mit der Fritzbox aus. Ich habe hier ein Testscript laufen, falls ich damit etwas rausfinde melde ich mich nochmal.

Mit der neuen Firmware schon. Unter http://10.0.0.1/recovery gibt es einen Button dafür. Du musst nur erst RESET in die Textbox davor schreiben, damit man das nicht ausversehen auslöst: Dass das Webinterface nicht sinnvoll angezeigt wird ist suspekt. Was für einen Browser benutzt du auf deinem Handy?