photron

Sorry, there was a bug in this call. Please try the attached version. tinkerforge_shell_bindings_2_1_33_beta1.zip

Firmware 1.1.2 ist über 1,5 Jahre alt. Wo hast du die als aktuelle Firmware gefunden? Oder hast du die Firmware aktualisiert als die Wallbox installiert wurde? Die aktuelle Firmware findest du immer hier: https://www.warp-charger.com/warp2.html#firmware

EVCC spricht mit der Wallbox über MQTT. Dafür müssen sich die Wallbox und EVCC zum MQTT Broker verbinden. EVCC verbindet sich nicht direkt mit der Wallbox, daher muss du in EVCC die Adresse des MQTT Brokers (dem Raspberry Pi in deinem Fall) angeben und nicht die Adresse der Wallbox.

Das Weitergeben geht weiterhin (dann offiziel), nur die API wird sich ändern. Die Umstellung wird in den nächsten Wiochen kommen. Die ganze Umstellung der Zähler API hat das Ziel meherer Zähler gleichzeitg zu unterstützen und es besser zu ermöglichen bereits vorhandene Zähler einfacher anbinden zu können.

https://tff-forum.de/t/charging-cable-release-tesla-taste/33270 Wenn der Schaltplan da stimmt, dann läuft die Entriegelung über den PP/PE Widerstand. PP ist aber die einzige Leitung die nicht durch das Kabel zur Wallbox geht. Sondern PP ist lokal mit PE im Stecker über einen Widerstand verbunden, der die Stromfestigkeit des Kabels codiert.

Firmware: WARP Energy Manager 1.0.7 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement 64k-Spitze in der Energiebilanz beim Neustart einer kontrollierten Wallbox beseitigt Y-Achsen Beschreibung zum Energiebilanz- und Stromzähler-Graphen hinzugefügt Identische Legendeneinträge im Energiebilanz-Graphen zusammengefasst Größenberechnung des Energiebilanz-Graphen repariert Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt Lastmanagement auf tabellarische Darstellung umgestellt Verwendung von Platzhaltern in Auswahlfeldern verbessert Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Aktualisierung des last_value_change Wertes im API-Meter repariert Download: WARP Energy Manager 1.0.7

Firmware: WARP2 2.1.4 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Y-Achsen Beschreibung zum Stromzähler-Graphen hinzugefügt Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt NFC-Tag-Injection-API repariert im Falle, dass ein bereits bekannter Tag injectet wurde Überflüssigen Freigabe-Knopf für den globalen Ladestromslot entfernt Verwendung von Platzhaltern in Auswahlfeldern verbessert LED blinkt nicht mehr fälschlicherweise bei deaktivierter Benutzerfreigabe Verhalten bei zu schnellem OCPP-Verbindungsverlust verbessert Lastmanagement, NFC und Benutzerverwaltung auf tabellarische Darstellung umgestellt Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Inkonsistenzen zwischen SDM630 und SDM72 V2 im OCPP Modul behoben Aktualisierung des last_value_change Wertes im API-Meter repariert DC-Fehlerstromprüfung wird nur noch bei geschlossenem Schütz durchgeführt (durch Update auf Ladecontroller-Firmware 2.1.6) Boost-Modus nach Start repariert (durch Update auf Ladecontroller-Firmware 2.1.14) Schütz bleibt mindestens 30 Sekunden lang nach Verlassen von Zustand D ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.14) Schütz bleibt mindestens 5 Sekunden lang nach Ende des Ladevorgangs ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.14) Download: WARP2 2.1.4

Firmware: WARP 2.1.4 Fehlende Messung der Phasenspannungen resultieren nicht mehr in zu niedrigen Ladeströmen im Lastmanagement Potentiellen Deadlock beim Aufruf von API-Befehlen beseitigt Y-Achsen Beschreibung zum Stromzähler-Graphen hinzugefügt Laden der RTC-Zeit an Sonntagen repariert Erstellungszeit der Firmware besser lesbar gemacht Behoben, dass Zeit- und Energielimits weitere Ladevorgänge blockieren konnten Subnetzmaske zum WLAN- und Netzwerk-Zustand hinzugefügt Auswahl der vollen Subnetzmaske (/0 bis /32) für WireGuard erlaubt Abweichung in der Serialisierung zwischen current_charge und last_charges beseitigt NFC-Tag-Injection-API repariert im Falle, dass ein bereits bekannter Tag injectet wurde Überflüssigen Freigabe-Knopf für den globalen Ladestromslot entfernt Verwendung von Platzhaltern in Auswahlfeldern verbessert LED blinkt nicht mehr fälschlicherweise bei deaktivierter Benutzerfreigabe Lastmanagement, NFC und Benutzerverwaltung auf tabellarische Darstellung umgestellt Payloads für Recovery-API-Aufruf repariert Fehleranzeige bei fehlender Auswahl einer Subnetzmaske repariert Aktualisierung des last_value_change Wertes im API-Meter repariert Boost-Modus nach Start repariert (durch Update auf Ladecontroller-Firmware 2.1.6) ID.3-Modus auf Zustandsübergang von C nach A ausgeweitet (durch Update auf Ladecontroller-Firmware 2.1.6) Schütz bleibt mindestens 30 Sekunden lang nach Verlassen von Zustand D ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.6) Schütz bleibt mindestens 5 Sekunden lang nach Ende des Ladevorgangs ausgeschaltet (durch Update auf Ladecontroller-Firmware 2.1.6) Download: WARP 2.1.4

Diesen Peak siehst du nur auf der Energiebilanzseite des Energy Managers? Aber nicht auf der Stromzählerseite der Wallbox? Welche Softwareversioen (WEM und WARP1) laufen da?

Hallo, EVCC kommuniziert dafür mit der Cloud des Autoherstellers. Das hat also so erstmal nichts direkt mit dem WARP Charger zu tun. Ich vermute man wird dir im EVCC Forum besser mit diesem Problem weiterhelfen können: https://github.com/evcc-io/evcc/discussions

Das USB CAN Gerät hat ja keinen Masse/GND-Kemme, das kanst du also nicht anschließen. Mir ist unklar die wie 120Ohm-Klemme zu verstehen ist. Leider schweigt sich die Anleitung aus. Muss da ein 120Ohm Widerstand angeschlossen werden, oder ist dort ein 120Ohm Widerstand innen drin? Hast du CANL an CANL angeschlossen und CANH an CANH? Oder hast du das vertauscht? Entferne mal die beiden kurzen Kabel, die du zwischen CANL/H und 120Ohm R+/- geschraubt hast. Falls das nicht hilft, stelle mal die Terminurung auf dem CAN Bricklet 2.0 auf Off. Man kann auch zu viel terminieren.

Please try the attched brickv version. brickv_macos_2_4_25_snapshot_150aa4c.dmg

Sorry, this is a bug in the data logger on macOS. I will provide you a fixed version for testing on monday.

How did you conect the sensor to the Bricklet? You have to connect it to the pin header which expects 3.3V TTL signals. You cannot connect it to the D-Sub 9 connector nor the terminal block, both expect RS232 voltage levels. I think you also need to power the sensor with 3.3V to make it output 3.3V TTL signals.

Try replacing this test = ''.join(data) with this test = [hex(ord(x)) for x in data] This will give you a list of hex numbers.

Ist dort bereits ein WLAN Netzwerk vorhanden, das du nutzen kannst? Wenn ja, dann kannst du alle WIFI Extensions und deinen Rechner als Clients zu diesem WLAN Netzwerk verbinden und so die Verbindung zwischen dem Rechner und den WIFI Extensions herstellen.

Die Einstellungen sind so okay. Was zeigt den der Status Dialog an, wenn du auf den "Show Status" Knopf klickst? Das sollte in etwa so aussehen. Du musst dann in Brick Viewer als Host eingeben, was dort bei IP steht.

Hi, wenn ich dich richtig versteht, dann willst du das so bauen: Laptop ---[USB]--- Master Brick --- WIFI Extension (Access Point) --- [WLAN] --- WIFI Extension (Client) --- Master Brick --- Industrial Dual Relay Bricklet Das ist so nicht gedacht, daher funktioniert es so nicht. Du kannst den ganzen Stapel am Laptop weglassen, den Stapel mit dem Industrial Dual Relay Bricklet dran als WLAN Access Point konfigurieren und dich dann direkt vom Labtop aus mit diesem Access Point verbinden. Im Brick Viewer verbindest du dich dann nicht mit localhost sondern mit 192.168.42.1: Laptop --- [WLAN] --- WIFI Extension (Access Point) --- Master Brick --- Industrial Dual Relay Bricklet

Wenn du die Zeit über Tage halten muss, dann kannst du ein Real-Time Clock Bricklet 2.0 nehmen. Das hat eine Batterie anstelle des Super Caps und hälte dadurch viel viel länger. Allerdings ist das Real-Time Clock Bricklet 2.0 nicht automatisch mit dem RTC System von Linux intergiert. Die Zeit des Real-Time Clock Bricklet 2.0 kannst du über Brick Viewer setzen. Um die Systemzeit auf die Real-Time Clock Bricklet 2.0 Zeit zu setzen kannst du dieses Skript beim Boot des Raspberry Pis z.B. durch cron oder systemd ausführen lassen. https://github.com/Tinkerforge/red-brick/blob/master/programs/rtc_time/rtc_time.py

Die RTC auf dem HAT Brick wird von einem Super Cap gestüzt und ist für kurze Unterbrechnung der Stromversorgung gedacht im bereich von Stunden, nicht Tagen. Sobald du Internet und damit NTP Verbindung hast kümmert sich Linux darum die RTC aktuell zu halten solange das Raspberry Pi läuft. Mit "sudo hwlock -r" kannst du abrfragen welche Uhrzeit die RTC gerade hat. Mit "sudo hwclock --systohc" kannst du die RTC von Hand auf die aktuelle Systemzeit setzen. Das macht Linux automatisch alle 11 Minuten. Mit "sudo hwclock --hctosys" kannst du die Systemzeit von Hand von der RTC laden. Das macht brickd automatisch beim Start des Raspberry Pis.

Genau die Kombination (Master Brick 2.1 Firmware 2.5.2) habe ich hier gerade noch mal getestet und es funktioniert. Hast du vielleicht ein Kontaktproblem in den oberen Stapelsteckern des Master Brick 2.1?

Das ist der gleiche Reset. Ja, das ist der Reset der gemeint ist. Hast du auf dem Master Brick die aktuelle Firmware 2.5.2 laufen? Blinkt/Leuchtet an der RJ45 Buchse die linke/orange LED? Hast du mal ein anderes Netzwerkkabel probiert?

Ich habe das unter Fedora 37 (Live System) getestet und es verhält sich genau so wie unter Debian. Der Brick im Bootloader taucht als /dev/ttyACM0 auf und gehört root und der Gruppe dialout. Wenn ich den liveuser der Gruppe dialout hinzufüge klappt der Zugriff als User wie erwartet.

Warum fürhst du brickv als root aus? Das sollte nicht notwendig sein.

Ich habe das jetzt in Fedora 37 ausprobiert. Das debhelper Package hat Probleme, dpkg findet es nicht, auch wenn es installiert ist. Zusätzlich ist es dann auch noch kaputt, es fehlt das dh_strip_nondeterminism Skript. Damit es überhaupt geht hab ich dh_strip_nondeterminism einfach durch einen Symlink erzeugt: ln -s /usr/bin/true /usr/bin/dh_strip_nondeterminism Neu im git ist jetzt die --dpkg-no-check-builddeps Option, damit dpkg die Probleme mit dem debhelper Package ignoriert. So kann ich jetzt auf Fedora 37 wieder das Debian Package bauen: ./build_pkg.py --dpkg-no-check-builddeps Nimm bitte die Änderung zurück, die ich die vorher genannt hatte, update auf den aktuellen git Stand und probier es nochmal aus.