Beiträge von ichwarteaufnenblauen

Ich finde, dass Beitrag #100 das schön zusammenfasst: OTA Update ME3.7 (O4B3 / O4B4) - für 3.2, 3.4, 3.5 & 3.6

Daten kopieren

Jetzt geht es ans Eingemachte: Wir kopieren die Statistikhistorie mit folgendem SQL:

insert into "statistics" (created, "start", mean, "min", "max", last_reset, state, "sum", metadata_id, created_ts, start_ts, last_reset_ts)
select created, "start", mean, "min", "max", last_reset, state, "sum", :new_id as metadata_id, created_ts, start_ts, last_reset_ts
from "statistics"
where metadata_id = :old_id and start_ts < :magic_ts;

:new_id und :old_id sind die weiter oben identifizierten Pärchen aus altem und neuen Sensor.

:magic_ts ist der oben ermittelte magische Zeitstempel.

Dieses SQL führen wir jeweils für die Pärchen aus Batteriestand und Reichweite aus. Für die Ladeleistung müssen wir W in kW umrechnen, daher verwenden wir dafür ein anderes SQL:

insert into "statistics" (created, "start", mean, "min", "max", last_reset, state, "sum", metadata_id, created_ts, start_ts, last_reset_ts)
select created, "start", mean / 1000 as mean, "min" / 1000 as "min", "max" / 1000 as "max", last_reset, state, "sum", :new_id as metadata_id, created_ts, start_ts, last_reset_ts
from "statistics"
where metadata_id = :old_id and start_ts < :magic_ts;

Das war es auch schon.

Summen werden nicht berechnet, daher müssen wir diese nicht anfassen.

Ersten Eintrag der neuen Sensoren finden

Wir wollen nur Einträge für die neuen Sensoren erzeugen für die Vergangenheit. Wir müssen also den ältesten Statistikeintrag eines der neuen Sensoren finden:

select min(s.start_ts)
from "statistics" s  
where s.metadata_id = :new_id;

min
1.731.006.000

:new_id ist ein Platzhalter für einen beliebigen der neuen Sensoren. Das Ergebnis merken wir uns als „magischen Zeitstempel“.

Sensormapping erzeugen

Über das Sensormapping wird definiert, welche technischen ID die alten Sensoren und deren neuen Gegenstücke besitzen, damit man per SQL die Historie kopieren kann.

Bei mir enthalten die alten Sensoren die Fahrgestellnummer und die neuen Sensoren den String skoda_enyaq, daher geht das mit einem SQL:

select id, statistic_id
from statistics_meta 
where statistic_id like 'sensor.tmbj%' or statistic_id like 'sensor.skoda_enyaq%'
order by statistic_id ;

id    statistic_id
277    sensor.skoda_enyaq_batteriestand
273    sensor.skoda_enyaq_kilometerstand
275    sensor.skoda_enyaq_ladegrenze_in_prozent
272    sensor.skoda_enyaq_ladeleistung
276    sensor.skoda_enyaq_nachste_inspektion
274    sensor.skoda_enyaq_reichweite
64    sensor.tmbjganzgeheim123_battery_level
63    sensor.tmbjganzgeheim123_charging_power
61    sensor.tmbjganzgeheim123_charging_rate
60    sensor.tmbjganzgeheim123_charging_time_left
62    sensor.tmbjganzgeheim123_electric_range

Daraus kann man herleiten:

1. 64 und 277 entsprechen dem alten bzw. neuen Sensor für den Batteriestand
2. 63 und 272 der Ladeleistung. Hier muss man aufpassen: Der alte Sensor misst die Ladeleistung in Watt, der neue in Kilowatt. Mehr dazu später.
3. 62 und 274 sind die Reichweite

Hallo zusammen,

In der vergangenen Woche wurde ich von einer prominenten DEPRECATION NOTICE der Skoda-Connect-Integration überrascht. Wobei „überrascht“ das falsche Wort, weil schon länger erkennbar war, dass diese Integration auslaufen wird, weil Skoda die entsprechenden API Anfang Dezember abschalten will.

Ich habe daraufhin die MySkoda-Integration installiert, die nach eigener Aussage „Alpha-Qualität“ hat, und diese funktioniert bislang problemlos. Trotz Alpha-Stadiums ist sie der alten Integration schon in einigen Punkten überlegen, so besitzen die Sensoren beispielsweise deutsche Bezeichnungen.

Einige Sensoren sind sowohl in der alten wie auch der neuen Integration vorhanden:

1. Ladeleistung
2. Reichweite
3. Batteriestand

Wer mutig ist, kann per SQL die Langzeitstatistik der Sensoren der alten Integration in die der neuen Integration kopieren. Ich zeige das in mehreren Schritten, aber vorweg: Ihr macht das auf eigenes Risiko! Ich übernehme keine Haftung, wenn Home Assistant hinterher kaputt ist oder die Katze brennt. Das ist eine Aktion für fortgeschrittene Anwender.

Zur Übersicht noch mal die Schritte:

1. Home Assistant herunterfahren
2. Backup der Datenbank erstellen
3. Sensormapping erzeugen -> separater Post
4. Ersten Eintrag der neuen Sensoren finden -> separater Post
5. Daten kopieren -> separater Post
6. Home Assistant wieder starten

Zitat von enopol

und wie sähe das in meinem Fall aus:

Der Wärmetauscher der Klimaanlage wurde auf Garantie getauscht, weil das Kühlmittel immer weniger wurde.

Welche Möglichkeit (zur Erinnerung: ich habe im Haus keine Fachjuristen inkl. KFz-Gutachter) hätte ich denn real, außer der Bitte um Kulanz, wenn der Wärmetauscher z.b. weniger als 2 Jahre nach dessen Austausch, außerhalb der Garantiezeit des Fz, wieder undicht wird?

Eine Garantie ist was anderes als die gesetzliche Gewährleistung. Bei einer Garantie bestimmt der Garantiegeber die Spielregeln.

Könnt ihr euch vielleicht mal darauf einigen, ob ihr von Garantie oder Gewährleistung sprecht? Das sind zwei völlig unterschiedliche Sachen.

Löscht mal die Handys aus dem Infotainment und umgekehrt die Autos aus den Handys. Wenn der Spuk dann vorbei ist, dann liegt es an der Handy-Kopplung.

Wenn die Reboots nach wiederhergestellter Kopplung erneut auftreten, dann hilft möglicherweise ein Zurücksetzen des Infotainments auf Werkseinstellungen. Das hat das Problem zumindest bei mir (3.2) behoben.

Zitat von eSwimmer-77

Neue Störung bei meinem Enyaq: die Sitzheizung hinten rechts steht fix aus Stufe 1 und lässt sich nicht mehr bedienen.

Heizleistung trotz Anzeige keine vorhanden, Busruhe hilft nicht.

Versuche, die Sitzheizung einmalig per Sprachsteuerung zu bedienen. Bei mir war die Sitzheizung des Fahrersitzes einst im Sommer auf Volldampf „festgenagelt“; nach einmaligem Ausschalten per Sprachsteuerung war der Spuk vorbei.

Ein Enyaq aus 2021 dürfte noch Software 2 Punkt irgendwas gehabt haben. Die wurden längst OTW auf 3.0/3.1 und dann weiter auf 3.7 gebracht.