photron

Fronius ist hier sehr kreativ und missbraucht beim GEN24 Plus MPPT 3 und 4 im SunSpec Modell 160 um die Batterieleistung abzubilden. Wenn ich das richtig sehe machen Fronius das beim Verto Plus genau so nur dass es dort MPPT 4 und 5 sind, dadurch kommt der +20 Versatz in den Registeraddressen. Ich denke wir können das für den Verto genau so lösen wie wir das auch für den GEN24 gemacht haben.

Das klingt gut. Wir haben hier die 8kW Variante allerdings ohne Speicher. Die Shine Sticks bieten nach außen kein Modbus/TCP an, so weit ich das sehe. Es geht wohl nicht ohne weiteren Modbus/RTU-Modbus/TCP-Adapter wie z.B. diesen hier an Pins 3 und 4 des COM Steckers am Wechselrichter: https://amzn.eu/d/0baV7Pm2 Damit habe ich die Anbindung für Growatt implmentiert und getestet. Allerdings noch nicht vollständig. Da wir hier keinen Speicher an diesem Wechselrichter habe. Ich könnte die Tests auf deiner Anlage über Fernzugriff auf deine Wallbox abschließen.

@Benji Welches Growatt Wechselrichtermodell hast du genau?

Ist das Netzwerkkabel gut gekrimpt? Hast du per Ping vom PC zum WEM die Verbindung vermessen, bezüglich Paketverlust? Zeig doch mal einen Debug Report vor (System -> Ergeignis-Log).

Das ist leider von Hersteller zu Hersteller verschieden. Manche Hersteller bilden dass sehr schön ab, da hat gefühlt jemand wirklich drüber nach gedacht. Andere sind da schwieriger. Bisher habe ich es noch bei allen hinbekommen Laden und Entladen unabhängig von einander zu kontrollieren. Einziges Problem das gerade noch besteht sind SMA ennexOS Geräte, bei denen man die interne Regelung der Batterie wirklich komplett abstellen muss, wenn man extern steuern will. Dann kann man alles unabhängig steuern. ABER dann kann regelt die Batterie garnicht mehr selber und ich kann den Normal/Normal Modus nicht umsetzen. Weil wir eigentlich nicht die Regelung der Batterie übernehmen wollen, sondern nur der bestehenden Regelung Vorgaben machen wollen. Ich habe gerade noch SAX Power in der Mache. Sobald das durch ist steht Kostal auf der Liste. Ich würde da gerne auf deine Erfahrungen aufbauen und das offiziell in die Firmware bringen wollen.

Soweit ich das sehe kommuniziert der Stick über Modbus/RTU mit dem Wechselrichter, aber der Stick gibt das nicht über Modbus/TCP nach außen weiter. Ich bekomme auch nicht wirklich raus, ob die anderen Varianten wie der ShineLan-X2 Stick Modbus/TCP anbieten. Wir haben hier zwar einen Growatt Wechselrichter an der Wand hängen, aber ich komme damit gerade leider noch nicht weiter.

Brickv 2.4.27 is released

Brick Viewer 2.4.27 Add support for NFC Forum Type 5 to NFC Bricklet plugin Make flashing of Co-MCU Bricklets more robust Fix firmware download on macOS Downloads: Windows, Linux, macOS

Brick Viewer 2.4.27 Unterstützung für NFC Forum Type 5 zum NFC Bricklet Plugin hinzugefügt Flashen von Co-MCU Bricklets robuster gemacht Firmware-Download auf macOS repariert Downloads: Windows, Linux, macOS

Okay. I cleaned up all the changes and make a new version that just contains the relevant fix. Please try this one more time to confirm the fix still works. Thank you. Once the fix is confirmed, then I will make an official brickv release form it. Edit: Obsolete brickv version removed.

The last line of the error message shows that the CA store is really empty. Here is a brickv version that tries to load the system CA store. This might actually fix the problem. I removed the other error message again. There will be just one message box showing details about the load process. I'd like to see that one. Edit: Obsolete brickv version removed.

brickd 2.4.9 mit diesen Korrekturen ist veröffentlicht.

Version 2.4.9 is released.

Brick Daemon 2.4.9 Fix crash on Raspberry Pi Compute Module 5 Adapt to changed packaging for hwclock in Debian Trixie Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.9 Absturz auf Raspberry Pi Compute Module 5 behoben An die geänderte Paketierung von hwclock in Debian Trixie angepasst Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

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.