photron

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.

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?