photron

git pull und teste bitte nochmal. Der Fehler dort ist ein anderer. An der Stelle wird Modell 160 gelesen, das 128 Register lang ist. Modbus erlaubt es aber nur 125 Register an einem Stück zu lesen. Das habe ich jetzt repariert. Mit -s wird der Block von Modell 160 nicht geladen, sondern übersprungen, daher tritt dieser Problem mit -s nicht auf.

Das hat aber leider alles nichts mit dem originalen Problem zu tun. Das Script kann die Daten lesen, der Energy Manager nicht. Ich such mal weiter nach dem Unterschied.

@poohnet Wir kommen näher. Das discover.py Script liest alle Werte einzeln. Der Energy Manager liest die Werte blockweise. Ich habe das discover.py Script jetzt umgestellt auf blockweises Lesen. Aktualisier mal bitte deinen git Clone und lass das Script nochmal laufen. Ich vermute, dass SMA es nicht erlaubt die Daten blockweise zu lesen. Das discover.py Script hat jetzt eine -s/--single-value-read Option, um das vorherige Verhalten wieder zu bekommen. Ich erwarte, dass das aktuelle discover.py Script ohne -s bei dir nicht funktiioniert, aber mit -s funktioniert. Kannst du das bestätigen?

@poohnet Komisch! Kannst du bitte diese Script ausführen:

https://github.com/Tinkerforge/esp32-firmware/blob/feature-meters-7/software/src/modules/meters_sun_spec/discover.py

Du brauchst dazu pymodbus >= 3.5.x, am einfachsten über pip installieren.

python3 discover.py -H <sunny-boy-addresse> -d 126

Das Script liest jeden Wert einzeln, anstatt den ganzen Common Model Block in einem Rutsch zu lesen.

@poohnet Dann teste mal bitte den aktuelle Stand des features-meters-7 Branch (Commit: meters-sun-spec: Avoid reading common model block padding). Vielleichthilft das. Der Common Model Block kann laut Spec 65 oder 66 Register lang sein. Alles was wir hier zum Testen haben hat de 65er Variante. SMA hat aber die 66 Variante. Der Code geht damit richtig um, denke ich, aber vielleicht mag SMA nicht, dass ich das eine Padding Register mit lese. Das habe ich gerade geändert.

Ich gehe davon aus das SunSpec aktiv ist, da die SunSpec ID gefunden wird bei Geräteadresse 126 (SMA Standardwert laut Dokumentation). Der Common Model Header wird auch gelesen, aber das Lesen des Common Model Blocks gibt dann einen ILLEGAL_ADDRESS Fehler. Es gibt gleich eine neue Firmware zum Testen.

Da scheint sich was in Python geändert zu haben. Dieser Code hat in älteren Python Versionen funktioniert. Ich habe das korrigiert. Teste bitte mal Beta2.

tinkerforge_shell_bindings_2_1_33_beta2.zip

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.

On 9/11/2023 at 9:44 AM, julian2701 said:

Bedeutet die Umstellung langfristig, dass ein manuelles Weitergeben von Netz-Bezug/-Einspeisung an den Energy Manager dann gar nicht mehr möglich ist oder nur, dass das payload sich ändert etc.?

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.

On 9/7/2023 at 5:43 PM, wuesten_fuchs said:

Werden die 7 Anschlüsse vom Typ2-Stecker über das Kabel 1:1 zur Wallbox verbunden? Dann könnte ich dort ja unauffällig einen Taster an der Seite ins Gehäuse bauen.

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.

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