photron

Okay, so brickv fails to validate the SSL certificate of download.tinkerforge.com, but every other program has no issue with it. Please try this version. It adds details about the CA store used to validate the SSL certificate. I suspect that Python uses an empty CA store on some devices, but not on others. This is expected. It's a side effect of the specific way I added this error message. Edit: Obsolete brickv version removed.

Please try this test version of brickv. Either this one just works now, or it reports an error, that should help me to figure out what's wrong. Edit: Obsolete brickv version removed.

Thank you. I can see that connection fails with a certificate error. That's what I expected to be the problem.

As I cannot reproduce the problem here I need help. Could anyone that is affected by the download problem run this brickv Github branch from source in a terminal? It prints the exception backtrace to the terminal. I would like to see this backtrace. GitHubGitHub - Tinkerforge/brickv at macos-download-problemSmall Qt GUI to control and test all Bricks and Bricklets from Tinkerforge - GitHub - Tinkerforge/brickv at macos-download-problem

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.

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.

Bei der Anzeige der aktiven Regel werden fälschlicherweise deaktivierte Regeln nicht eingerechnet. Dadurch ist dann die Anzeige falsch, wenn du deaktiverte Regeln hast, sorry. Das habe ich gerade gefixt, wird Teil der nächsten Firmware-Version sein.

Danke, das sieht auf den ersten Blick gut aus. Ich komme in Kürze darauf zurück, das mit deiner Anlage zu testen.

Die Batteriesteuerung ist jetzt in den aktuellen Firmwares für alle Produkte mit enthalten. Der Beta-Test ist damit beendet. Danke für eure Unterstützung. Die Entwicklung der Batteriesteuerung ist aber noch nicht angeschlossen. Es wird ähnlich wie bei den Stromzähler noch Unterstützung für weitere Hersteller hinzugefügt werden.

Es kommen noch weitere Modelle.

Danke für den Hinweis, aber das sind nicht die Ströme am Netzanschluss (Power grid), sondern die Ströme am Wechselrichters (Inverter). Für den Netzanschluss sind keine Ströme aufgelistet. Ich habe bei RCT Power noch eine Supportanfrage laufen, aber dort ist man mir bisher ein Antwort schuldig geblieben.

Kannst du mir die Modbus Dokumentation für Solis schicken? Dann schau ich da mal drüber.

Gut, dann teste das erst nochmal. Falls das dennoch nicht passen sollte, was ich nicht erwarte, denn EVCC liest auch 13010 für die Netzanschlussleistung aus, dann melde dich wieder und wir gucken genauer hinterher, was im da nicht ist.

Das ist richtig, denn das sind die Register für die SG Serie. Siehe im Python Script die "'variants': ['String']" Zeile bei jedem dieser Register. Die lesen wir bei dir also nicht aus, weil du einen SH hast. Bei dir lesen wird Registernummer 13010 aus. Das 5601 Register ist recht neu. Das war mir garnicht bekannt, dass es das gibt, da ich bisher nur Version 1.0.23 der Registerdokumentaton hatte. Danke, dass du Version 1.1.11 verlinkt hast. Wenn nötig können wir da zu Register 5601 wechseln, aber das muss ich mit Versionserkennung machen, weil ältere Sungrow Firmwareversionen das nicht unterstützen werden. Die Frage ist jetzt aber, was ist bei dir anders. Denn wir haben mehrere Sungrow Kunden mit denen wir in Kontakt stehen und bisher habe ich noch von keinem gehört, dass die Netzanschlussleistung nicht passen würde. Und das ist ja nicht nur ein kosmetischer Wert, sondern es fällt beim PV-Überschussladen schnell auf, wenn das nicht passt.

Das sollte so aussehen. Bei dir fehlen die Balken, die Daten sind aber grundsätzlich da, denn du hast Werte in der Gesamt-Energie-Ansicht unter dem Graphen. Welcher Browser in welcher Version ist das? Stehen Fehler in der Browser-Konsole?

Stimmt, die Lokalisierung von Zahlen und Daten wurde nicht durch die Systemsprache-Einstellung beeinflusst. Das ist jetzt korrigiert und wird Teil des nächsten Firmware-Release. Nachtrag: Das ganze ist kompliziert... Der Browser hat zwei Spracheinstellungen. Eine für das Browser UI (in JS abrufbar mittels: Intl.NumberFormat().resolvedOptions().locale) und eine für die Website (in JS abrufbar mittels: navigator.languages). Ohne Argument nimmt toLocaleString() das Browser-UI-Locale. Soweit hast du recht, dass wir toLocaleString() mit en bzw. de Locale aufrufen müssten (die Details sind kompliziert, die lasse ich mal weg). Aber... die HTML Eingabefelder, die wir für Zahlen, Uhrzeiten und Daten verwenden, verwenden immer das Browser-UI-Locale und wir können das, im Gegensatz zu toLocaleString(), nicht überstimmen. Dadurch hätten wir dann Inkonsistenz in der Darstellung von Zahlen, Uhrzeiten und Daten abhängig davon wo diese angezeigt werden. Ich denke diese Inkonsistenz wäre schlimmer, als die jetztige Situation. Daher wird das leider bis auf weiteres so bleiben müssen. Ich habe an die Systemsprache Option jetzt eine Warnung hinzugefügt, wenn das Locale der Systemsprache und das Browser-UI-Locale von einander abweichen und dadurch die Textsprache und die Darstellung von Zahlen, Uhrzeiten und Daten nicht zueinander passen werden.

Für Smart Energy Broker Support (auch Batteriesteuerung) wende dich bitte an Christopher Ibrügger bei der Henrich Schröder GmbH: c.ibruegger@henrich-schroeder.de

Der Crash war in Firmware 2.8.15 und ist bei dir beim Auslösen des Neustarts im Rahmen des Firmware-Updates aufgetreten. Der Fehler ist in der aktullen Firm 2.8.16 behoben, auf der auch diese Beta-Firmware basiert. Das ist absolut ertwarte, denn du hast 300W PV-Leistung, bei 3600W Hausverbrauch, dadurch 3300W Netzbezug und du steuerst den Speicher in "Normal Laden, normal Entladen" an. "Normal" heißt, dass wir den Speicher nicht zwingen oder blockieren, sondern der Speicher selbst entscheidet im Rahmen der vorgebenen maximalen normalen (Ent-)Ladeleistung. Da du keinen PV-Überschuss hast lädt dein Speicher dann eben nicht. Wenn du den Speicher zum Laden zwingen willst, dann musst du "Laden erzwingen, Entladen blockieren" wählen.

Hier geht es weiter, jetzt auch endlich mit SMA:

Das klingt gut. Melde dich wenn du, sobald du was funktionales hast. Dann nehmen wir das offiziell auf.

Firmware: WARP1 2.8.15, WARP2 2.8.16, WARP3 2.8.16, WARP Energy Manager 2.4.14, WARP Energy Manager 2.0 1.3.14 Absturz beim Schließen oder Neuladen des Webinterfaces im Fernzugriff behoben Download: WARP1 2.8.15 bzw. WARP2 2.8.16 bzw. WARP3 2.8.16 bzw. WARP Energy Manager 2.4.14 bzw. WARP Energy Manager 2.0 1.3.14

Die Dokumentation sieht gut aus. Danke. Neben der Wallbox, benötigust du dann noch einen Modbus/RTU-zu-Modbus/TCP-Wandler, damit die Wallbox mit deinem Wechselrichter kommunizieren kann. Zum Beipspiel diesen von Waveshare: https://www.amazon.de/Waveshare-RS485-Ethernet-Converter-Auto-Negotiation/dp/B09QMNWYLQ Ich schlage folgendes Vorgehen vor. Du bestellst dir einen WARP Charger Pro und einen Modbus/RTU-zu-Modbus/TCP-Wandler und lässt besides montieren. Sobald das alles läuft meldest du dich wieder bei uns. Wir richten zusammen auf deiner Wallbox temporär den Fernzugriff für uns ein. Dadurch können wir die Anbindung an deinen Wechselrichter auf deiner Wallbox entwicklen und testen. Am Ende hast du eine Wallbox die deine Anforderungen erfüllt.

Die Batteriesteuerung ist jetzt in den aktuellen Firmwares für alle Produkte mit enthalten. Der Beta-Test ist damit beendet. Als eine nächstes großes Feature kommt die Batteriespeicher-Steuerung. Sie ist im Webinterface unter Energiemanagement → Speichersteuerung zu finden. Unter anderem kann dem Batteriespeicher das Entladen verboten werden, während im Schnelllademodus geladen wird. Vorher hätte sich der Batteriespeicher für die Ladung des Autos entladen. Dies kann jetzt unterbunden werden. Intern wird dies über das Lastmanagement realisiert. Dementsprechend muss der Lastmanager aktiviert sein. Dies ist aber vermutlich eh schon der Fall, da die Speichersteuerung hauptsächlich zusammen mit PV-Überschussladen verwendet werden wird, für das der Lastmanager auch aktiviert sein muss. Aktuell steht zur Kommunikation mit dem Batteriespeicher Modbus/TCP zur Verfügung. Es gibt sechs diskrete Modi, in die ein Batteriespeicher versetzt werden kann: Laden blockieren, Entladen blockieren Normal Laden, normal Entladen Normal Laden, Entladen blockieren Laden erzwingen, Entladen blockieren Laden blockieren, normal Entladen Laden blockieren, Entladen erzwingen Damit sind alle Anwendungsfälle abgedeckt und es können auch Speicher gesteuert werden, bei denen die Lade- und Entladeleistung nicht unabhängig voneinander beeinflusst werden kann. Es gibt zwei Regelsätze: Laderegeln und Entladeregeln. Bei jeder Regel muss angegeben werden, ob sie das Laden/Entladen erzwingt oder blockiert. Die jeweils erste zutreffende Regel aus jeder Tabelle ist aktiv, sodass über die Reihenfolge priorisiert werden kann. Die beiden aktiven Regeln zusammen ergeben dann den Speichermodus. Trifft in einer Tabelle keine Regel zu, wird die Lade-/Endladerichtung entsprechend nicht beeinflusst und auf normal belassen. Neben Registersätzen für Alpha ESS, Deye, Hailei, Sungrow und Victron Energy gibt es jetzt auch einen Registersatz für SMA Hybrid- und Batterie-Wechselrichter basierend auf der 6-Register Steuerung. Dies wurde erfolgreich mit einem SMA STP8.0-3SE-40 Wechselrichter getestet (Firmware: 3.06.18.R). Es sollte mit allen SMA Hybrid- und Batterie-Wechselrichtern gleichermaßen funktionieren. Wichtig ist, dass das SMA eigene prognosebasierte Batterieladen deaktiviert sein muss. Achtung: Die Parameterierung der Registersätze sind zwischen diesen und den vorherigen Firmwares nicht kompatibel und müssen nach dem Update neu eingestellt werden. Es wird empfohlen, vor dem Update jeweils einen Screenshot o. Ä. zu machen. Alle anderen Einstellung werden übernommen. Wir freuen uns über jegliche Rückmeldung. Gerne auch mit Modbus-Registersätzen, die für eure Speicher funktionieren. Edit: Veraltete Firmware-Dateien entfernt.

Aktualisier mal die Firmware, dann funktioniert das automatisch.