Reku on/off
- mitpro
-
- Junior Boarder
-
- Beiträge: 71
- Dank erhalten: 33
22 Jan 2019 17:49 #166074
von mitpro
Reku on/off
Habe das Update auf dem OVMS installiert. Der Fehler tritt weiterhin auf. Es blockiert irgendwo beim "Client.Connect()", parsen oder Darstellen der Daten. Schleifen mit Endlos-Gefahr sind eigentlich nicht vorhanden. Die Klammern scheinen auch alle an der korrekten Position zu sein.. Man weiß ja nie 
Versuche es gleich weiter einzugrenzen.
Versuche es gleich weiter einzugrenzen.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- mitpro
-
- Junior Boarder
-
- Beiträge: 71
- Dank erhalten: 33
22 Jan 2019 19:12 #166085
von mitpro
Reku on/off
Irgendwie kann ich meinen letzten Beitrag nicht editieren. Deswegen ein neuer.
Der parsen wirft keine Fehler mehr. Die empfangenen JSONs, die ich mit dem PC sehen kann, sind alle valide.
Das Problem besteht bei dem websocket-client beim erhalten der Daten. Weiter differenzieren kann ich es bisher nicht.
In der Loop wird überprüft, ob der Wifi-Client noch verbunden ist. Ist die Bedingung erfüllt, wird versucht die Daten zu empfangen.In den Connect geht er noch rein, das data.length() erreicht er schon nicht mehr.
Auch irgendwie ungewöhnlich die Variable "data" an den Websocket als Variable zu übergeben. Eigentlich müsste es
data = webSocketClient.getData(); sein.. Er möchte aber gerne den Verweis auf data.. naja sei's drum.
Es lässt sich kein Muster erkennen, wann der Fehler auftritt. Öfter nach dem Anfahren, aber auch nicht immer.
Ich werde mal eine anderen Bibliothek probieren...
Der parsen wirft keine Fehler mehr. Die empfangenen JSONs, die ich mit dem PC sehen kann, sind alle valide.
Das Problem besteht bei dem websocket-client beim erhalten der Daten. Weiter differenzieren kann ich es bisher nicht.
In der Loop wird überprüft, ob der Wifi-Client noch verbunden ist. Ist die Bedingung erfüllt, wird versucht die Daten zu empfangen.
void loop() {
String data;
....
if (wsclient.connected()) {
webSocketClient.getData(data);
if (data.length() > 0) {
....Auch irgendwie ungewöhnlich die Variable "data" an den Websocket als Variable zu übergeben. Eigentlich müsste es
data = webSocketClient.getData(); sein.. Er möchte aber gerne den Verweis auf data.. naja sei's drum.
Es lässt sich kein Muster erkennen, wann der Fehler auftritt. Öfter nach dem Anfahren, aber auch nicht immer.
Ich werde mal eine anderen Bibliothek probieren...
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- mitpro
-
- Junior Boarder
-
- Beiträge: 71
- Dank erhalten: 33
23 Jan 2019 10:24 #166121
von mitpro
Reku on/off
Der Empfang der Daten ist besser geworden, Anfang und Ende sind aber teilweise immernoch verschoben.
Die Ursache des blockierens beim getData liegt in einer Schleife des Websocket.Der Clientsocket ist wohl nicht verfügbar und diese Schleife wird nie beendet.
Habe einen Zähler eingefügt und das Verlassen der Schleife veranlasst, wodurch allerdings der gesamte Client beendet wird.
Das Umschalten zwischen den Fahrwerten funktioniert weiterhin, was vorher nicht mehr möglich war.
Unter umständen hilft ein größeres Intervall, um den einzelnen Komponenten mehr Zeit zu geben. Aktuell wird alle 250ms die Funktion (im besten Fall) aufgerufen.
Die Ursache des blockierens beim getData liegt in einer Schleife des Websocket.
int WebSocketClient::timedRead() {
while (!socket_client->available()) {
delay(20);
}
return socket_client->read();
}Habe einen Zähler eingefügt und das Verlassen der Schleife veranlasst, wodurch allerdings der gesamte Client beendet wird.
Das Umschalten zwischen den Fahrwerten funktioniert weiterhin, was vorher nicht mehr möglich war.
Unter umständen hilft ein größeres Intervall, um den einzelnen Komponenten mehr Zeit zu geben. Aktuell wird alle 250ms die Funktion (im besten Fall) aufgerufen.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- dexter
-
- Moderator
-
- Beiträge: 6037
- Dank erhalten: 4222
23 Jan 2019 12:39 #166126
von dexter
Michael
Twike 3 (2001) … Emco Novum (2011) … Twizy 80 (2012) … Mii electric+ (2020)
dexters-web.de
Reku on/off
Das sieht nach einer Utility-Funktion für einen reinen Websocket-Client aus, ich würde die available()-Prüfung und -Behandlung eher in die Hauptschleife verschieben, und auf jegliche Delays verzichten.
Michael
Twike 3 (2001) … Emco Novum (2011) … Twizy 80 (2012) … Mii electric+ (2020)
dexters-web.de
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- dexter
-
- Moderator
-
- Beiträge: 6037
- Dank erhalten: 4222
07 Okt 2019 19:19 #183535
von dexter
Michael
Twike 3 (2001) … Emco Novum (2011) … Twizy 80 (2012) … Mii electric+ (2020)
dexters-web.de
Reku on/off
Danke auch nochmal für die Inspiration, meine Version hier:
→ www.twizy-forum.de/ovms/86551-ovms-v3-wificonsole
→ github.com/dexterbg/WifiConsole
…auch erst mal ohne Auswertung des Websocket-Streams. Das Arduino-Framework macht die parallele Bedienung mehrerer TCP-Verbindungen auch unnötig kompliziert, das ist eher ein Job für das FreeRTOS-basierte Espressif-IDF.
Aber nötig ist der Stream für diese Art Anwendungen ja auch nicht unbedingt, und ohne braucht das Ding auch weniger Strom.
→ www.twizy-forum.de/ovms/86551-ovms-v3-wificonsole
→ github.com/dexterbg/WifiConsole
…auch erst mal ohne Auswertung des Websocket-Streams. Das Arduino-Framework macht die parallele Bedienung mehrerer TCP-Verbindungen auch unnötig kompliziert, das ist eher ein Job für das FreeRTOS-basierte Espressif-IDF.
Aber nötig ist der Stream für diese Art Anwendungen ja auch nicht unbedingt, und ohne braucht das Ding auch weniger Strom.
Michael
Twike 3 (2001) … Emco Novum (2011) … Twizy 80 (2012) … Mii electric+ (2020)
dexters-web.de
Bitte Anmelden oder Registrieren um der Konversation beizutreten.