[Request]Button zum Auslösen eines Durchsteppens der Frequenz des CMT2300A wenn keine Verbindung zum Wechselrichter zB HMS 1600-4T #2278
Comments
|
Frequenzwechsel von HMS 1600-4T bestätigt: |
|
Hier das gleiche Problem mit HMS-1600-4T. Fragen dazu: Danke. |
|
@khschmidt @Troubadix einen extra GPIO für einen Frequenzwechsel zu belegen ist mE nicht zielführend. Könntet ihr die ersten sieben Stellen Eurer Seriennummer und die Seite mit der Firmware/Hardware Version aus OpenDTU hier dokumentieren? |
|
Seriennummer: 1164A006Bxxx |
|
habe gestern mein python script der Nulleinspeisung erweitert. |
|
Muss mich hier mal dranhängen. Als Frischling der heute seinen allerersten HMS-1800-4T (FW 1.0.27) mit einem OpenDTU Fusion v3 (generic_esp32s3_usb 24.9.27) in Betrieb genommen hat war ich na klar sofort in Panik als keine Daten mehr vom WR kamen. Zum Glück hab ich dieses Issue gefunden bevor ich den WR herausgerissen habe ;-) Müsste der HMS nicht einen Frequenzwechsel irgendwie vorher ankündigen? Ich meine, der Hoymiles-Stick muss das doch auch irgendwie mitbekommen. |
|
Rein von der Logik macht es meines Erachtens keinen Sinn, wenn irgendein Wechselrichter der DTU sagt, auf welcher Frequenz sie zu kommunizieren hat. Eine DTU kann ja mehr als einen Wechselrichter verwalten und wird nicht jeden Wechselrichter auf dessen eigener Frequenz anfunken. |
|
Guter Punkt. Oder lässt das Funkmodul vielleicht ein größeres Empfangsspektrum zu? Vom Signalduino-Projekt (FHEM) kenne ich das. Dort werden im 433MHz-Band ja auch diverse Geräte mit leicht unterschiedlichen Frequenzen empfangen. Ist aber ein anderer Chip. Wohlgemerkt hat der HMS durchaus noch Befehle empfangen. Ich konnte ihn z.B. problemlos an- und ausschalten. Nur kam halt nichts mehr zurück. |
|
@khschmidt & @kopierschnitte könnt ihr von Eurem Problem ein Serial Log erstellen, dann weiß man vielleicht eher wann und wo genau das Problem auftritt. Das bei @kopierschnitte klingt seltsam, da er angeblich noch Kommandos schicken kann? |
|
Seriallog dauert bei mir leider, da ich den ESP recht tief vergraben habe. Aber die Sache mit den Kommandos ist definitiv so. Habe ja direkt vor'm WR gekniet und gesehen, wie er direkt von grün zu rot (und wieder zurück) wechselte. OpenDTU hat natürlich mangels ACK einen Fehler angezeigt. |
|
Serial Log ist bei mir auch aufwendig. Kann man die virtuelle Konsole in eine Datei umleiten, oder gibt es eine Debugschnittstelle über Telnet? |
|
Der Fall den Kopierschnitte beschreibt wäre auch so erklärbar: Wenn er sehr nahe am Wechselrichter mit seiner DTU war, dann ist die Empfangsfeldstärke sehr hoch. Wenn die Kanaltrennung des Chips im Wechselrichter nicht allzu hoch ist, dann kann das auch ein Kanalübersprechen sein, da bei mir der Wechselrichter von 865,00MHz auf den Nachbarkanal 865,25MHz gewechselt hat. Die Antwort vom Wechselrichter wird von der DTU nicht gesehen, wenn die Kanaltrennung des CMT2300 höher ist. |
|
In der Tat sind es bei mir max. 2m Entfernung. Könnte also sein! |
|
@khschmidt es gab erst kürzlich einen PR für die Umleitung auf einen Remote Syslog Server #2292 . Ich habe leider die Vermutung dass Hoymiles seit ca. Ende 2023/Anfang 2024 das Verhalten / Verfahren der HMS/HMT Baureihe mit einem Update der WR Firmware geändert hat. Früher hatte das Change Channel Command von der DTU ausgereicht. Vielleicht kann auch ein Nutzer (@nivadis ?) mit einer Hoymiles DTU-S Pro/Lite das aktuelle Verhalten nochmal mitschneiden ? |
|
@stefan123t danke für den Hinweis, dann werde ich meine Zweit-DTU mal auf die aktuelle Firmware updaten damit ich remote syslog einrichten kann, sende ich dann auf meinen raspi3 |
|
@khschmidt den PR musst Du selber bauen, der ist m.W. noch nicht im aktuellen Trunk / Master enthalten. |
|
Hab den PR syslog in die aktuelle Version eingebaut, compiliert und geflasht. Leider taucht auf der Konfigurationsseite/Netzwerk der Syslogéintrag nicht auf. Irgendetwas habe ich wohl noch übersehen. Ja richtig, ich musste erst die webapp compilieren, jetzt ist der syslog-Eintrag vorhanden |
|
Heute ist wieder mal im Wechselrichterlog der folgende Eintrag: |
|
Seltsam finde ich dass das Active Power Limit mE sehr niedrig ist 1W/1%, obwohl der WR ca. 20-30W mindestens braucht um zu Laufen. Man darf ihn nicht unter die Einschaltschwelle runterregeln, weil er sonst nicht mehr selber aufwacht oder antworten kann. Hier ein altes Beispiel aus #35 Hier aus Deinem Log Und hier im 1:1 Vergleich nochmal: @tbnobody sollen wir das untere Limit beschränken und stattdessen einen Fehler zurück liefern. Laut den bisherigen Erfahrungsberichten soll man den WR dann lieber mit Power Off bzw. on Aus- bzw. Einschalten, wenn man den Strom nicht nutzen möchte, zB OpenDTU-OnBattery. |
|
@stefan123t das ist sehr eigenartig, mein pythonscript hat als unteres limit 15% relativ, also 240W, es wird auch nie weniger in der dtu angezeigt und das script läuft mit 5s Raster und in diesem Zeitfenster ist dieses Kommando mehrfach innerhalb weniger Sekunden, danach ist das Logfile wieder komplett unauffällig. Ich habe noch ein Stück danach rauskopiert ich benutze zur Übertragung im python script die web-api mit http-get und http-post; kann es dabei zu einem Übertragungsfehler kommen? |
|
Ich glaube ich habe das Kommando nicht richtig interpetiert. Das 0x01 2C = 300 bzw das 0x00 B4 = 180 ist der Wert. Danach folgt die Art, wie das Limit gesetzt wird. Persistent/Temporär bzw Absolut in W / Relativ %. Das ist einmal 0x01 00 bzw. 0x00 01. Ich kann mich nicht mehr erinnern was davon was bedeutet / setzt. Aber die Frage ist warum setzt Du das Limit alle fünf Sekunden ? Prüfst Du auch, ob das Limit gezogen hat, dh ob der WR das Limit angenommen hat ? Die Hoymiles WR reagieren sehr pikiert wenn man das Limit zu schnell anpasst, bevor sie es richtig gesetzt haben. Die anderen beiden Limits sind 0x00 C8 = 200 und dann 0x00 BE = 190. Vielleicht ist das bei Dir auch schon zu kleinteilig geregelt ? Hoymiles verwendet mW Stufen von 30W bzw 1-2% rauf/runter. Vielleicht machen die WR - zumal die kleinen Modelle - auch Schritte von 20W mit aber 10W klingt mir persönlich nach ein wenig zu engmaschig. Wieviel Watt hat denn Dein WR und wieviel Prozent sind das dann ? Ach steht ja oben 15% sind 240 W also 16 W / 1% folglich sind 100% = 1600 W. Wenn Du nur in >16 W Schritten regelst, wird es dann besser ? Die DTU bekommt die Rückmeldung dass der WR den neuen Limit Wert angenommen hat ja auch nur in Prozent zurück. Vermutlich speichert der WR den Wert intern auch nur in Prozent und wenn der eben schon gesetzt ist (Rundungsfehlern sei Dank) dann verweigert der WR wie oben gesagt die Teilnahme und schmollt. Näheres könnte evtl Flole sagen der kennt die Firmware im Assembler Code. |
|
mein Script habe ich so geschrieben, das ich das Limit immer relativ, also in % an die DTU sende, also von minimal 15 bis maximal 100. Der Wechselrichter hat 1600W (HMS1600-4T). Auch sende ich nur ein neues Limit, wenn es sich vom alten bestätigten Limit unterscheidet. Wenn das vom Wechselrichter rückgesendete Limit sich von dem von mir zuvor gesendeten Limit unterscheidet, schreibe ich das ab heute in eine Logdatei. Wenn ich hier einen Eintrag bekomme, dann erhöhe ich den minimalen limitstep auf 2%. Das Limit regle ich nur, wenn es nötig ist, heute ist es beispielsweise sehr bewölkt, das Haus verbraucht jetzt ca. 300W, produziert werden aktuell lächerliche 78W. Da erfolgt natürlich keine Limitvorgabe, die Regelschleife läuft aktuell im Raster von 5 Sekunden, die Limitvorgabe an die DTU erfolgt aber nur wenn nötig. Das Raster von 5 Sekunden habe ich nur deshalb gewählt, weil die DTU ebenfalls im 5 Sekundenraster den Wechselrichter abfragt; ist also nicht unbedingt nötig. Heute habe ich wieder mehrere Einträge mit Zeitabgleich im Wechselrichterlog. |
|
Hallo @khschmidt
Das Event 2 kommt immer wieder mal vor, vermutlich wenn sich die Timestamps in den Commands von der DTU mit denen des WR beissen. Heute neu geflasht mit v24.10.02 und der WR hat sich beim Reset der OpenDTU jeweils ein paar Einträge im Eventlog gemerkt. Die Kommunikationsprobleme können mE von zwei prinzipiellen Ursachen kommen:
Die Radio statistics findest Du auf der Live-View Seite unten zum Aufklappen. |
|
Hallo @stefan123t, sehe ich auch so, das Thema Time calibration hat wahrscheinlich nichts mit den Kommunikationsabbrüchen/mögliche Frequenzwechsel zu tun, manchmal habe ich tagelang keine Einträge von Time calibration geshen. Ich lasse das Mitloggen der Konsole jetzt mal laufen, eventuell kommt es ja wieder zu Kommunikationsproblemen, dann sehe ich mir die Logs wieder an. |
|
Kleine Anmerkung von mir: Ich nutze keine Limitierung und das Frequenzproblem tauchte dennoch auf. |
|
Ich hab kurzzeitig eine zweite OpenDTU an den gleichen WR gehängt - das soll man ja nicht machen, aber da kein anderer WR zum Test vorhanden war hab ich es halt doch gemacht - und das hat dann prompt den Frequenzwechsel getriggert. Seriennummer | 1164a0092a30 |
|
Ich logge seit einer Woche die Konsole mit. Am Morgen beim Start des Wechselrichters sieht das so aus: |
|
Ich habe einen HMS-1600-4T und die Verbindung bricht aktuell jeden Tag gegen 11 Uhr ab. Am späten Nachmittag habe ich dann plötzlich wieder eine Verbindung. Interessanterweise ist es jeden Tag das selbe Spiel, nur sehr selten kommt zwischendrin mal kurz eine neue Verbindung zustande. |
|
Vielleicht hat es doch etwas mit dem Funk an sich zu tun? Seitdem ich bei mir die Sendeleistung deutlich reduziert habe ist völlig Ruhe. Seit Wochen. |
|
Hier die ChannelChangeCommands der Original Hoymiles DTU Pro S als Referenz: |
|
Heute ist es endlich nach mehr als 3 Wochen wieder passiert, der Inverter HMS1600-4T hat sich um 6:38:50 online gemeldet und ist um 6:57:15 offline gegangen, weil er die Frequenz gewechselt hat. Ich bekomme von meinem Script eine Meldung aufs Handy geschickt, wenn der Inverter online oder offline geht. Da heute Feiertag ist, bin ich etwas später aufgestanden und habe erst um etwa 7:50 Uhr die offline Meldung am Handy gesehen. Danach bin ich zum PC gegangen und habe die openDTU-Seite aufgerufen, der Inverter war tatsächlich offline, die Anzeige auf der DTU dunkel. Dann habe ich manuell die Frequenz des CMT2300A von 865,0 auf 865,25MHz gestellt. Sofort ist die DTU online gewesen und die Anzeige auf der DTU hat wieder die aktuellen Daten angezeigt. Folgendes ist im Logfile der Konsole zu finden: Beim von mir herbeigeführten Frequenzwechsel sieht man folgendes (File: ManuellerFrequenzwechsel): |
|
@khschmidt danke für die Logfiles in dem einen sendet die DTU einfach auf 865,00 MHz Bei dem zweiten Logfile wird auch tatsächlich das ChannelChangeCommand 0x56 fünf mal gesendet und danach klappt die Kommunikation offenbar auch wieder. Zumindest habe ich ein 0x15 DevInfo Request RealTimeRunData_Debug 0x0b mit der entsprechenden 0x95 DevInfo Response Antwort gesehen. @tbnobody wir sollten eigentlich den Inverter wieder ansprechen können wenn wir ihm das ChannelChangeCommand 0x56 auf allen Kanälen mal zukommen lassen und dann immer auf dem Zielkanal auf die Antwort warten. Wie ist das denn aktuell bei den CMT2300A Modellen programmiert. Ich habe selber kein HMS/HMT deshalb kann ich es nur anhand der Logfiles nachvollziehen. Details
|
Definiere "Alle Kanäle"? Es sind keine Kanäle definiert. Es gibt alle möglichen Frequenzen in 0,25mhz Schritten von 860,25 - 923,50. Was also ~250 mögliche Frequenzen sind. Ich sehe es gerade nicht ein hier das ganze 868MHz Band zuzumüllen. Das kann so nicht die Lösung sein. |
|
@stefan123t Beide Dateien kommen aus einem Tageslogfile. die beiden beiden Files habe ich aus diesem Logfile ausgeschnitten, da ich nur die relevanten Teile zeigen wollte. Das zweite File habe ich ausgeschnitten ab dem Umschaltbefehl von 865,0 auf 865,25 MHz. davor sind nur die Versuche den Inverter auf 865MHz zu erreichen und die jeweils 5 Versuche des ChannelChanceCommands. Bitte nicht missinterpretieren: Im File ManuellerFrequenzwechsel sieht man, dass die ChannelChangeCommands hier nichts bewirken, die Kommunikation auf 865,25 MHz ist bereits ab Zeile 7 vom Inverter bestätigt, die ChannelChangeCommands sind hier nicht hilfreich, da die Kommunikation zu diesem Zeitpunkt schon wieder funktioniert. @tbnobody Mit alle Kanäle meine ich, dass man 2 einstellbare Grenzen (zB.: von: 865,0 MHz bis: 868 MHz). Aktuell wird bei Verbindungsunterbrechung laufend RealTimeRunData gesendet (ich meine so 30 mal) und dann jeweils 5 mal das ChannelChangeCommand. |
|
@tbnobody ich will nicht das ganze Frequenzband zu spammen sondern würde mich auf die üblichen Frequenzen / Kanäle beschränken, ich muss nochmal nachlesen; es gab in der DTU Pro S FDI Anmeldung oder anderswo eine Liste der wirklich genutzten Frequenzen / Kanäle. Hier nochmal Deine Doku aus dem OpenDTU Code: OpenDTU/lib/Hoymiles/src/commands/ChannelChangeCommand.cpp Lines 9 to 18 in dc5eb96 Das ChannelChangeCommand nimmt mW nur einen Kanal und sieht keine Frequenz für die Kommunikation vor.
Die Requests werden mit 01 und 02 als Paketcounter von der DTU an den WR geschickt.
Davon ist das zweite [>15< 14] mW und auch nach Deiner Doku der Kanal, in den Logfiles von Bernhard steht an dieser Stelle >18< 14, >21< 14, >15< 14 also verwendet die DTU Pro nur jeden dritten Kanal. Schau Dir dazu doch bitte mal die Logfiles von Bernhard an, die ich hier in Auszügen angehängt habe: #2137 (comment) Die Antwort kommt nach der Trainingsphase wie üblich mit 0x80 Komplement also 0x56 | 0x80 = 0xd6 vom WR. zB: |
|
Noch eine Ergänzung zu meinen Beobachtungen: |
|
@khschmidt ich denke es ist auch wichtig die Zeit zwischen Verbindungsabbruch und dem von Dir initiierten erneuten Aufbau (mit ChannelChangeCmmand) zu berücksichtigen. Der Inverter sperrt sich bei verschiedenen Fehlern ca 10-15 Minuten lang gegen Verbindungen, erst danach reagiert er wieder auf das ChannelChangeCommand und kommuniziert dann auf dem im CCC vorgegebenen Kanal bzw dessen zugehöriger Frequenz. |
Is your feature request related to a problem? Please describe.
Mehrfach wird im Forum über Verbindungsabbrüche beim HMS 1600-4T berichtet. In einem Beitrag wird erwähnt, dass der Wechselrichter offensichtlich den Frequenzkanal wechselt und nach dem Ändern der Frequenz des CMT2300A die Kommunikation wieder funktioniert.
Describe the solution you'd like
Da nicht jeder über einen Spectrumanalyser verfügt, wäre folgende Funktion hilfreich: Ausgelöst durch einen Klick auf einen Button mit der niedrigsten erlaubten Frequenz eine Anfrage an den Inverter senden, die Antwort oder das Timeout abwarten. Bei Timeout auf den nächsthöheren Frequenzkanal schalten und so weiter. Wenn die Kommunikation erfolgreich ist, Frequenz anzeigen um sie zu speichern. Ist der Scan nicht erfolgreich, Fehlermeldung ausgeben
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: