-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Device Information ( 0x15
REQ_ARW_DAT_ALL
) SubCmd Kommandos
#145
Comments
Hi, die eigentliche Funktion ist schon implementiert.
ToDo's / Ideen für die weitere Umsetzung: R3: Parser für die InfoCmds erstellen. Wer Ansätze / Vorschläge hat bitte einfach Bezug nehmen auf die Anfroderungen R1 / R2 / R3 die m.E. zunächst notwendig sind bevor die Funktion implementiert wird. Ein aufwendigerer alternativer Ansatz -- aber m.E. der beste Weg -- wäre per git sub modul das repository https://github.com/tbnobody/OpenDTU einzubinden und dort die Quellen unter /lib/Hoymiles/* 1:1 zu verwenden. Dann wäre was das Thema / Modul Applikation <-> Inverter alles einheitlich. |
@aschiffler bzgl. R1: eine Command Queue ist für die noch anstehenden Commands von der API / UI notwendig. Sollte also eventuell auch als Liste in der UI angezeigt werden können, zumindest deren Länge.
R2: AsyncWebServer gibt es im Branch asyncWeb, es gab aber einen Merge Conflict #107, den ich offenbar nicht richtig auflösen konnte. Einziger Schwachpunkt aktuell bricht der AsyncWebServer unser OTA Update Methode. Hier wird empfohlen auf Elegant OTA zu wechseln. @lumapu ist da m.W. aktuell dran ... R3: Vielleicht können wir das schon mal nach vorne ziehen, dafür müssen die entsprechenden Strukturen zur Ablage der Daten ( |
R3: den Vorschlag die Code Basis von @tbnobody zu verwenden finde ich nicht schlecht. Das hatte ich mit dem Aufräumen der app.cpp ebenfalls vor. Leider bin ich bisher gescheitert den OpenDTU Code auf dem ESP8266 zum Laufen zu bekommen. Ich hänge immer an den Interrupt Handlern die über std::bind als Callback angebunden werden. Meine bisheriger Informationsstand ist daß das für den ESP nicht als Methode einer Klasse unterstützt wird. Man müsste die Interrupt Handler also als globale Funktionen / Methoden auslagern. Ich weiß nicht ob das wirklich ein Problem ist ? |
R3: Memory, daran habe ich gar nicht gedacht, dass der Speicher evtl. knapp wird wenn wir die ganzen Parser implementieren. |
R3: Richtig, die setCallback Methode muß public sein! |
ich hätte gerne den ESP8266 weiterentwickelt und nicht die OpenDTU kopiert - was genau ist dort aus deiner Sicht besser Aufgelöst? |
ja das liegt daran, dass du versuchst direkt auf |
This comment was marked as off-topic.
This comment was marked as off-topic.
Ich verwende fast ausschließlich OTA mit und ohne Async-Webserver |
Ich würde vorschlagen für den o.g. Scheduler und eventuell auch die Command Queue das bestehende Issue #78 zu verwenden. |
@lumapu Ja aber genau dieser Public Wrapper geht nicht wegen dem Methodenaufruf. Der Public-Wrapper übergibt dann eine Funktion app::XXXX an den PubSubClient und nicht std::func (void*) oder so ähnlich. Ich habe dazu einiges im I-Net gelesen und man müssten dann die Methode setCallback des PubSubClient anders abauen. |
ok, ich werde da auch nochmal drauf schauen, evtl. finde ich ja eine Lösung |
@aschiffler jetzt ist |
@lumapu Klasse! |
R1 ist nun erledigt. Man kann vie iv->enqueCommand(subCmd) jedes oben genannte SubCmd in die Reihe stellen. Der Parser muss dann in hmdefines.h als Byte assignment hinterlegt werden. Die geparsten Daten sind aber nur solange im array 'record' im inverter Objekt bis ein neues Kommando geparst wird. R2 ist nun Baustelle. SSE wäre mein Vorschlag. |
R2: comparison of SSE (server side events, half-duplex, ESP->Client push) vs WebSocket (full-duplex, ESP<->Client): According to Random Nerd example SSE may require ESPAsyncWebServer too, though the general effort being HTML5 seems lower: https://randomnerdtutorials.com/esp8266-nodemcu-web-server-sent-events-sse/ |
@lumapu wir hatten heute im Discord #ahoy-esp8266 diskutiert wie wir die Integration von HM- und MI-Wechselrichter weiter voranbringen können. Hier geht es ebenfalls um das Queuing von Kommandos die zum WR geschickt werden müssen und deren Antworten ausgewertet werden sollen:
Man müsste dann in den ersten beiden Fällen auch nicht mehr von MI/HM reden sondern vielleicht eher von:
|
0x15
REQ_ARW_DAT_ALL
) SubCmd Kommandos0x15
REQ_ARW_DAT_ALL
) SubCmd Kommandos
Alle zum MainCmd
0x15
REQ_ARW_DAT_ALL
bzw. dem. Device Information gehörenden SubCmd Kommandos implementieren:Subtask: #178
0x00
InverterDevInform_Simple
0x01
InverterDevInform_All
0x02
GridOnProFilePara
0x03
HardWareConfig
0x04
SimpleCalibrationPara
0x05
SystemConfigPara
Subtasks: ?
0x0B
RealTimeRunData_Debug
0x0C
RealTimeRunData_Reality
0x0D
RealTimeRunData_A_Phase
0x0E
RealTimeRunData_B_Phase
0x0F
RealTimeRunData_C_Phase
Subtask: #177
0x11
AlarmData
0x12
AlarmUpdate
Subtask: ?
0x13
RecordData
0x14
InternalData
0x15
GetLossRate
0x1E
GetSelfCheckState
0xFF
InitDataState
The text was updated successfully, but these errors were encountered: