dachte die brauchen bis zu 200mA beim senden? Da ist das kleine Netzteil schon krass überfordert, das versorgt cpu und wandler mit und kann glaub 1,5W
Was für einen esp müßte ich kaufen? (Ist denn sicher, daß ich wirklich Zugriff habe? Is beim 500er die gleiche software drauf wie beim 1000er?)
Das ist auch grober Unfug mit den 20 ESP, aber einen, auch den ESP 32, packt das Netzteil, wenn du den ESP einen ordentlichen Kondensator auf 3,3 Volt spendierst
Und nein, ich gehe in keinem Fall davon aus, dass der Code der 1000 für den 500 funktioniert.
also "fernbedienen" oder Diagnose geht beim 500er sicher nicht? Muss ich eine CPU vom 1000er besorgen?
Würde da nicht ein 1kohm R reichen?
Oder auf der soyo rx seite gar nix weil irrelevant?
Warum "lauscht" du nicht mal an tx1 oder tx2?
Ein usbee oder salae clone mit pulseview kostst keine 5 eur.
Oder notfalls ein seriell-usb und dann die baudrate nachschauen?
Allerdings versuch das nicht wenn PC und Soyo am netz hängen !
Die tx pins sind alle still. Müsste da schon was kommen ohne dass ich was reinsende?
KA
Bein aufstarten auch still ?
netter versuch, aber wenn wr oder pc nicht am strom sind seh ich sicher nix
war da mim scope dran, nix.
Ich hab aldi laptop ;o)
So zeugs is mit scope teils echt schwierig zu sehen.
Würde 100us/div und "single trigger" auf 2V versuchen.
hatte auch mal ne helle led dran und nachts geschaut. da kommt ohne kommando gar nix, weder bei 230v ein noch bei 24V ein
Die display version antwortet auf Send in Hex : "55 01 00 00 00 FE" am displayport oder Send in Hex : "24 00 00 00 00 00 00 00" 8 Bytes am limiter port.
Neuere versionen antworten am limiter port nicht mehr.
Hier der glavanisch isolierte seriall usb wandler dazu
Ich versuche einmal eure Diskussion der letzten 24 Stunden hier zusammenzufassen auch um einen Realitätscheck zu machen, ob ich euch nicht falsch verstanden habe:
- Eure Diskussion dreht sich nicht mehr um die GTN-1000 oder GTN-1000 Modelle, sondern um den GTN-500 der von Haus aus per Drehpoti geregelt wird.
- Gesucht wird nach internen Schnittstellen (UARTs des STM32), welche im besten Fall leicht zugänglich sind.
- Erhofft wird sich, dass die Software auf dem STM32 den gleichen Befehlssatz unterstützt wie beim großen Bruder. Deshalb die Idee unterschiedliche (bekannte) Nachrichten ("Gib mir 100W", "Gib mir ein old-school Status-Frame", "Gib mir ein Display-Frame") an den STM zu senden.
- Gehofft wird, dass der STM32 beim booten oder periodisch auf einem der UARTs quasselt und irgendwas spannendes zu erzählen hat, was abweichend zum großen Bruder wäre.
Konnte ich euch richtig folgen? Die ganzen Fragen in Richtung "Wie versorge ich den ESP mit Strom" und "Wie stelle ich sicher, dass der Spannungspegel stimmt" lasse ich mal außen vor.
Das war meine Frage. Alternativ dazu: einen 1000er Totalschaden schlachten falls ich einen finde und damit einen 500er intelligent machen
ich halte es auch für interessant, wenn es einen Diagnosemodus gäbe. Fehler die sich nur in "startet nicht" äußern gibts auch bei den kleinen
Alles klar! Dann hilft nur herum stochern. 
Ich würde damit beginnen die CPU-Boards der beiden Modelle zu vergleichen. Der STM32 hat mehrere serielle Schnittstellen, welche beim großen Bruder eine zum Display führt und eine für den Empfang von Limiter-Wünschen genutzt wird. Ich vermute, dass bei dem neuesten Modell (der Display und WiFi-Dongle parallel unterstützt) eine dritte serielle Leitung zum Einsatz kommt.
Ist das CPU-Board des GTN-500 ähnlich belegt? Welche UARTs sind rausgeführt und welche nicht? Welche Pads dienen nur zum flashen/debuggen? Das müsste man alles mit Hilfe der Specs eines STM32 und etwas Fleißarbeit "rausklingeln" können.
Hab jetzt den 24V 500W mit CPU V3 offen
Platinenbeschriftung rechte Leiste:
1 SPWM
2 ACV
3 TMP
4 8V
5 AO1
6 2.5
7 DCI
8 UAR geht auf RS485 Stecker
9 TX1 geht auf RS485 Stecker
10 RX1 geht auf RS485 Stecker
mittlere Leiste:
1 GND
2 FAN
3 SD
4 ACF
5 +5V
linke Leiste
1 LED G
2 LED B
3 LED R
4 scheint +5V zu sein
5 "R62" nicht blegter SMD nach +5V
6 zum Poti
7 TX3 - con102 heisst auf CPU TX2
8 RX3 - con102 heisst auf CPU RX2
9 müsste Schalter sein
10 müsste +5V sein (?)
dazu noch der 4pin header auf der CPU
zu Display und WiFi-Dongle
Auf einem Bild kann man erkennen, dass der controller vom Display den dongle managt. Das ist auch schlau, weil damit beides konsistent gehalten wird
siehe hier https://akkudoktor.net/uploads/default/optimized/3X/1/2/128d2c87996d7f0dd87ebabecbebd2545e7d37af_2_748x1000.jpeg
Das hast du richtig zusammengefasst !
Zu beachten die alten "nur display" haben ein anderes protokoll als die "display & dongle". Ich habe nur das alte "display only" protokoll untersucht. Das status abfragen der "dongle version" müsste man aus dem sissy code rauslesen oder ihn einfach fragen.
Wenn du die display + dongle Version schon da hast, könntest du die Daten mim Terminalprogramm mitschneiden und mit den bekannten vergleichen. Das wäre sehr interessant!
Dongle version (ohne gewähr, war irgendwo bei mir im unterordner):
55 0B 30 2D 5A 64 00 00 00 06 01 D2 # Set PV Mode
55 0B 30 2D 5A 64 00 00 00 06 11 C2 # Set PV Limit Mode
55 0B 30 2D 5A 64 00 00 00 06 02 D1 # Set Bat Const Mode
55 0B 30 2D 5A 64 00 00 00 06 12 C1 # Set Bat Limit Mode
A6 00 00 61 02 00 00 00 00 00 F9 64 02 11 2C # Status frame (PV)
A6 00 00 E1 02 00 00 00 00 00 FA 64 02 11 AB # Status frame (PV Limit)
A6 00 00 51 02 00 00 00 00 00 F9 64 02 11 3C # Status frame (Bat Const)
A6 00 00 D1 02 00 00 00 00 00 F9 64 02 12 BB # Status frame (Bat Limit)
A6 03 84 D1 42 00 00 00 00 00 FB 64 02 15 EF # Status frame (RS485 connected)
A6 03 84 D1 42 00 00 00 00 00 FB 64 02 16 EE # Requested power demand 900W
A6 00 64 D1 42 00 00 00 00 00 FB 64 02 16 11 # Requested power demand 100W
A6 01 2C D1 42 00 00 00 00 00 FB 64 02 16 48 # Requested power demand 300W
A6 01 2C D1 02 00 00 00 00 00 FB 64 02 16 88 # Status frame (RS485 offline)
A6 00 00 63 02 D4 30 30 2D 00 FA 64 5A 06 7B # Settings frame (PV Mode)
A6 00 00 E3 02 D4 30 30 2D 00 FA 64 5A 06 FB # Settings frame (PV Limit)
A6 00 00 53 02 D4 30 30 2D 00 FA 64 5A 06 8B # Settings frame (Bat Const)
A6 00 00 D3 02 D4 30 30 2D 00 FA 64 5A 06 0B # Settings frame (Bat Limit)
55 11 30 2D 5A 64 00 00 00 06 00 CD # Reboot command (Respone: A6 00 00 61 02 00 00 00 00 00 F9 64 02 13 2A)
55 -> zum soyo
A6 -> vom soyo
Du könntest einfach 55 11 30 2D 5A 64 00 00 00 06 00 CD senden und schauen ob der reboot macht.
Real mitschnitte wird schwieriger, der macht gerade 740W.
1 „Gefällt mir“
Nächste Frage: Wenn ich eine "48V CPU" in ein 24V Gerät stecke, was passiert? Sind nur die Anzeigewerte falsch?
Moin,
ich lese hier schon oft mit, habe aber jetzt selber mal eine Frage.
Ich nutze den Soyosource Controller jetzt schon seit 2 Jahren - und das absolut stabil.
Zuerst habe ich noch keinen Shelly 3EM Pro gehabt. Da hatte ich die Leistung manuell über NodeRed berechnet und gesteuert (Static HttpInterface/WebGui). Mittlerweile habe ich den 3EM Pro und lasse es darüber regeln.
Jetzt habe ich zeitweise den Sonderfall, dass ich doch manuell regeln möchte. Kann ich die Betriebsart von außen umschalten? Entweder per MQTT oder es würde auch per rest call gehen. Würde dann gerne in Homeassistant eine Automation dafür anlegen.
Hat jemand einen Tipp für mich?
Danke
LG André
In meiner Lösung schaltet mein einfach den "manuellen Modus" ein und setzt eine Leistung. Das geht per MQTT oder nativen API (Home Assistant Anbindung) und sieht so aus:
Bei KlausLis (BSG) Lösung kannst du sicher den "SetStatic"-POST-Request samt Wert gegen das Webinterface posten.