Neue Lade-App für den Spring

Download-Link Lade-App
​
Springcontrol-Download Webseite

So Ihr Lieben,

da ich mit der Alten App etwas unzufrieden war, besonders weil jeder seinen eigenen node-red-Server haben mußte, habe ich angefangen eine neue native App zu schreiben. Mehr Infos auch über die alte app siehe hier!
ich mache einen neuen Trööt auf weil diese App nix mehr mit node-red zu schaffen hat.

Die neue App benötigt auch einen Server, es können sich aber viele Leute einen Server teilen. So ist zumindest die Theorie:unsure:

Warum einen Server? Damit die Steuerung immer funktioniert muss eine stabile Verbindung zum Internet bestehen. Das ist mit einem Mobile nicht immer der Fall.

Ich zeige euch ein paar Screenshots der neuen App. ich habe mich dabei an der alte orientiert, die fand Ich gut.
Solltet Ihr Verbesserungsvorschläge haben, immer her damit. Die Buttons für die Ladebegrenzung sollen frei einstellbar werden. Dafür ist der Schieberegler weggefallen.
die Farben sind noch nicht endgültig, ich werde versuche es dunkler zu machen, eventuell einen eigenen Dark-Mode. Zuerst aber soll sie funktionieren.
Ich bin auf euer Rückmeldungen gespannt:)

LG Godehard
 

Anhänge

  • 1.webp
    1.webp
    12,4 KB · Aufrufe: 1.507
  • 2.webp
    2.webp
    11,6 KB · Aufrufe: 1.503
  • 3.webp
    3.webp
    12,3 KB · Aufrufe: 1.487
Zum Vergrößern anklicken....
@Godehard:
also der Dirty-Fix funktioniert bis jetzt zuverlässig - vorhin wieder "Unhandled exception" bei proxy_dacia.exe 1.3.9-139:

🔁 Start um 2025-12-05 18:11:03
App Version: 1.3.9+139 <== IST ANDROID 140
...
Unhandled exception:
ClientException with SocketException: Failed host lookup: 'api-wired-prod-1-euw1.wrd-aws.com' (OS Error: Temporary failure in name resolution, errno = -3), uri=https://api-wired-prod-1-euw1.wrd-aws.com/commerce/v1/accounts/f2971fdb-8964-4a33-8e83-b6d644fd4124/kamereon/kca/car-adapter/v2/cars/VINXXXXXX/battery-status?country=AT
#0 IOClient.send (package:http/src/io_client.dart:154)
<asynchronous suspension>
#1 BaseClient._sendUnstreamed (package:http/src/base_client.dart:93)
<asynchronous suspension>
#2 _withClient (package:http/http.dart:167)
<asynchronous suspension>
#3 DaciaBefehle.getDaten (package:daciapackete/daciabefehle.dart:256)
<asynchronous suspension>
#4 DaciaBefehle.holeBattery (package:daciapackete/daciabefehle.dart:279)
<asynchronous suspension>
#5 HoleAutodaten.holeAutoDaten (package:daciapackete/holeautodaten.dart:32)
<asynchronous suspension>
#6 AutoProfileRepository.holeAutodatenSpeicherLokal (package:daciapackete/auto_profile_repository.dart:379)
<asynchronous suspension>
#7 SequenzManager.ablauf (package:daciapackete/sequenzmanager.dart:330)
<asynchronous suspension>
#8 abarbeitungAuto (file:///home/ubuntu/StudioProjects/proxy_dacia/bin/userauto.dart:85)
<asynchronous suspension>
#9 autoIsolateEntry (file:///home/ubuntu/StudioProjects/proxy_dacia/bin/ablauf.dart:38)
<asynchronous suspension>

Du solltest diese Unhandled exception abfangen sonst bleibt proxy_dacia.exe abgestürzt hängen und macht relativ rasch die Kommunikation dicht d.h. man sieht es daher zum Glück rasch wenn das Log in der App nicht ergänzt wird.
Ich würde maximal diese Meldung im Log eintragen plus "Wiederholung in Kürze...." oder so. Beim nächsten Versuch - wenn nicht proxy_dacia.exe hängen bleibt - läuft es wieder sauber durch.

"Unhandled exception" ist 6x aufgetreten von 15:36 bis 18:36 Uhr. d.h. jedes Mal würde eine hängende Leiche überbleiben.

Ein DNS Server Problem ist auszuschließen - habe extra nun erweitert -> 3-fache Ausfalls-Absicherung: Cloudflare, Google und Quad9.
Nachdem der Dacia Server eh häufiger steht als läuft - würde ich einmal auf diesen als eventuelle Ursache tippen d.h. die Anwendung muss sicherstellen das dieser Grund abgefangen wird und nicht Crashed.

Wenn keine Kommunikation mehr möglich ist, liefert der proxy_dacia.exe einmal "20": error:

🔁 Start um 2025-12-05 02:25:12
../../runtime/bin/thread.cc: 20: error: Could not start thread dart:io EventHandler: 11 (Resource temporarily unavailable)

und dann jede Minute nur noch "348": error:
...
Starte Durchlauf Proxy
AnzahlAbfragen 0
Normaler durchlauf
AnzahlAbfrageok: true
2025-12-05 02:26:01.993987 Durchlauf Startet
Get Data 2025-12-05 02:26:02.105054
../../runtime/vm/os_thread.cc: 348: error: Could not start thread DartWorker: 11 (Resource temporarily unavailable)


d.h. dann endet auch das LOG in der App und man erkennt das der Proxy ein Problem hat.
 
Kurze Analyse zu den "Unhandled exception":
Info: Die Angabe von "App" im Log bezieht sich nicht auf die App vom Client - es soll die Version vom proxy_dacia darstellen.
🔁 2025-11-22 3x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-23 6x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-24 2x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-25 4x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-26 7x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-27 7x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-28 2x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-29 6x mit proxy_dacia Version: 1.3.7+101
🔁 2025-11-30 >28x mit proxy_dacia Version: 1.3.7+101 - exakte Anzahl ist unklar, da Proxy-System ab 6:47 Uhr hängt als Folge der Unhandled exception Abstürze vom Proxy -> ../../runtime/vm/os_thread.cc: 348: error: Could not start thread DartWorker: 11 (Resource temporarily unavailable)
🔁 2025-12-01 5x mit proxy_dacia Version: App Version: 1.3.9+131
🔁 2025-12-02 7x mit proxy_dacia Version: App Version: 1.3.9+131
🔁 2025-12-03 16x mit proxy_dacia Version: App Version: 1.3.9+131
🔁 2025-12-04 19x mit proxy_dacia Version: App Version: 1.3.9+131 2x und ab 1:08 Uhr 1.3.9+139 17x
🔁 2025-12-05 >63x mit proxy_dacia Version: App Version: 1.3.9+139 -> Dirty-Fix seit 13:36 Uhr, exakte Anzahl ist unklar, da Proxy-System ab circa 2:22 Uhr hängt als Folge der Unhandled exception Abstürze vom Proxy. d.h. von 2:22 Uhr bis 13:36 Uhr -> keine Kommunikation - nur: ../../runtime/vm/os_thread.cc: 348: error: Could not start thread DartWorker: 11 (Resource temporarily unavailable)
🔁 2025-12-06 64x mit proxy_dacia Version: App Version: 1.3.9+139 nur bis 11:25 Uhr..... da heute...


Einzig auffällig ist der sprunghafte Anstieg der "Unhandled exception" seit 5.12.2025.
Beruhigend ist das die Version 1.3.7+101 und 1.3.9+131 offenbar keinen Unterschied macht d.h. das Problem dürfte eher auf der Seite Dacia oder AWD liegen, was so oder so nichts hilft - da die sicher nicht ändern werden.

Godehard muss also diesen Fall einfach nur sauber abfangen damit proxy_dacia.exe nicht abstürzt und hängt und gut ist es.
Vielleicht kann jemand mit einem Proxy-Server sich die Logs auch ansehen und die obige Liste verifizieren um den Fehler besser eingrenzen zu können. Danke.
 
@WoodyXXL Danke für Deine Super Ausführliche Beschreibung.
WoodyXXL schrieb:
Unhandled exception:
ClientException with SocketException: Failed host lookup: 'api-wired-prod-1-euw1.wrd-aws.com' (OS Error: Temporary failure in name resolution, errno = -3), uri=https://api-wired-prod-1-euw1.wrd-a...s/
Zum Vergrößern anklicken....
Bedeutet, das der Name nicht aufgelöst werden kann oder der Host nicht gefunden wird. Mit anderen Worten: Der Server ist offline. Ich dachte, ich hätte alle fehler abgefangen, das aber anscheinend noch nicht. Ich werde die programmierung da ändern, Danke.
Die Dark-Unschaltung kann ich auch in die Konfiguration mit Aufnehmen, kein Problem.
Das Menü werde ich auch anpassen mit dem doppelten Eintrag. Ist mir bis jetzt nicht aufgefallen
Was meinst du mit "Dirty-Fix"?
Du hast recht. wenn so etwas wie "Unhandled exception" kommt, dann Antwortet der Dacia-Server nicht korrekt. Ich werde versuchen das besser abzufangen. Das Passt zum ersten Punkt.
Was du vorläufig machen kannst: Du kannst z.b. jede Stunde alle proxy_dacia Tasks killen mit folgendem Eintrag in deine crontab:
1 * * * * root sleep 50 &&pkill -f proxy_dacia.exe
So wird jede 1. Minute einer Stunde alles gekillt. Warum die sleep 50? Damit der Task, der jede Minute Läuft nicht abgewürgt wird, sondern nur die anderen. Du kannst das auch alle 15 min machen mit
*/15 * * * * root sleep 50 &&pkill -f proxy_dacia.exe

Aktuell hab ich keinen toten Tasks bei mir, hab eben nachgeschaut.

Ich werde mich erstmal um die "Unhandled exception" kümmern, dann kommt die Statistik dran.
Nochmals Danke @WoodyXXL Das hilft mir weiter.
 
Ich hab die Fehler die @WoodyXXL aufgelistet hat, (nicht das mit der Statistik und den Farben) hoffentlich behoben.
Ich werde morgen den Proxy austauschen und auch zum Download bereitstellen. Der neue Proxy sollte ohne Probleme mit der alten App zusammenarbeiten.
Es gibt auch einen neuen Menüpunkt für die Benachrichtigungen. Es sind inzwischen 6 Benachrichtigungen, da lohnt sich ein eigener Menüpunkt. Zwei Punkte sind noch nicht implementiert, das kommt aber noch.
Der neue Client kommt morgen natürlich auch. Erst einmal für Linux und Android. IOS & Windows folgen.
Das Umschalten des Modus hab ich noch nicht in Config gebracht. Das kommt noch.

Meine Erfahrung: Je weniger Kontaht man zum Dacia-Server hat, um so weniger probleme gibt es.
Eventuell mache ich das so, das der Kontakt zum Server auf alle 30 oder 60 Minuten gedrosselt wird, wenn kein Progtamm läuft.
Eventuell wird es einen zweiten Zyklus geben:
  • Einen Zyklus wenn ein Programm/Aktion läuft, also das z.B. Auto geladen wird
  • Ein Zyklus wenn nix ist
Damit ist nur die Abfrage gemeint. Wenn um 18:34 Uhr die Klimaanlage eingeschaltet werden soll, dann geht das natürlich.

Was haltet Ihr davon? Oder wird das zu kompliziert?
 
moin, gibt es eine zusammenfassende download und installationsanleitung? ich würde die ladeapp auch gerne mal ausprobieren. aber bei programmierung bin ich raus. lg
 
Godehard schrieb:
Meine Erfahrung: Je weniger Kontaht man zum Dacia-Server hat, um so weniger probleme gibt es.
Eventuell mache ich das so, das der Kontakt zum Server auf alle 30 oder 60 Minuten gedrosselt wird, wenn kein Progtamm läuft.
Eventuell wird es einen zweiten Zyklus geben:
  • Einen Zyklus wenn ein Programm/Aktion läuft, also das z.B. Auto geladen wird
  • Ein Zyklus wenn nix ist
Damit ist nur die Abfrage gemeint. Wenn um 18:34 Uhr die Klimaanlage eingeschaltet werden soll, dann geht das natürlich.

Was haltet Ihr davon? Oder wird das zu kompliziert?
Zum Vergrößern anklicken....
Hört sich für mich ebenfalls super an.
 
@onkelb Hier ist die Webseite mit Anleitung und Downloads:

SpringControl | Spring Control

Spring Control Das Spring Management System
springcontrol.ydns.eu springcontrol.ydns.eu
Bei Fragen wende Dich gerne an mich/uns.

Danke für eure schnellen Antworten. Ich werde das in Ruhe umsetzen. Es kommt also noch nicht mit der aktuellen Version raus.
 
Die neue Version 145 ist da. Für Linux, Windows, IOS, Android

Den Proxy hab ich schon umgestellt.
@WoodyXXL Zu den Versionen: Es kann durchaus sein, das der Proxy mal eine andere Version hat als die App. Das passiert dann, wenn ich eine Änderung mache, die nur ein Teil betreffen. Da sich der proxy und die App eine große Codebasis Teilen, haben sie jedoch fast immer die gleiche Version.

Was noch nicht gemacht wurde: Zeichensatzfarbe, Dark/Normal in config einpflegen, Statistik verbessern, unterschiedliche Zyklen.

Ich hoffe, ich hab nicht all zuviel kaputt gemacht 🤣
 
Godehard schrieb:
@WoodyXXL Danke für Deine Super Ausführliche Beschreibung.

Bedeutet, das der Name nicht aufgelöst werden kann oder der Host nicht gefunden wird. Mit anderen Worten: Der Server ist offline. Ich dachte, ich hätte alle fehler abgefangen, das aber anscheinend noch nicht. Ich werde die programmierung da ändern, Danke.
Die Dark-Unschaltung kann ich auch in die Konfiguration mit Aufnehmen, kein Problem.
Das Menü werde ich auch anpassen mit dem doppelten Eintrag. Ist mir bis jetzt nicht aufgefallen
Was meinst du mit "Dirty-Fix"?
Du hast recht. wenn so etwas wie "Unhandled exception" kommt, dann Antwortet der Dacia-Server nicht korrekt. Ich werde versuchen das besser abzufangen. Das Passt zum ersten Punkt.
Was du vorläufig machen kannst: Du kannst z.b. jede Stunde alle proxy_dacia Tasks killen mit folgendem Eintrag in deine crontab:
1 * * * * root sleep 50 &&pkill -f proxy_dacia.exe
So wird jede 1. Minute einer Stunde alles gekillt. Warum die sleep 50? Damit der Task, der jede Minute Läuft nicht abgewürgt wird, sondern nur die anderen. Du kannst das auch alle 15 min machen mit
*/15 * * * * root sleep 50 &&pkill -f proxy_dacia.exe

Aktuell hab ich keinen toten Tasks bei mir, hab eben nachgeschaut.

Ich werde mich erstmal um die "Unhandled exception" kümmern, dann kommt die Statistik dran.
Nochmals Danke @WoodyXXL Das hilft mir weiter.
Zum Vergrößern anklicken....
1765109073312.webp


Anbei ein paar "Leichen" wenn proxy_dacia.exe bei der "Unhandled exception" abstürzt und dies in wenigen Stunden. Das du das nicht hast kann ich mir kaum vorstellen - aber ich habe zu Linux NULL Ahnung im Gegensatz zu dir.
Ich habe Debian 12 in Verwendung:
Linux 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16) aarch64
Wenn die "Leichen" bleiben, dann wird irgendwann die Kommunikation komplett beendet mit der 2ten Fehlermeldung bei jedem Aufruf.

@Dirty-Fix: ist wie du es schon richtigerweise angedacht hast - nur bei mir etwas genauer. Exakt vor dem Aufruf erfolgt ein pfkill und DANNACH ein sleep 1 -> läuft seit meinem oben angeführten Zeitpunkt sauber durch. d.h. ich rufe proxy_dacia.exe über ein Skript auf um eine bessere Protokollierung zu haben (falls du dich schon gewundert hast woher die eine Zeile im LOG stammt).
Als LINUX Noop und bekennender LINUX Hasser kann ich nicht sagen, ob ein permanentes "Abschießen" von Task in Linux ohne Probleme bleibt - Fakt ist: bis zur 1.3.9-139 crashed proxy_dacia.exe sehr oft wegen des "Erreichbarkeits-Problem" des Servers.

Wenn du die Kommunikation STATISCH reduzierst und nur aktivierst wenn "abgefragt" wird, dann benötigst du aber eine Logik das die Abfrage beim Zeitpunkt einer "Unhandled exception" - welche dann hoffentlich nicht mehr "Unhandled" ist zumindest diesen Status im Log einträgst und dann eine Wiederholung erfolgt. Jetzt bekommst du gesichert einen gespeicherten Wert - in Zukunft kann aber auch "kein" Wert folgen, wenn gerade bei "deiner aktuellen" Anfrage der Server nicht antwortet. Ich bin mir nicht sicher ob dies nicht "schlechter" ist - oder ich habe deine Idee falsch verstanden.

Laut der Analyse der vorhandenen LOGs ist zu ~99% immer die 2te Abfrage dann OK d.h. 1 Minute später sind die Daten nun "aktuell". Jetzt ist es sehr transparent was passiert durch die Abfrage minütlich durch proxy_dacia.exe und der App wo ja jeder dies selber einstellen kann, wie oft der die Daten haben will - Standard ist ja 20. Ich habe meist 5 und 10 in Verwendung und es lief perfekt mit Proxy 101 und der App 99. (Einige Aktualisierungsfehler in der App - aber mit ein paar Mal hin und her oder Refresh oder Aus-und Einsteigen "lösbar".)

Mir persönlich ist eine einstellbare Variante - wie sie aktuell vorhanden ist - lieber. Wobei eine dynamische Abfrage bei "Nicht-Antworten" sicher eine Verbesserung darstellt.

Danke für die rasche Reaktion - wenn du die Exception abfängst ist ein Problem am Proxy-Server gelöst (zumindest bei mir unter Debian 12) - bitte um Info - dann baue ich den "Dirty-Fix" testweise aus um dir mitteilen zu können, ob es behoben ist.

Nachtrag zum letzten LOG:
6.12.2025 -> 147x "Unhandled exception" bei ~1440 Abfragen d.h. 10% liefern keine Antwort - das ist zwar sehr unschön, aber ist noch erträglich. Fakt ist: war vorher nur eine Handvoll pro Tag aufgetreten ist, tritt nun gehäuft auf. Vielleicht kann Codehard in seinem LOG nachsehen und bestätigen ob dies nur bei meinem ISP auftritt oder "generell".
Ob "wir" nun ein paar Mal weniger abfragen, wird keine messbare Verbesserung des "China-Rumänischen-Franzosen" Server bringen - ist aber nur meine Theorie.
 
@Codehard: wir haben gerade parallel geschrieben - ich werde einmal den neuen Proxy einsetzen - ohne Dirty-Fix. Das die Versionen unterschiedlich sind, dass passt schon - im Log stand/steht aber "App" daher hatte ich in einer Antwort von mir irrtümlich gemeint das dort die falsche Nummer 139 stand, da die App 140 verwendet wurde - es ist aber die Server Anwendung 139 gemeint gewesen (ich würde den Ausdruck App daher ändern auf proxy_dacia).

Wenn ich es verstanden habe: Abfangen des "Unhandled exception" ist drinnen - ansonst die bisherige Logik - das wäre fein.
 
BTW - es gibt da einen Bug im LOG in der App - bei mir wird angezeigt 9 Zeilen (1/1) obwohl ich etwas mehr habe.... siehe:
1765115153924.webp

Daher habe ich nur die ältesten 9 Zeilen im Clipboard:

05.12 21:11 Dacia-Anmeldung ok
05.12 15:08 Hole Klima Daten OK
05.12 15:08 Hole Location Daten OK
05.12 15:08 Hole Cockpit Daten OK
05.12 15:08 Batterie 38% Charging 0.0 Plugin 0
05.12 15:08 Vordergrund Button
05.12 12:12 Vordergrund Button
01.12 00:33 Token Error
01.12 00:33:39 Log beginnt

Wie du schon sehen kannst ist das Ergebnis nicht ganz das Gewünschte.
 
Die gute Nachricht:
LOG von proxy_dacia.exe -> keine "Unhandled exception" mehr - wie es sein soll. Aber der Proxy 1.3.9-145 läuft "erst" seit 14:06 Uhr d.h. bis nun 15:22 Uhr zumindest kein Eintrag mehr.
Es gibt bis jetzt auch keine "hängenden Leichen" vom proxy_dacia.exe am Server - das ist soweit gut.

um 14:17 Uhr habe ich die APP auf 1.3.9-145 aktualisiert und das sieht schon nicht mehr so gut aus - in der App Anzeige gibt es nun eine rote Anzeige:

1765115830230.webp
1765115953854.webp


Spannend ist das LOG von proxy_dacia.exe
🔁 Start um 2025-12-07 14:18:01
App Version: 1.3.9+145
Path: /home/dess/springcontrol/
Modus: normal
Type: normal
vin:
Kompression: true
/home/dess/springcontrol/springcontrol_db
AutoProfileID = XXXXXXXXXXXXXXXXXX
 Email
Starte Durchlauf Proxy
AnzahlAbfragen 1
AnzahlAbfrageok: true
2025-12-07 14:18:01.505608 kein Durchlauf
Counter Anleldung im Sequenzmanager e 3

🔁 Start um 2025-12-07 14:19:01
App Version: 1.3.9+145
Path: /home/dess/springcontrol/
Modus: normal
Type: normal
vin:
Kompression: true
/home/dess/springcontrol/springcontrol_db
AutoProfileID = XXXXXXXXXXXXXXXXXX
 Email
Starte Durchlauf Proxy
AnzahlAbfragen 1
Normaler durchlauf
AnzahlAbfrageok: true
2025-12-07 14:19:01.659736 Durchlauf Startet
Get Data 2025-12-07 14:19:01.772545
Counter Anleldung im Sequenzmanager e 3

🔁 Start um 2025-12-07 14:20:01
App Version: 1.3.9+145
Path: /home/dess/springcontrol/
Modus: normal
Type: normal
vin:
Kompression: true
/home/dess/springcontrol/springcontrol_db
AutoProfileID = XXXXXXXXXXXXXXXXXX
Email
Starte Durchlauf Proxy
AnzahlAbfragen 2
AnzahlAbfrageok: true
2025-12-07 14:20:01.385036 kein Durchlauf
Counter Anleldung im Sequenzmanager e 3

🔁 Start um 2025-12-07 14:21:01
App Version: 1.3.9+145
Path: /home/dess/springcontrol/
Modus: normal
Type: normal
vin:
Kompression: true
/home/dess/springcontrol/springcontrol_db
AutoProfileID = XXXXXXXXXXXXXXXXXX
 Email
Starte Durchlauf Proxy
Start Nachrichten
sende Nachricht Anzahl Tokens 4
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
sende Nachricht Anzahl Tokens 3
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
sende Nachricht Anzahl Tokens 0
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
sende Nachricht Anzahl Tokens 0
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
sende Nachricht Anzahl Tokens 0
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
sende Nachricht Anzahl Tokens 0
💡 Generiere neuen FCM Server Access Token...
❌ Service Account JSON nicht gefunden unter ./fcm-privkey.json.
ServerAccess = null
Keine Tokens oder FCM-Authentifizierung fehlgeschlagen. Senden abgebrochen.
Stetze AnzahlAbfrage auf 0
AnzahlAbfragen 0
Normaler durchlauf
AnzahlAbfrageok: true
2025-12-07 14:21:02.324943 Durchlauf Startet
Get Data 2025-12-07 14:21:07.554350
Get Data 2025-12-07 14:21:25.035850
Get Data 2025-12-07 14:21:25.351207
Get Data 2025-12-07 14:21:25.654047
Counter Anleldung im Sequenzmanager e 3

🔁 Start um 2025-12-07 14:22:01
App Version: 1.3.9+145
Path: /home/dess/springcontrol/
Modus: normal
Type: normal
vin:
Kompression: true
/home/dess/springcontrol/springcontrol_db
AutoProfileID = XXXXXXXXXXXXXXXXXX
Email
Starte Durchlauf Proxy
AnzahlAbfragen 1
AnzahlAbfrageok: true
2025-12-07 14:22:01.496347 kein Durchlauf
Counter Anleldung im Sequenzmanager e 3


Vielleicht sagt dir diese Token Fehler etwas - ich habe diese Meldung in meiner gestrigen kurzen Analyse zu den "Unhandled exception" glaube gerade einmal gesehen - nun habe ich nach (!!) der Installation der App 1.3.9-145 diese Meldung 3x im Log.
Seit ich die App nicht "nutze" -> LOG vom Server ohne diese Meldungen.

Anregung: Anzahl der LOG Einträge in der App erweitern (nun max. 9999) - mir schon ein paar Mal passiert, dass ich etwas "mehr" sehen wollte - sollte ja kein Problem sein, oder?

Status quo:
proxy_dacia.exe 1.3.9-145 -> perfekt (zumindest nach 1 Stunde Laufzeit) - kein Absturz mehr - keine Leichen bis jetzt dh.. "Unhandled exception" nun "handled"!

App 1.3.9-145 -> hier gibt es nun die Fehler wie oben sichtbar sind. BTW wenn du vom LOG in die Hauptanzeige zurück wechselst, wäre es sinnvoll die Daten zu aktualisieren - sonst muss "gewartet" werden.
Kann es sein, dass die "Unhandled exeption" vom proxy_dacia.exe LOG nun in das LOG der App gewechselt sind?
 
1765118110107.webp


Nun ist eine neuer Fehler aufgetaucht - nur zur Info, da er mir bis jetzt nicht aufgefallen ist. HTTP 503.

Fakt: Proxy-Server proxy_dacia.exe läuft nun sauber durch - keine LOG Einträge, nur die 2x "Token" Meldungen was immer dies bedeutet - sonst Bussi-Fein. Kein hängender Task mehr. Top.

Aber offenbar gibt es mit den Anforderungen durch die App die "Verbindungsfehler" was aber auch unlogisch ist, wenn die Abfrage durch proxy_dacia.exe jede Minuten den Server zu 100% immer erreichen kann und nur die "Abfragen" der App den Server nicht finden kann. Aber das kann sicher Godehard verstehen - da er ja den Code kennt.
Die Anzeige von Datum/Uhrzeit bei Letzter Kontakt DS bedeutet wohl: es ist seit der Anzeige keine Kommunikation mehr möglich gewesen d.h. Fehler in der Kommunikation. Die Anzeige ist wohl der letzte korrekt Kontakt mit dem DS.

1765118835757.webp


14:41 Uhr ist das Refresh Problem. LOG zeigt letzten Eintrag 15:37 - zurück -> bleibt bei 14:41 Uhr -> App beenden und starten -> Datum+Uhrzeit wieder OK.

Wurde auch etwas bei der Benachrichtigung geändert, da wir auf keinem Handy bisher eine Benachrichtigung bei "Nachricht Bewegung" erhalten haben - Laden haben wir noch nicht testen können.
 
@onkelb Keine Angst, wir bekommen das hin. Starte erst einmal die App und richte sie ein, dann sehen wir weiter.

@WoodyXXL
WoodyXXL schrieb:
Anbei ein paar "Leichen" wenn proxy_dacia.exe bei der "Unhandled exception" abstürzt und dies in wenigen Stunden. Das du das nicht hast kann ich mir kaum vorstellen
Zum Vergrößern anklicken....
Dein Netz hast ein DNS-Problem so wie es aussieht. Der Name wird nicht aufgelöst, es kommt zum fehler der nicht abgefangen wird, das programm stürtzt ab. Ich hab diese Problemenicht, sonst hätte ich das schon längst abgefangen. Du kannst das einfach malmit einem Ping versuchen. Stell den dacia_proxy-Aufruf ab und versuche mit einem Ping die Seite zu erreichen. Warte dann 20 min und versuche es wieder. Meine Vermutung: Zuerst bekommst Du einen Fehler. Eine Minute später geht es. Nach 20 Minuten wieder das gleiche. Zuerst ein fehler, eine Minute später geht es.

Du hast die Idee falsch verstanden.
Es wird immer jdede Minute geschaut ob eine Aktion gemacht werden muß
Wenn geladen wird, also eine Aktion läuft, dann wird öfter nachgeschaut, also Daten abgerufen vom Dacia-Server. Eventuell dann alle 10 min.
Wenn keine Aktion läuft, dann wird weniger oft der Server angesprochen. Eventuell alle 30 oder 60 min.
Aktuell ist es auch so, wenn Daten abgerufen werden sollen und es funzt nicht, dann wird es noch 2x hintereinander versucht. Und Es dürfen maximal 3x in 10min Daten abgerufen werden.
Ich hoffe, es ist deutlicher geworden

Um das Clipboard kümmere ich mich Danke :)

Die FCM(Firebase Cloud Messaging)-Token Fehler haben nix mit dem Dacia-Server zu tun. Der token wird benötigt um Nachrichten über Firebird von Google zu versenden. Google stellt Kostenlos einen Dienst zur Verfügung.

Jedes Mobilgerät bekommt ein Token. Wenn Nun die App neu installiert wird, dann bekommt man auch einen neuen Token. Wenn ein Token lange nicht benutzt oder bestätigt wird, dann wird der eintrag nach ca. 3 Monaten aus der Datenbank gelöscht. Meine Vermutung: Du hast durch eine Neuinstallation der App einen neuen Token bekommen, und der alte ist noch da in der Datenbank und hat keine Verwendung mehr.
Ws du machen kannst: Schau in der datenbank nach unter db_user_auth/anmledename/users.json. Für jedes Handy gibt es dort einen Eintrag unter "benachrichtigungConfig":[{"lastUpdateTime":"2025-11-25T16:26:57.379593","fcmToken":"irgendeintoken","benachrichtigeBeiAkkuVoll":false,"benachrichtigeBeiBewegung":false,"benachrichtigungKlimaStart":false,"benachrichtigungLadenStart":false,"benachrichtigungSendeKlimaStart":false,"benachrichtigungSendeLadenStart":false},{der nächste eintrag...}] Der Letzte Eintrag sollte der Aktuellste sein.
Du kannst auch den USer Löschen und Dich neu anmelden. Dann hast Du alles überflüssige weg.
Ich werde da noch etwas einbauen um über ein Button aufzuräumen.

Du kannst die Log-einträge in der app erweitern unter config. Das Problem: Je mehr Einträge Du machst, um so länger dauert die Datensyncronisation. Schalte die umfangreiche Protokollierung ab. Nun wird nicht jede Abholaktion separat aufgezeichnet, sondern für Akku, location, Km-Stand und Klima wird nur ein eintrag gemacht.

Die Hauptanzeige wird alle 30s normalerweise Aktualisiert. Das Kann in der config eingestellt werden.
Eventuell ändere ich das mal das Aktualisiert wird wenn man in das Hauptmenü zurückkommt. Es gab da Probleme, deshalb hatte ich das erst einmal nach hinten geschoben.


WoodyXXL schrieb:
Kann es sein, dass die "Unhandled exeption" vom proxy_dacia.exe LOG nun in das LOG der App gewechselt sind?
Zum Vergrößern anklicken....
WoodyXXL schrieb:
Nun ist eine neuer Fehler aufgetaucht - nur zur Info, da er mir bis jetzt nicht aufgefallen ist. HTTP 503.
Zum Vergrößern anklicken....

Ich hab die excepions nun abgfangen iund sie werden als Fehlermeldungen in das Logfile eingetragen, So haben wir eine Chance, die Fehler zu erkennen und eventuell zu umgehen. Vorher wahren die Fehler nur als Absturzmeldungen auf dem Screen zu sehen. Das ist zur Fehlersuche nicht sehr hilfreich.
WoodyXXL schrieb:
wenn die Abfrage durch proxy_dacia.exe jede Minuten den Server zu 100% immer erreichen kann und nur die "Abfragen" der App den Server nicht finden kann. Aber das kann sicher Godehard verstehen - da er ja den Code kennt.
Zum Vergrößern anklicken....
Siehe Erläuterung oben. Es wird eben nicht jede Minute der Dacia-Server angerufen. Der würde uns sofort blokieren. Es wird nur jdede Minute nachgeschaut ob etwas gemacht werden muß oder nicht. Nicht jeder Aufruf von proxy_dacia ruft den Dacia-Server an. wenn der Zyklus auf 20min Steht, dann ruft nur jeder 20 Aufruf den Dacia-Server an.
WoodyXXL schrieb:
Wurde auch etwas bei der Benachrichtigung geändert, da wir auf keinem Handy bisher eine Benachrichtigung bei "Nachricht Bewegung" erhalten haben - Laden haben wir noch nicht testen können.
Zum Vergrößern anklicken....
Siehe oben bei den FCM (Firebase Cloud Messaging)-Token.

Ich hoffe alles beantwortet und alle Klarheiten beseitigt zu haben.

Nun werde ich anfangen und Deine Bemerkungen in Code umzusetzen.
 
Achtung, Wichtiger Hinweis:

Bei mir hat die Anmeldung beim Dacia-Server nicht mehr funktioniert. Da hab ich die Zugangsdaten überprüft und beim Passwort stand dann nicht das was ich erwartet habe, sondern es stand "error" als Passwort. Also bitte das Passwort überprüfen wenn es Probleme gibt.

Zur Info: Das Passwort selbst wird weder auf dem Handy noch auf dem Proxy im Klartext gespeichert.

Wie kann es zu so etwas kommen?
Wenn die App neu installiert wird, dann wird auch zum verschlüssen ein neuer Key generiert. Der wird für die Verschlüsselung benötigt. Da der alte Key nicht mehr zur Verfügung steht, kann das Passwort nicht korrekt entschlüsselt werden. Vermutlich ist so das Problem entstanden.
 
Ich verstehe nicht viel von dem Ganzen, aber ich habe Bedenken, daß die Probleme so offen kommuniziert werden wenn das Risiko besteht, daß Dacia mitliest. Da können die dann wunderbar Blockaden einbauen. Vielleicht liege ich damit ja falsch, aber zu leicht sollte man es in die "Feindesrichtung" auch nicht machen.
 
Wenn DACIA @Godehard 's App blockieren wollten, dann hätten die das schon lange getan.
Das Knowhow zum aussperren der Anfragen, die über einen anderen Weg als die DACIA-APP kommt ist relativ simpel.
 

Empfohlene Communitys



Zurück
Oben