FeatureRequest: Test-Kommunikation zwischen zwei DTU's (ohne WR)

[rg-engineering]

Ich habe hier versucht, das System aufzubauen und mit meinem HM-WR zu verbinden. Leider bisher ohne Erfolg; ich bekomme keine Verbindung zum WR. Die Fehlersuche ist etwas aufwändig, zusätzlich kommt bei mir noch hinzu, dass der WR nicht bei mir sondern 20km entfernt verbaut ist. Ich muss also für jeden Versuch dorthin :-( Meine Idee ist, ob es nicht eine Möglichkeit gibt, zwei DTU's testweise miteinander kommunizieren zu lassen. Damit könnte man am Schreibtisch prüfen, ob die Verdrahtung funktioniert, ob gesendet und / oder empfangen wird. Das würde die Fehlersuche in dieser Phase deutlich vereinfachen. Vielleicht hat das ja sogar schon mal jemand versucht?

[jimknopf63]

Ich habe hier versucht, das System aufzubauen und mit meinem HM-WR zu verbinden. Leider bisher ohne Erfolg; ich bekomme keine Verbindung zum WR. Die Fehlersuche ist etwas aufwändig, zusätzlich kommt bei mir noch hinzu, dass der WR nicht bei mir sondern 20km entfernt verbaut ist. Ich muss also für jeden Versuch dorthin :-( Meine Idee ist, ob es nicht eine Möglichkeit gibt, zwei DTU's testweise miteinander kommunizieren zu lassen. Damit könnte man am Schreibtisch prüfen, ob die Verdrahtung funktioniert, ob gesendet und / oder empfangen wird. Das würde die Fehlersuche in dieser Phase deutlich vereinfachen. Vielleicht hat das ja sogar schon mal jemand versucht?

Warum richtest Du den denn nicht vor Ort ein. Ist doch in 5 Minuten umgesetzt. Wenn Du die Verdrahtung nach dem hier gemachten Schema erledigt hast sollte das doch funktionieren. Nach dem Flash den Wemos neu starten und dann kannst Du ja schon mal am Handy sehen ob der sein eigenes Netzwerk ausspannt. Sich darauf einloggen und die Daten vom Hoymiles, Panel usw schon eintragen und abspeichern. Dann zum Einsatzort und dort wieder übers Handy mit dem Ahoy verbinden, die WLAN Einstellungen vornehmen (falls Du das zu Hause nicht schon getan hast) und im Router schauen was der Ahoy für eine IP Adresse bekommen hat. Diese aufrufen und schon siehst Du das Ergebnis.... allerdings muss es dafür noch hell genug sein und der WR produzieren. Sollte er sich nicht mit dem WR verbinden, bei mir lag das immer an der externen Antenne (trotz Kondensator). Mit der kleinen internen steht die Verbindung sofort.

[rg-engineering]

so war der Plan... Das WLAN und die Einbindung in's Netzwerk sind kein Problem. Die webUI sehe ich, aber die Verbindung zum WR habe ich nicht. und das kann viele Ursachen haben: von falscher Verkabelung bis zu defekten Funkmodulen oder Problemen mit dem WR. Ich wollte soviele Ursachen wie möglich vor dem nächsten Vor-Ort-Einsatz eliminieren...

[jimknopf63]

so war der Plan... Das WLAN und die Einbindung in's Netzwerk sind kein Problem. Die webUI sehe ich, aber die Verbindung zum WR habe ich nicht. und das kann viele Ursachen haben: von falscher Verkabelung bis zu defekten Funkmodulen oder Problemen mit dem WR. Ich wollte soviele Ursachen wie möglich vor dem nächsten Vor-Ort-Einsatz eliminieren...

Ob das Funkmodul richtig angeschlossen ist und funktioniert siehst Du doch auch ohne Verbindung zum WR in der Systemübersicht. Wenn da alles ok ist kann es nur am WR liegen bzw. vertippen bei der Eingabe der SN des WR

[rg-engineering]

Ob das Funkmodul richtig angeschlossen ist und funktioniert siehst Du doch auch ohne Verbindung zum WR in der Systemübersicht.

"is connected" hatte ich gesehen. heisst doch aber nur, dass das Com-Interface zum Funkmodul funktioniert. ich bin mir nicht sicher, ob man daraus 100% ausschliessen kann, ob nicht doch irgendeine der Leitungen (z.Bsp. IRQ) ein Problem hat. Auf RF-Seite sieht man die Paketzähler, bei mir hatte sich nur TX count erhöht, also wurde nichts empfangen...

Wenn da alles ok ist kann es nur am WR liegen bzw. vertippen bei der Eingabe der SN des WR

SN des WR hatte ich x mal geprüft... und dann war es zu dunkel ....

[jimknopf63]

Ob das Funkmodul richtig angeschlossen ist und funktioniert siehst Du doch auch ohne Verbindung zum WR in der Systemübersicht.

"is connected" hatte ich gesehen. heisst doch aber nur, dass das Com-Interface zum Funkmodul funktioniert. ich bin mir nicht sicher, ob man daraus 100% ausschliessen kann, ob nicht doch irgendeine der Leitungen (z.Bsp. IRQ) ein Problem hat. Auf RF-Seite sieht man die Paketzähler, bei mir hatte sich nur TX count erhöht, also wurde nichts empfangen...

Wenn da alles ok ist kann es nur am WR liegen bzw. vertippen bei der Eingabe der SN des WR

SN des WR hatte ich x mal geprüft... und dann war es zu dunkel ....

Wenn Du dich da versteckt hast bei den IRQ steht da eine Fehlermeldung und man soll die Verkabelung überprüfen. Habe mich am Anfang mal vertan und da kam so eine Meldung sinngemäß. Nachtrag... hast Du auch im Einstellungsfenster Inverter oben links den Haken gesetzt bei "Communication Enabled"?

[Loetnase]

@rg-engineering möchtest du öfters eine DTU aufbauen und testen? Dann leg dir doch einen kleinen HM-WR zu, welchen du mit einem einstellbarem Netzteil am Solarmoduleingang mit Spannung versorgst. Einfach die Spannung langsam hochdrehen bis der WR aufwacht und zu arbeiten anfängt. Dann kannst deine DTUs testen und bist sogar unabhängig vom Sonnenschein. Dazu noch die Zeitsteuerung passend einstellen. Ich habe irgendwo mal eine gute Anleitung gelesen wie man das genau macht und was das Netzteil können muss. Vielleicht weiß jemand wo das steht und kann hier einen Link einstellen.

[stefan123t]

Die Option einen WR zu simulieren mit einer zweiten DTU ist an sich schon ganz interessant: So ließen sich u.a. auch die ganzen Anpassungen am Code überprüfen. Ich weiß nur nicht ob wir neben dem DTU Code auch noch den WR Code implementieren können. Allerdings wäre es ein prima Mock-Up um dann automatisierte Tests auch bei Nacht bzw. ohne WR durchzuführen.

[rg-engineering]

Im ersten step würde es mir reichen, wenn es einen Modus gäbe der:

• regelmässig Daten sendet (vielleicht mit der IP oder dem Namen der DTU im payload)
• auf o.g. Daten reagiert wird (z.Bsp. in's log schreiben) Wenn zwei DTU's in dem Mode sind, zeigen sie "über Kreuz" die jeweils gesendeten Telegramme des anderen an.

Das könnte man natürlich dann weiter ausbauen, das automatisierte Testen bzw. Testen bei Nacht hätte sicher auch seinen Charm...

[stefan123t]

@lumapu was hältst Du von so einem Test- / Echomodus ?

[lumapu]

viel, aber leider ist zZ. meine Zeit stark begrenzt und ich will bei HMS unbedingt weiterkommen

[rg-engineering]

ich kann versuchen, hier etwas in der Richtung zu implementieren. Benötige aber Hinweise, wo man diesbezüglich ansetzen könnte oder sollte...

[stefan123t]

@rg-engineering eigentlich würde es ja genügen, wenn der Dummy-WR einfach nur irgendwelche statischen oder Random Werte zurückschickt. Beispiele gibt es im Wiki unter Protocol. Als WR-Serial ID würde auch irgendein Dummy ID passen: z.B. 114180112345 je nachdem welchen WR Typ man simulieren möchte schickt er dann HM-300..500, HM-600..800 oder HM-1000..1500 payloads zurück. Beispiele und Traces sollten entweder in Deiner AhoyDTU auf der Serial Console sichtbar sein bzw. im Wiki unter > Traces angehängt sein.

Die aktuell hierfür genutzten Kommandos werden in hmInverter.h app.cpp bzw. RestApi.h / web.h abgesetzt:

• enqueCommand<InfoCommand>(InverterDevInform_All); InverterDevInform_All | 0x01
• enqueCommand<InfoCommand>(SystemConfigPara); iv->enqueCommand<InfoCommand>(SystemConfigPara); // read back power limit SystemConfigPara | 0x05
• enqueCommand<InfoCommand>(RealTimeRunData_Debug); RealTimeRunData_Debug | 0x0B
• //enqueCommand<InfoCommand>(AlarmUpdate); // What is the function of AlarmUpdate? enqueCommand<InfoCommand>(AlarmData); Wie sieht das Device Info Kommando Alarm Data 0x11 / Alarm Update 0x12 aus ?
• iv->enqueCommand<InfoCommand>(jsonIn[F("val")].as<int>()); iv->enqueCommand<InfoCommand>(cmd); Welche Device Control DEVCONTROL_ALL (0x51) Sub Kommandos gibt es