photron

Das Device unter 247 wirst du nur haben wenn du den WiNet-S hast, vermute ich. Wenn du den nicht verbaut hast kommt vermutlich nichts unter 247. Darf ich fragen, was du em Ende erreichen möchtest? PV-Überschussladen? Dafür muss die Wallbox wissen wieviel Leistung über ist. Mal von SunSpec weg. Hier eine Firmware die einen ersten Schuss für eine generelle Modbus/TCP Unterstützung hat mit Sungrow SH... Vorlage. Das Mapping und die Auswahl der Sungrow-Werte auf unsere Zähler-API ist absolute experimentel und muss definitiv überarbeitet werden. Ich habe da mal ein erste Auswahl getroffen. Es werden aber alle gelesenen Werte auch im Ereignis-Log ausgegeben. Also, anstatt einen SunSpec-Zähler, kannst du einen Modbus/TCP Zähler hinzufügen und als Vorlage Sungrow SH... auswählen. Dann werden die 5000er und 13000er Register von Sungrow gelesen. Edit: Veraltete Firmware entfernt.

Wir haben gerade noch einen anderen Kunden auch mit Problemen bei Sungrow. Es scheint mir so, dass man die Modbus/TCP Schnittstelle recht schnell überlasen kann. Wenn ich die richtig verstehe fagst du die Daten ach noch mit anderen Programmen ab. Könntest du versuchen die anderen Abfragen zu pausieren, so dass am besten nur wir alleine mit Modbus/TCP reden können? Dann den Suchbereich auf 247-247 einschränken. Das funktioniert gerade beim anderen Kunden, wenn auch mit Aussetzern.

Um zu verhindern, dass wir zu viele Anfragen stellen bei der Gerätesuche, habe ich in dieser Firmware eingebaut, dass der Geräteadressbereich einschränkbar ist. Teste bitte mit dieser Firmware einmal, ob es hilft den Geräteadressbereich von 1-247 auf 247-247 zu stellen und dann die Gerätesuche durchzuführen. Edit: Veraltete Firmware entfernt.

SunSpec wird leider von verschiedenen Herstellern immer wieder leicht unterscheidlich umgesetzt. Wir arbeiten daran die Kompatibilität zu den Fehlern der Herstellern zu verbessern. Dein erstes Problem ist, wie Matze schon erwähnt hat, dass Sungrow das Ende der Modelliste falsch meldet und wir darüber stolpern. Das haben wir letzte Woche schon bei einem anderen Kunden gesehen. Teste mal bitte die angehängte Firmware, in der dieser Punkt behoben sein sollte. Wir erkennen deinen Wechselrichter als "Wechselrichter einphasig", weil Sungrow den in SunSpec so meldet. Das ist nicht unsere Entscheidung. Das ist leider verwirrend, aber erstmal okay, wie Matze erklärt, weil auch das einphasige Modell dreiphasige Werte melden kann. Hier habe ich noch keine gute Idee wie wir das verbessern könnten. Im Sinne von irgendwie zu raten, dass eigentlich das dreiphasige Modell gemeint ist, Sungrow aber das einphasige meldet. Grundsätzlich liegt kein Problem vor, aber es verwirrt den Kunden. Alles außer dem Anzeigenamen unter dem "Suche starten" Knopf ist relevant. Da wird festgelegt von welcher Modbus/TCP Geräteadresse, von welchem SunSpec Untergerät (Hersteller, Modell, Seriennummer), welches SunSpec-Modell und davon welche Modellinstanz gelesen wird. Da kannst du schlussendlich eintragen was du möchtest, und so lange dein Gerät dann diese Daten auch liefern kann wird es auch funktionieren. Wenn die Suche es aber schon nicht findet, dann ist es höchstwarscheinlich auch nicht vorhanden. Bezüglich der falschen Werte. Die SunSpec Register fangen bei 40000 an. Wir lesen also nicht im 130XX Bereich den du von Hand ausließt. Teste mal bitte mit der angehängen Firmware, ob die Gerätesuche jetzt besser funktioniert. Sobald wir das Problem gelöst haben, schauen wir uns an was bei den Werten nicht passt. Ob wir das falsch lesen, oder ob Sungrow das falsch meldet. Edit: Bitte Firmware im nächsten Post ausprobieren.

Danke für den Hinweis. Ich habe die Dokumentation aktualisiert.

Ich habe deine Änderungen mit in Delphi Bindings 2.1.34 aufgenommen.

Dafür müssen wir das Problem aber nachstellen können. Welches Debian-Derivat nutzt du, auf dem dieses Problem auftritt?

Bindings: C# 2.1.33, Delphi/Lazarus 2.1.34, LabVIEW 2.1.32, Mathematica 2.1.32, Visual Basic .NET 2.1.32 Handle forced socket read timeout for System.AppDomain.Unload timeout fix correctly when using Microsoft .NET runtime on Linux [C#, LabVIEW, Mathematica, VB.NET] Use macOS specific code for all non-Windows platforms [Delphi] Download: C#, Delphi/Lazarus, LabVIEW, Mathematica, Visual Basic .NET

Bindings: C# 2.1.33, Delphi/Lazarus 2.1.34, LabVIEW 2.1.32, Mathematica 2.1.32, Visual Basic .NET 2.1.32 Erzwungener Socket-Lese-Timeout, um das System.AppDomain.Unload-Timeout-Problem zu lösen, wird jetzt auch bei der Verwendung der Microsoft .NET Runtime unter Linux richtig behandelt [C#, LabVIEW, Mathematica, VB.NET] macOS spezifischer Code wird für alle nicht-Windows Platformen verwendet [Delphi] Download: C#, Delphi/Lazarus, LabVIEW, Mathematica, Visual Basic .NET

Klingt gut. Ich baue das ein. Danke!

Das brickv Debian Package hängt ab von: python3 (>= 3.5), python3-pyqt5 (>= 5.5), python3-pyqt5.qtopengl, python3-serial (>= 3.0), python3-tz, python3-tzlocal, python3-pkg-resources Da ist alles dabei was dein Script auch installiert. Da fehlt also erstmal nichts. Der Unterschied ist aber, dass du mit pip die aktuellsten Versionen von PyPI installierst im Gegensatz zu deinem Debian Derivat, dass vermutlich ältere Versionen ausliefern wird. Wir importieren PyQt5.sip nicht direkt. SIP ist ein Implementierungsdetail von PyQt5. Ich vermute das ist ein Bug in der speziellen PyQt5 Version, die dir apt installiert hat, oder in der Art und Weise wie Debian PyQt5 paketiert hat. Vielleicht können wir da einen Workaround für einbauen.

Ich habe die JavaScript Binding im Browser getestet und kann dein Problem leider nicht nachstellen. Die Bindings funktionieren bei mir. Ich habe dieses Beispiel einfach direkt im Browser ausgeführt, ohne es vorher runterzuladen. Ich habe nur die UID meines Outdoor Weather Bricklets eingetragen: https://www.tinkerforge.com/de/doc/Software/Examples/JavaScript/OutdoorWeather_Bricklet_JavaScript_ExampleCallback.html Ich verwenden die aktuellen Softwareversionen: brickd 2.4.5 und Outdoor Weather Bricklet Firmware 2.0.4.

Das Thema ist nicht neu: https://github.com/Tinkerforge/esp32-firmware/issues/210 Das wollen wir uns anschauen, was da realisierbar ist.

Jetzt auch wirklich, sorry 🤦‍♂️

Sorry, ich hatte vergessen die tinkerforge.asc mit hochzuladen. Die Anleitung funktioniert jetzt wie sie soll. Es ist nicht notwenig euch die .asc Datei selbst zu erstellen.

Brick Logger 2.1.10 Support für Industrial Dual AC In Bricklet hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.10 Add support for Industrial Dual AC In Bricklet Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.26 Add support for Industrial Dual AC In Bricklet Add Data Logger support for Industrial Dual AC In Bricklet Only use Python dev-mode if available Fix health monitor metric errors for ESP32 (Ethernet) Brick Add "@ host:port" to window title if connected Avoid crash when closing Brick Viewer Add function code to Modbus master function selection in RS485 Bricklet plugin Downloads: Windows, Linux, macOS

Brick Viewer 2.4.26 Support für Industrial Dual AC In Bricklet hinzugefügt Data Logger Support für Industrial Dual AC In Bricklet hinzugefügt Python dev-mode wird nur aktiviert, wenn verfügbar Health-Monitor Metric-Fehler für ESP32 (Ethernet) Brick korrigiert Verbindingsdetail "@ host:port" im Fenstertitle anzeigen Crash beim Schließen von Brick Viewer vermieden Modbus-Funktionscodes werden im Master-Modus im RS485 Bricklet Plugin angezeigt Downloads: Windows, Linux, macOS

Ich habe Trixie und tinkerforge.asc hinzugefügt und die Anleitung aktualisiert. Danke für den Hinweis!

Bindings: C/C++ 2.1.34, C/C++ for Microcontrollers 2.0.4, C# 2.1.32, Delphi/Lazarus 2.1.33, Go 2.0.15, Java 2.1.33, JavaScript 2.1.35, LabVIEW 2.1.31, Mathematica 2.1.31, MATLAB/Octave 2.0.33, MQTT 2.0.17, Perl 2.1.32, PHP 2.1.31, Python 2.1.31, Ruby 2.1.31, Rust 2.0.21, Saleae 2.0.8, Shell 2.1.33, Visual Basic .NET 2.1.31 Add support for Industrial Dual AC In Bricklet [All] Add FFC shutter mode and normalization to Thermal Imaging Bricklet API [All] Fix System.AppDomain.Unload timeout, avoid crash [LabVIEW] Fix System.AppDomain.Unload timeout [C#, Mathematica, VB.NET] Fix error response check [Go] Fix single chunk streams [Go] Handle empty payload in streamed function calls [MQTT] Remove wrong stream error handling [JavaScript] Add IPv6 support, raises PHP requirement to 7.2.0 [P,HP] Don't leak socket on connect error [Python] Add IPv6 support [Python] Show dropped bytes [Saleae] Fix get-identity call [Shell] Fix --execute with modern Python versions [Shell] Support authentication secret, listen address and port for Arduino ESP32 [µC] Don't count callbacks as unexpected packets [µC] Fix byte offset when splitting packet to be sent [µC] Correctly mark packet as processed if received in setter [µC] Correctly stop waiting for packet when timeout is elapsed [µC] Use correct sequence number when resending proxy packets [µC] Validate header length of received packets [µC] Report local function calls as unsupported instead of timing out [µC] Fix IP address handling with current Arduino ESP32 [µC] Download: C/C++, C/C++ for Microcontrollers, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell,

Bindings: C/C++ 2.1.34, C/C++ for Microcontrollers 2.0.4, C# 2.1.32, Delphi/Lazarus 2.1.33, Go 2.0.15, Java 2.1.33, JavaScript 2.1.35, LabVIEW 2.1.31, Mathematica 2.1.31, MATLAB/Octave 2.0.33, MQTT 2.0.17, Perl 2.1.32, PHP 2.1.31, Python 2.1.31, Ruby 2.1.31, Rust 2.0.21, Saleae 2.0.8, Shell 2.1.33, Visual Basic .NET 2.1.31 Support für Industrial Dual AC In Bricklet hinzugefügt [Alle] FFC Shutter Mode und Normalization zur Thermal Imaging Bricklet API hinzugefügt [Alle] System.AppDomain.Unload Timeout behoben und dadurch LabVIEW-Abstruz vermieden [LabVIEW] System.AppDomain.Unload Timeout behoben [C#, Mathematica, VB.NET] Überprüfung der Antwort im Fehlerfall korrigiert [Go] Single-Chunk-Streams repariert [Go] Leerer Payload in gestreamtem Funktionsaufruf wird korrekt behandelt [MQTT] Falsche Stream-Fehlerbehandlung entfernt [JavaScript] IPv6-Support hinzugefügt, benötigt PHP 7.2.0 [P,HP] Socket-Resource-Leck durch Verbindungsfehler korrigiert [Python] IPv6-Support hinzugefügt [Python] Ignorierte Bytes werden angezeigt [Saleae] get-identity Aufruf repariert [Shell] --execute mit modernen Python-Versionen korrigiert [Shell] Support für Authentication-Secret, Listen-Adresse und -Port für Arduino ESP32 hinzugefügt [µC] Callbacks werden nicht mehr fälschlicherweise als unerwartete Pakete gezählt [µC] Byte-Offset beim Aufteilen zu sendender Pakete korrigiert [µC] Packet wird korrekt als verarbeitet markiert, falls es in einem Setter empfangen wurde [µC] Warten auf Pakete beim Ablauf des Timeouts wird korrekt abgebrochen [µC] Verwendung der korrekten Sequenznummer beim Weiterleiten von Proxy-Paketen [µC] Header-Länge empfangener Pakete wird überprüft [µC] Lokale Funktionsaufrufe werden direkt als nicht-unterstüzt abgebrochen anstatt in einen Timeout zu laufen [µC] IP-Adress-Behandlung bei Verwendung der aktuellen Arduino ESP32 Bibliothek korrigiert [µC] Download: C/C++, C/C++ for Microcontrollers, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET

The power supply looks okay. For now I don't expect it to the an issue. Does the USB cable ferrit cores near the connectors? Could you try a different USB cable and/or a different USB port on the Raspberry Pi?

@fridolin11 Your problem seem to have a different cause. There was no fix in Brick Viewer, but a change in Brick Daemon to handle the message burst created by the enumeration of the whole system. There is no need to test any old version that might have been mentioned in this thread. Please only test the latest versions of Brick Daemon and Brick Viewer. I assume that is what you already have installed. From the brickd.log I can see that you get a lot stalled USB read transfers making the communication with the Bricks and Bricklets unreliable. As long as you continue to see this kind of message in brickd.log the problem persists. You can open brickd.log in a console/terminal like this to get a live view: tail -f /var/log/brickd.log Then try plugging and unplugging the Bricks from USB and see what messages you get. Do the stall messages only appear when you connect two Bricks to USB? Is one Brick alone okay? In the Raspberry Pi 2 era many problems where caused by insufficiant power supplies. How do you power the Raspberry Pi 4? Could you try a "stronger" power supply? Du you directly connect the Bricks to the Raspberry Pi, or is there another USB hub in between? Does it make a difference if you remove any USB hub? You can also try to add a powered USB hub.

@andyknownasabu Firmware 2.0.2 wurde soeben veröffentlicht. Diese merkt sich jetzt die letzte Phasenanforderung über Neustarts des ESP32 Ethernet Bricks hinweg. Der Crash im SunSpec Scan ist behoben. Und noch einige Dinge mehr, die hier aber gerade nicht relevant sind. Sorry, für das leichte Chaos!