Come programmare ricarica Twizy per reintegrare quanto consumato

[Myo900]

Codice: Seleziona tutto

 if ((handShakeStep == 8) && (lastResponseOK == 1)) {
    // Abbiamo la risposta del SoC, procediamo
    // 155 07 97 cf 54 71 78 00 70 - 155 07 97 - header, cf - footer
    // 71 78 - valore in esadecimale, da convertire in decimale
    String SoC = elmResponse;
    SoC.replace("155", "");
    SoC = SoC.substring(9, 14); // Estrai i caratteri dal decimo al quattordicesimo
    
    unsigned long SoCl = 0;
    char SoCc[5];
    SoC.toCharArray(SoCc, 5);
    SoCl = strtol(SoCc, NULL, 16);
    float SoCf = SoCl / 400.0; // Dividi per 400 invece di moltiplicare per 0.02
        
    webSocket.broadcastTXT("SoC: " + String(SoCf, 2));
    snprintf (msg, MSG_BUFFER_SIZE, "%3.2f", SoCf);
    mqtt_reconnect();
    mqtt.publish("elm327report/result/SoC", msg, true);

    // Report di successo, continuiamo con il prossimo passo
    
    handShakeStep = 101;
    lastResponseOK = 1;
}

Ho corretto il codice

Chiedo scusa per gli errori di scrittura, scrivo sempre con il cellulare e avvolte non so cosa scrivo

[Maico]

Perfetto Enzo,
non hai levato gli spazi ma l'hai fatta tornare comunque
direi obiettivo raggiunto !!!

Ciao Maico

p.s. ottima gestione dei commenti.... tutto molto chiaro e comprensibile

[Myo900]

Ciao @Maico

Ti volevo chiedere possiamo tirare fuori altri dati dal comando ATCRA155 ?

Da questa stringa 155 07 97 CF 54 75 80 00 70

Non so voltaggio batteria , ampere ?

Grazie un saluto Enzo

[Myo900]

Aggiornamento.

Ora i dati vengono letti e convertiti correttamente.

MQTT riceve il Soc della batteria allineato con quello della twizy.

Ho apportato alcune modifiche al codice, le modifiche fanno in modo che alla stringa di dati ricevuti dal comando ATCRA155 e successivamente da ATMA , Vega eliminato il prefisso 155, vengono eliminati gli spazi tra i byte e estratti solo le due coppie di byte che interessano, convertiti in decimali e divisi per 400.

Ho inserito anche un paio di righe di codice con output di terminale del’lIDE , così si possono leggere i byte presi in considerazione e anche la conversione dei dati con il risultato in % Soc .

C’è da risolvere ancora.

1- eco di risposta del comando ATCRA155 , la risposta contiene molte volte la stringa .

2- succede poco, e ad oggi non riesco a individuare il motivo una disconnessione dall’adattatore obd , per poi riconnettersi nuovamente e inviare dati.

3- sembra che i dati convertiti e inviati a MQTT arrivino molto lentamente, ma forse ho trovato il motivo farò dei test.

Cercherò di inserire anche il SOH della batteria,avendo grazie a @Maico gia il comando AT e il byte de prendere, e poi sarebbe bello inserire ampere della batteria e kWh caricati.

Un saluto Myo900

IMG_4471.jpeg (127.91 KiB) Visto 477 volte

IMG_4472.jpeg (127.21 KiB) Visto 477 volte

[Maico]

Ciao Enzo,

ottimo che fai progressi

ti rispondo solo ora perche' prima non ho avuto tempo....
mi sa che ti stai "imbarcando" in un lavoro "lungo"... ma so che e' la "passione" e la voglia di farsi da solo le cose che "traina" questi "hobby", si "fanno le notti in bianco", ma alla fine "il piacere" di veder funzionare le cose funzionare e' tanto....
domani vedo di mandarti qualche ulteriore "info" che possa esserti utile....

Tu intanto costruisciti una "base stabile e funzionante" da utilizzare per acquisire informazioni di vario tipo.... il resto "poi arriva"

Ciao Maico

[Maico]

..........

Cercherò di inserire anche il SOH della batteria,avendo grazie a @Maico gia il comando AT e il byte de prendere, e poi sarebbe bello inserire ampere della batteria e kWh caricati.

Un saluto Myo900

Ciao Enzo,

come promesso ti allego "la bibbia" dei dati che passano sul CanBus della Twizy ( che poi e' quella che ho consultato io per realizzare la mia apk ), con i "dettagli" per la loto interpretazione..... e' in tedesco, ma si sa, non tutto e' sempre a "portata di mano" ma so che questo piccolo problema, non ti fermerà

si tratta di una "mole gigantesca" di dati la cui gestione non sarà rapidissima ( dovrai decidere a quale informazioni dare priorità, così da "gestirle prima di altre" ) per quello ieri ti anticipavo che ti stavi "imbarcando" in un lavoro lungo ma con calma e senza fretta si fa tutto

spero di avert fatto "cosa a te gradita" .

un saluto

ciao Maico

Twizy-CanBus.pdf

Lista dei Messaggi CanBus della Twizy con "interpretazione" dei dati in essi contenuti

(313.75 KiB) Scaricato 11 volte

[Myo900]

Ciao @Maico

Grazie davvero , perfetto ho dato subito un occhiata al file.

Senza le tue spiegazioni sui byte da prendere in considerazione alle risposte dei comandi AT , non sarei stato in grado di interpretare il pdf .

Oggi primo test ricarica con assistenza Home Assistant.

Per il momento solo un avvertimento vocale con l’assistente Google, che mi notifica il raggiungimento della carica desiderata.

L’esp comunica con la presa obd , quando l’auto è in carica o se il quadro è acceso.

Il processo di monitoraggio della carica si è svolto in modo perfetto, ho modificato il codice per far sì che i dati arrivino con aggiornamento ogni secondo.

Provo con calma a vedere qualcosa di utile del pdf che hai allegato, non voglio riempire Home Assistant di sensori ma solo quelli più utili durante la ricarica.

Un saluto Enzo

[Myo900]

Ciao a tutti.

Il codice per il controllo della carica è completo, ho avuto problemi per quanto riguarda la ricezione dei dati , avvolte risultavano picchi in alto e in basso della carica , sono riuscito ad eliminare i picchi in alto , resta solo qualche picco in bassa ma raramente, non riesco ad eliminare questo errore.

Ora sto montando la presa con esp32 e alimentazione dedicata .

Quando sarà tutto funzionante posterò i componenti utilizzati.

Credo che la ricezione dei picchi dipenda dal fatto che avvolte la risposta ricevuta sia differente da 155 XX XX XX XX XX , avvolte c’è un prefisso esadecimale , ho cercato tramite codice di estrapolare solo la stringa che inizia con 155 essendo l’unico dato fisso di tutta la risposta.

@Maico

Non so se tu hai qualche suggerimento in merito.

Buona giornata Enzo

[Maico]

ciao Enzo,
non so se ho compreso perfettamente quello che stai dicendo ma provo comunque a risponderti .
se quanto mi dici ti succede dopo aver settato il filtro ATCRA155, ti confermo che sempre e solo 155 xx..... dove arrivarti. Sul canbus non possono viaggiare "messaggi anomali/inaspettati" potrebbero mandare in crisi qualche centralina .
Il messaggio canbus 155 arriva ogni 10 millisecondi e avendolo filtrato NON puoi avere messaggi canbus che si alternano con tempistiche inferiori .
Pensa che non impostando il filtro potresti ricevere altri messaggi ogni 10ms come ogni 20ms, come ogni 100ms, come ogni 1000ms, quindi un "delirio di dati".
L'adattatore odb2 che "utilizziamo" e' perfettamente in grado di gestire la ricezione di TUTTI i messaggi che viaggiano sul canbus "senza filtri" e quindi ancora piu in "sicurezza" impostando "i filtri", ovviamente questi dati devono essere "gestiti/smaltiti" con le tempistiche giuste e quindi il principale "problema" in cui potresti incorrere e' il buffer overflow/overrun ed a quel punto, ti si potrebbe presentare qualunque tipologia di dato ( tra cui il problema che hai )
Il Messaggio 155 non presenta problematiche, cosi come tutti gli altri e quindi il SoC NON puo avere "spike".
Detto questo , spero di averti dato "qualche spunto di riflessione"

complimenti per il tuo lavoro e la tua perseveranza

un saluto

ciao Maico

[Myo900]

Ciao @Maico

Sì la risposta è 155 XX , ma avvolte vedo da terminale che prima di 155 nella risposta appare F , ho cercato di filtrare il più possibile, ma non so perché ho questi picchi di lettura in basso tipo -45%

Quello che ho fatto é stato indivuare 155 dopo averlo individuato prendere i 24 caratteri che compongono la risposta, elimino 155 e limino gli spazzi ed estraggo la coppia di caratteri che servono per calcolare il soc.

Non sono un grande programmatore, come sai , più di così non riesco, c’è da dire che funziona anche perché i picchi in basso non influenzano la carica.

Se riesco in questi giorni monto la presa volante per fare test , vorrei anche implementare un display oled con due pulsanti per regolare il livello di carica indipendente da Home Assistant .

Penso che sia utile averlo separato per qualcuno.

Hai perfettamente ragione sul buffer , uno dei problemi infatti è questo, avvolte succede.

Un altra cosa che aggiungerò alla presa é un sensore di hall , per attivare L’esp e l’alimentatore solo all’inserimento della presa .

Un saluto a tutti

Enzo