Alle Aktivitäten

Hold your horses. That is not what happened. I ran into the above problem with Brickv and tried finding the cause. I did some digging and found your developer cert expired a few months ago. That's it: I did some digging. The expired developer certificate worries me a bit whether it is causing this trouble or not, but that is a different conversation. The URL "https://download.tinkerforge.com/latest_versions.txt" works fine with Safari, Curl, Wget, Python3, Ruby, and also Shortcuts. URL https://download.tinkerforge.com/ works too. Brickv reports an error.

Naja, ist ja auch der Zähler für den Wechselrichter und ein Wechselrichter kann nur Energie einspeisen. Möchtest du vielleicht den virtuellen Zähler auf „Netzbezug“ ändern, bzw. einen weiteren Zähler dafür anlegen, falls du beide Werte gleichzeitig sehen willst? Mit dem Netzbezugszähler klappt’s dann auch mit PV-Überschussladen.

Unser erstes E-Auto ist jetzt im Einsatz - verträgt sich im Prinzip auch gut mit der WARP2-Smart. Aber das PV-Überschussladen funktioniert nicht wie erwartet. Liegt das vielleicht an der unvollständigen Kommunikation zwischen Wallbox und Sungrow-Wechselrichter? Siehe angehängte Bilder Die angezeigte "Leistung" stimmt sehr genau mit dem auch via iSolarCloud dargestellten "PV-Ertrag" überein - wenn auch mit negativem Vorzeichen. Unter "Energiebezug" wird beim Zähler aber nichts angezeigt. Was läuft hier falsch? Herzliche Grüße

Könnte es beispielsweise so sein, dass ein nur sehr geringer PV Überschuss unterhalb der Min Leistung von PV+Min zu einem fälschlichen Start im dreiphasigen Lademodus führt?

Kann verstehen, wenn andere Themen gerade höhere Priorität haben, aber irgendwas passt da noch nicht. Gerade hat es in Min+PV trotz sehr geringem PV Überschuss wieder dreiphasig gestartet und dann nach einiger Zeit auf einphasig umgeschaltet. Und diesmal hatte ich vorher definitiv keine Schnellladung aktiviert bzw. den Lademodus kürzlich verändert. Hab ich da irgendwas falsch konfiguriert, oder ist das ein grundsätzlicher Bug? warp3-2bBb-Debug-Report-2026-02-17T15-14-35-098.txt

What I wanted to see is not in the curl log file because you only redirected stdout to the log file. Please run this command: curl -v https://download.tinkerforge.com &> curl.txt But both logs already show that the download is working.

The last brick daemon release works with all Raspberry Pis except the Compute Module 5. Raspbian 13 also works, but to automatically use the real time clock on the bricklet, you have to install util-linux-extra, which is currently not a dependency of the brickd debian package. Both issues will be fixed with the next brickd release, possibly this week.

Sehr cool, das fände ich super. Ich habe keine andere Heimautomatisierungszentrale (Home Assistant o.ä.) am laufen und würde mich freuen, wenn ich alle Verbräuche der diversen Messstellen im Haushalt mit ins HEMS einbinden könnte. Auch, um darauf aufbauend gewisse Automatisierungsregeln für Batterie und Co zu schreiben. Würde das denn mit der maximalen Anzahl von 7 Zählern kollidieren? Kann mir vorstellen, dass das recht schnell der Fall wäre. (Woher kommt eigentlich die Beschränkung?)

Merci für die schnelle Rückmeldung :)

Die Wallboxleistung ist in der Tat ein Durchschnittswert über die letzten fünf Minuten. Da der Energy Manager nur diese Durchschnittswerte speichert, steht an der Stelle auch nicht die Momentanleistung zur Verfügung. Wir setzen deine Anregung mal auf die Todo-Liste.

Eine Pro, also mit von euch integriertem Zähler

Files attached. curl.txt python.txt

I cannot reproduce the download issue here, with two different MacBooks with macOS 15.5 and 26.1. It's not a general issue with our server, but with Python not being able to verify the HTTPS certifcate of our server. We are using Let's Encrypt now. I'm a little puzzled why it should not work. I suspect a problem local to the affected computer. Could you try running this terminal command on the affected computer and post it's output here: curl -v https://download.tinkerforge.com Same with Python please: python3 -c "from urllib.request import urlopen; print(urlopen('https://download.tinkerforge.com').read()[:100])" Yes, the code signing certificate used to sign that version of brickv is expired by now. But that's not a real issue, because the signature is timestamped and at the time brickv was signed the certificate was valid. This version of brickv is still properly signed. There is no issue to be fixed. There will not be a new brickv release just because of that. Apple decided to show this in a too dramatic way, making it look like an issue. This also has nothing to do with the download issue.

Wir binden im Moment Shelly Module über Modbus/TCP ein. Aber nicht alle Shelly Module bieten Modbus/TCP an. Die Minis haben das leider nicht. https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen2/ShellyProEM Du kannst z.B. hier sehen bei welchem Modulen Modbus/TCP in der Liste steht. Wir haben auf der Todo Liste stehen Shelly Module auch über Outbound Websocket anzubinden. Dies wird dan auch von den Minis unterstüzt. Es gibt dafür aber aktuell keinen Zeitplan, wann das villeicht umgesetzt werden wird.

Ist deine Wallbox eine Pro oder Smart? Bei einer Pro sollte der Wert auf dem WEM-Display mit ein bis zwei Sekunden Verzögerung aktuell sein. Bei einer Smart kann die tatsächliche Ladeleistung nur geschätzt werden.

Ok danke

Sofern ich deine Frage richtig verstehe, wäre ein reguläres Datenkabel, z.B. ein gut geschirmtes S/FTP Verlegekabel, wohl eine gute Wahl. P.s.: Im Außenbereich natürlich mit entsprechendem Mantel gegen Feuchtigkeit und UV.

Habe es gerade noch mal ausgiebig probiert und konnte das Problem nicht reproduzieren. Ich bin unsicher, wie genau ich das unerwartete Verhalten erzeugt hatte. Entschuldigung für den falschen Alarm, eure Software funktioniert genau wie sie soll. Sollte es doch irgendwie noch einmal passieren, melde ich mich hier wieder. Bei den Tests ist mir aber aufgefallen, dass das Display des WEM2 im Wallbox Feld nur einen Durchschnittswert anzeigt, vermutlich der letzten paar Minuten oder so. Die Anzeige für den Netzzähler scheint dagegen sekundengenau. Wenn ich wirklich an den Zählerschrank gehe, um auf das Display zu schauen, dann passt vermutlich irgendwas nicht. Meine Anregung wäre daher, dass das Feld Wallbox auch wirklich die momentane Last abbildet oder sich das im Display Menü so konfigurieren ließe. P.s.: Danke für eure tolle Arbeit!

Hallo, welches Kabel bzw. Kabelquerschnitt kann ich für den EVSE Klemmblock / Abschalteingang §14a EnWG verwenden? Danke Gruß Stefan

Moin, ich möchte gerne einige Shelly Minis in Steckdosen verbauen, diese dann über WLAN ins Heimnetz einbinden und zu den Zählern im Warp Energy Manager 2 hinzufügen. Ist das überhaupt möglich? In den Docs stehen ja nur die großen (Hutschienen-)Zähler mit Klappwandlern als kompatibel. Sorry, falls die Antwort für Shellynutzer:innen offensichtlich ist. Ich hab damit noch keine Erfahrung. 😅 Danke und schöne Grüße

Hallo MatzeTF, ich glaube den Grund gefunden zu haben. Ich habe den Stromzähler für das PV-Überschussladen ohne die PV-Vorlage erstellt. Es wurde es mir erst jetzt (wahrscheinlich mit der neuesten Version) als Fehler angezeigt. Jetzt bleibt die Lade- Leistung bei Bezug bei min. 4,1kW stehen. LG Tino

Wenn ich das richtig sehe, war das Auto über Nacht dauerhaft angeschlossen und wollte nicht laden. Morgens hat das Auto dann von sich aus eine Ladung begonnen. Da die Wallbox die ganze Nacht lang im Schnellmodus maximale Leistung freigegeben hat und am Netzanschluss trotzdem noch Einspeisung war, ist das Lastmanagement davon ausgegangen, dass das schon so passt. Wir haben Pläne, das noch zu verbessern, aber aktuell sind leider andere Dinge wichtiger. Die Sache mit der Inkonsistenz zwischen den Lademodus-Buttons und -Menüs steht schon auf rtrbts Todo-Liste.

Wenn dein Auto gerade lädt und unsinnigerweise bis auf 11 kW hochgeregelt wurde, lade bitte einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an. Dann sehe ich mir das an.

Moin, Anbei der Export meiner Konfiguration der Batteriesteuerung (json) sowie 3 screenshots zu den Einstellungen in der Web-Oberfläche der WARP3: Mein Kostal setzt die Register nach 60 s zurück, daher habe ich das Wiederholraster auf 55 s gesetzt. Hatte in der Beta Phase auch mal 58 s eingestellt, ging auch. Um erst mal zu sehen, was im Normalbetrieb in den Registern steht, habe ich GModBus benutzt. Damit kann man auch Werte testweise schreiben um zu sehen, wie das System reagiert. Da der Plenticore physikalische Vorgaben will (zB Register 1040 in W), braucht es dann noch eine Umrechung von float nach hex. Im obigen Fall "Entladeleistung 0 W" ist das einfach, für andere Werte hilft google "float to hex" ... Batteriespeicher-Konfiguration-Modbus-TCP-Kostal_Plenticore+10_20260214.json Wer aus sowas wie ein *.py wie im referenzierten git macht, ist mir nicht bekannt. hth VinciSC71

Hallo Zusammen, hallo MatzeTF, ich bekomme ja dank eurer Unterstützung nun die Werte vom Stromzähler am Netzeingang auf der WARP2 angezeigt. Da der Ertrag der Solaranlage wieder langsam steigt, möchte jetzt ich gern mit PV-Überschuss das Auto laden. Dazu habe ich den Modus Min(1.380kW) + PV ausgewählt. Wenn der Stromzähler positiv Werte ausgibt, also im Bezug ist, steigt die Leistung bis zum Sollwert 11kW an. Ich erwarte das genau bei negativen Werten, wenn Energie eingespeist wird. Deshalb meine Frage: Welcher Regelalgorithmus steckt dahinter (Differenzbildung zum vorherigen Wert etc.)? Vielen Dank für eure Antwort. LG Tino