Script virtmeter.php [GUIDA]

[TonyP62]

Scusate ancora per il disturbo, ma vorrei segnalare e chiedere una soluzione a questo piccolo problema.
Come già richiesto tempo fa, mi piacerebbe che su Virtmeter si potessero definire i valori iniziali da cui devono partire i vari misuratori.
Cerco di spiegarmi meglio. Attualmente la mia situazione prevede che per la Produzione ci si affidi a pool123s che legge i dati dal contatore con ID2, mentre per la produzione li deve leggere dal contatore con ID1 attraverso il nuovo programma di @Garluk.
Tutti gli altri misuratori li gestisce VirtMeter (Prelievo, Immissioni e AutoConsumo). E qui nasce il problema in caso di partenza da 0. Infatti si verifica una situazione visibile nel file allegato, dove ci si ritrova con dati che probabilmente non tengono conto dei dati precedenti o non prevedono un azzeramento contatori. Quello che chiedevo a @Garluk nel post precedente era questo:
Sarebbe possibile inserire su VirtMeter una sorta di variabili alle quali sommare i dati di partenza, un po' come fa il pool123s , ossia:

Codice: Seleziona tutto

$KWHTC      = 0; // Contatore iniziale in caso di azzeramento o sostituzione inverter (si somma al valore letto)

Inserendo delle variabili tipo:

Codice: Seleziona tutto

$KWHEXP=0; // Contatore Corrente Immessa
$KWHIMP=0; // Contatore Corrente Prelevata
$KWHSELF=0; // Contatore AutoConsumo

In questo modo Virtmeter somma a questi i valori letti e non abbiamo perdite di dati precedenti o registrati precedentemente con altri driver o misuratori.

Spero sia una cosa fattibile senza snaturare l'ottimo programma di @Garluk .
Attendiamo sue risposte in merito.

Un saluto,
Tony

[Garluk]

Tutto si può fare ma in questo caso non serve a nulla.
meterN e quindi virtmeter funziona su un banalissimo principio. La nuova lettura è fatta dall'ultima lettua a cui sommo la variazione avvenuta.

Questo vuol dire che se vuoi che i meter virtuali partano da un determinato valore basta fare così:
Manda in stop meterN
Fai un backup dell'ultima riga del file csv odierno.
Cancelli tutta la cartella csv.
Fai partire meterN e lo stoppi appena scatta il minuto con finale 0 o 5.
Apri il file csv e metti in prima riga, nella colonna corrispondente i valori iniziali che vuoi che assumano i meter virtuali.
Riavvii meterN

Ovviamente ti conviene fare questa operazione subito dopo che è stato aggiornato il file csv per cui poco dopo che scatta il minuto con finale 0 o 5.

Ciao
G.

[TonyP62]

L'ho fatto svariate volte quando usavo eflow. Ma con virtmeter non mi riesce. Ambra quasi che tenga in una sua memoria i dati e al riavvio meli corregge nuovamente. Ho provato anche a cancellare i vari .jason ma non cambia niente. Questo è uno dei motivi per cui chiedevo una eventuale modifica.

[Garluk]

Mi sembra strano.
Prima di riattivare meterN dopo aver modificato il file csv ti sei accertato che nella cartella csv ci sia un unico file e che quel file ci sia una sola riga?
Prima di riattivare meterN dopo aver modificato il file csv ti sei accertato di aver cancellato i 3 file .json in /dev/shm (mN_ILIVEMEMORY.json, mN_LIVEMEMORY.json e mN_MEMORY.json)?

Ti dico questo perchè virtmeter prima controlla se trova i valori precedenti dentro i file .json e dopo legge il csv.
Per cui se meterN trova i json in /dev/shm non è detto che li rilegga dal csv quando riparte e virtmeter li trova nel json e quindi non li legge dal csv.....
Questo meccanismo e altri trucchetti sono pensati per pesare poco sulla cpu e rendere tutto più snello.
Eflow ogni volta leggeva dal csv con grande carico per la cpu....

Ciao
G.

[cosimo61]

Grazie Garluk per il tuo lavoro...
Sto seguendo anche io l'evoluzione di virtmeter e lo sto testando sul mio sistema.
Vorrei segnalare quello che secondo me è un bug dello script.
Avevo già notato degli errori di conteggio dei vari meter virtuali ma avendo tra ieri pomeriggio e oggi azzerato tutti i contatori, il problema si è rivelato in modo chiaro.
Come si vede dall'immagine allegata ad ogni lettura i meter virtuali aggiungo a volte 2 o 4 o più Wh che detto così potrebbe essere trascurabile ma poi facendo il calcolo per tutta la giornata lo sfasamento raggiunge e supera 1 KWh a seconda se si tratta dell'energia prelevata o immessa o autoconsumata.

Quello evidenziato si riferisce allo sfasamento da mezzanotte in poi, mentre quello cerchiato in rosso sui totali è stato accumulato da ieri pomeriggio ad ora.
Preciso che questo non si è mai verificato con eflow/eflowlive, la corrispondenza tra i vari meter era sempre precisa e corrispondente alla misura del contatore, per i consumi, e alle letture dall'inverter per la produzione.

La mia configurazione attuale risulta essere:

1 Consumi = poolerconsumi
2 Produzione = pool123s
3 Prelievo = virtmeter 3 0 0 impenergy 0
4 Immissione = virtmeter 4 0 0 expenergy 0
5 Autoconsumo = virtmeter 5 0 0 selfcenergy 0
6 Prelievo F1 = virtmeter 6 0 0 impenergy F1
7 Prelievo F23 = virtmeter 7 0 0 impenergy F23
8 Immissione F1 = virtmeter 8 0 0 expenergy F1
9 Immissione F23 = virtmeter 9 0 0 expenergy F23

e i relativi comandi live.

[FaManY77]

L'ho fatto svariate volte quando usavo eflow. Ma con virtmeter non mi riesce. Ambra quasi che tenga in una sua memoria i dati e al riavvio meli corregge nuovamente. Ho provato anche a cancellare i vari .jason ma non cambia niente. Questo è uno dei motivi per cui chiedevo una eventuale modifica.

Ciao Tony, anch'io ho modificato i valori totali dei contatori allineandoli a quelli del contatore Enel. Per farlo, in aggiunta a quello che ti ha già detto Garluk, io ho modificato il valore totale prima sul file mN_LIVEMEMORY.json e poi nei csv. Al riavvio tutto funziona perfettamente

[TonyP62]

L'ho fatto svariate volte quando usavo eflow. Ma con virtmeter non mi riesce. Ambra quasi che tenga in una sua memoria i dati e al riavvio meli corregge nuovamente. Ho provato anche a cancellare i vari .jason ma non cambia niente. Questo è uno dei motivi per cui chiedevo una eventuale modifica.

Ciao Tony, anch'io ho modificato i valori totali dei contatori allineandoli a quelli del contatore Enel. Per farlo, in aggiunta a quello che ti ha già detto Garluk, io ho modificato il valore totale prima sul file mN_LIVEMEMORY.json e poi nei csv. Al riavvio tutto funziona perfettamente

Grazie a tutti. Proverò con piacere anche la soluzione della modifica al .json


Inviato dal mio SM-G935F utilizzando Tapatalk

[TonyP62]

Grazie Garluk per il tuo lavoro...
Sto seguendo anche io l'evoluzione di virtmeter e lo sto testando sul mio sistema.
Vorrei segnalare quello che secondo me è un bug dello script.
Avevo già notato degli errori di conteggio dei vari meter virtuali ma avendo tra ieri pomeriggio e oggi azzerato tutti i contatori, il problema si è rivelato in modo chiaro.
Come si vede dall'immagine allegata ad ogni lettura i meter virtuali aggiungo a volte 2 o 4 o più Wh che detto così potrebbe essere trascurabile ma poi facendo il calcolo per tutta la giornata lo sfasamento raggiunge e supera 1 KWh a seconda se si tratta dell'energia prelevata o immessa o autoconsumata.

Cattura.PNG

Quello evidenziato si riferisce allo sfasamento da mezzanotte in poi, mentre quello cerchiato in rosso sui totali è stato accumulato da ieri pomeriggio ad ora.
Preciso che questo non si è mai verificato con eflow/eflowlive, la corrispondenza tra i vari meter era sempre precisa e corrispondente alla misura del contatore, per i consumi, e alle letture dall'inverter per la produzione.

La mia configurazione attuale risulta essere:

1 Consumi = poolerconsumi
2 Produzione = pool123s
3 Prelievo = virtmeter 3 0 0 impenergy 0
4 Immissione = virtmeter 4 0 0 expenergy 0
5 Autoconsumo = virtmeter 5 0 0 selfcenergy 0
6 Prelievo F1 = virtmeter 6 0 0 impenergy F1
7 Prelievo F23 = virtmeter 7 0 0 impenergy F23
8 Immissione F1 = virtmeter 8 0 0 expenergy F1
9 Immissione F23 = virtmeter 9 0 0 expenergy F23

e i relativi comandi live.

Confermo. Uno dei tanti motivi per il quale ero interessato a modificare i dati è anche questo segnalato da @cosimo61.


Inviato dal mio SM-G935F utilizzando Tapatalk

[Garluk]

Grazie Garluk per il tuo lavoro...
Sto seguendo anche io l'evoluzione di virtmeter e lo sto testando sul mio sistema.
Vorrei segnalare quello che secondo me è un bug dello script.
Avevo già notato degli errori di conteggio dei vari meter virtuali ma avendo tra ieri pomeriggio e oggi azzerato tutti i contatori, il problema si è rivelato in modo chiaro.
Come si vede dall'immagine allegata ad ogni lettura i meter virtuali aggiungo a volte 2 o 4 o più Wh che detto così potrebbe essere trascurabile ma poi facendo il calcolo per tutta la giornata lo sfasamento raggiunge e supera 1 KWh a seconda se si tratta dell'energia prelevata o immessa o autoconsumata.

Cattura.PNG

Quello evidenziato si riferisce allo sfasamento da mezzanotte in poi, mentre quello cerchiato in rosso sui totali è stato accumulato da ieri pomeriggio ad ora.
Preciso che questo non si è mai verificato con eflow/eflowlive, la corrispondenza tra i vari meter era sempre precisa e corrispondente alla misura del contatore, per i consumi, e alle letture dall'inverter per la produzione.

La mia configurazione attuale risulta essere:

1 Consumi = poolerconsumi
2 Produzione = pool123s
3 Prelievo = virtmeter 3 0 0 impenergy 0
4 Immissione = virtmeter 4 0 0 expenergy 0
5 Autoconsumo = virtmeter 5 0 0 selfcenergy 0
6 Prelievo F1 = virtmeter 6 0 0 impenergy F1
7 Prelievo F23 = virtmeter 7 0 0 impenergy F23
8 Immissione F1 = virtmeter 8 0 0 expenergy F1
9 Immissione F23 = virtmeter 9 0 0 expenergy F23

e i relativi comandi live.

Ahimè penso che non sia un bug di virtmeter ma che sia dovuto a una differenza fra le letture dei meter.
Virtmeter quando valuta un meter virtuale legge sempre l'ultimo dato disponibile per cui essendo, per esempio, Prelievi e Prelievi_F23 calcolati in momenti differenti vengono calcolati con dati differenti (per via della lettura dei meter in tempi differenti).

Anche eflow funzionava in maniera simile come daltronde funziona ogni meter in meterN. E' proprio la logica di meterN che è così. Forse con eflow non viene siete accorti perchè con uno storico lungo lo sfasamento non si vedeva....

Cmq riguarderò tutto il codice di virtmeter alla ricerca di eventuali bug e cercherò di capire se è possibile eliminare questo disallineamento.

[cosimo61]

Salve Garluk, se può essere utile ad individuare le possibili cause, posto questa nuova immagine per ribadire ed evidenziare i vari disallineamenti dei contatori che come si vede non corrispondono neanche nella differenza Produzione - Autoconsumo = Immissioni.
Posso però affermare con certezza, perché controllato più volte da me calcolatrice alla mano nel corso di due anni circa di funzionamento ininterrotto, che con eflow non succedeva: i contatori erano sempre allineati e le differenze tra i vari meter erano sempre precise, i grafici prodotti dai dati erano perfettamente sovrapponibili.
Anche virtmet di TheDrake calcolava i prelievi in F1 ed F23 in modo perfettamente corrispondente ad eflow mentre il problema con virtmeter era già evidente quando usavo il sitema misto eflow/virtmeter per fasce. Infatti sono passato ad utilizzare esclusivamente virtmeter pensando di eliminare questo problema e poi ho provato ad azzerare tutti i contatori... ma senza risultato.
Grazie ancora Garluk se avrai tempo e voglia di eliminare questo problema e perfezionare il tuo già eccellente lavoro.