Grazie mille. Provvedo..

Non do mai nulla per scontato quindi i tuoi suggerimenti sono sicuramente ben accetti ... il viaggio è ancora lungo e le ottimizzazioni tantissime ... :-)

Per la gestione del dato, la suite TICK (Telegraf, InfluxDB, Chronograf e Kapacitor) dovrebbe mettere a disposizione tutto il necessario ...
Tra l'altro a breve uscirà la versione 2.0

InfluxDB 2.0: Complete Time Series Toolkit | InfluxData

dove essenzialmente la ICK verranno collassati in un unico binario hassle-free: e con un docker ancora meglio !
E forse si potrebbe fare a meno anche di Grafana visto che implementerà una UI tutta sua

https://v2.docs.influxdata.com/v2.0/...ization-types/

Nonostante tutto, i grafici che servono sono abbastanza basilari ...
Vedremo ... in ogni caso Grafana non è così impattante sul sistema ... è un modulo relativamente leggero e sicuramente più robusto e supportato.

Ah ok ! :-)))
E si .. anch'io finchè non me lo hanno attivato ho potuto fare pochino ...

Ottimo influxdb2, daltronde il passo per una roba unificata era molto breve.
Dato alla mano tirare giù qualsivoglia dashboard o report (grafici ed analisi) è immediato con diversi tool

Ciao a tutti,

un piccolo avanzamento ...

Giusto per dare un'idea, questo è stato l'andamento di 2 giorni fa, una bella e costante giornata di sole (già postato sul thread Shelly, ma lo riposto qui per completezza):




con solo i due valori SDM_CS e SDM_FV ottengo 3 curve.
In rosso il reale consumo che è PRODUZIONE (linea gialla) + SCAMBIO (linea verde).

Quando la linea verde è sottozero sono in autoconsumo per il valore della linea rossa ... si può vedere come la linea verde, quando è maggiore di 0 indica un prelievo e quindi non sono più in autoconsumo.

Mi piace tantissimo quando la linea rossa e la verde sono identiche e sovrapposte e piano piano nell'arco della giornata divergono fino poi a riunirsi a fine giornata ...
Volendo potrei facilmente creare anche un grafico dell'autoconsumo ma forse sovraccaricherei troppo il disegno ... già così a colpo d'occhio di vede quando e quanto sono stato in autoconsumo.

Adesso arrivano i dolori ... mi sto convincendo, ogni volta che approfondisco Grafana, che forse non è lo strumento migliore.
Mentre InfluxDb al momento non perde colpi, quella è la fonte di ogni elaborazione.
Per rispondere a SolarByte e dove scaricarli. Al momento Influx crea tutti i sui dati in una cartella del sistema:


















(aprila per vedere il dettaglio)
La cartella è esterna al Docker dove gira Influx ed è fisicamente sulla macchina "host", ovvero il Rasp. Questo volume sarà poi facilmente spostabile su un disco esterno o addirittura via NFS su un altro server. Avremo modo di approfondire il discorso Docker e configurazioni varie più avanti.

Il problema ad oggi è Grafana.
Già ho avuto problemi a fare il grafico di cui sopra, grazie all'aiuto di raffaelem si è trovata una quadra ...
Adesso mi sono lanciato sui grafici a barre ... ma credo che anche qui ancora non abbia capito bene la logica ...

Ne parlo nel prossimo post.

Qui sotto un primo esempio di barre:



Si riferisce ai soli dati di produzione e la timeline è "last 7 days"

Dopo un pò di ricerche ho trovato la formula da usare ... la momento è:

La funzione chiave è integral, e pare funzioni bene. Divido 3600 secondi per campionare l'ora. Raggruppati poi in 24h.

Ci sono però vari problemi:

1) come vedere le barre sono a cavallo della mezzanotte ... io risultato è che mezza barra visualizza il giorno precedente e l'altra metà il successivo ... boh !
2) i totali sono abbastanza corretti, ad esempio l'ultima barra più alta, quella sopra il "2/28 00:00" (la parte destra) visualizza 21,65 kwh. Se però vado sull'app SolarEdge mi dice che ho prodotto 21.83. Temo che sia dovuto al fatto che quando l'interver non produce, consuma energia ... quindi mi consuma circa 5w all'ora che credo vengano conteggiati nel conto totale ... anche se a ben vedere 5wh per le circa 13 ore di non produzione dovrebbe dare 5*13 = 65wh .... al che non quadra lo stesso ...
3) non capisco come creare delle viste che siano "ultimo giorno, ultima settimana, ultimo mese ecc" e la possibilità di scorrere avanti indietro nei giorni o mesi INDIPENDENTEMENTE dalla timeline degli altri pannelli. Infatti come visualizzato come nell'immagine sopra, ovvero le barre degli ultimi 7 giorni, ovviamente si spostano anche gli altri grafici ... cosa che ovviamente non voglio. Forse devo creare delle dashboard diverse ?

I dubbi sono tanti. Ammetto però che devo ancora approfondire la presenza di eventuali plugin o altre possibilità.
E' però un pò frustrante in quanto ogni volta che si cercano commenti viene detto "Grafana non supporto questa funzionalità, non ha questa capacità" .... uff.

Nel frattempo oggi mi dedico a proxare Grafana tramite reverse proxy ... lasciando aperta la porta 3000 col port-forward in molti posti (aziende) i loro proxy non la lasciano passare col risultato che devo sempre e solo collegarmi via connessione dati del cellulare ... proxando tutto sulla 80 non dovrei avere problemi ... ovviamente indovinate un pò ? E' un bel pò complicato anche questo ! Ma qui la colpa non è di Grafana ma dell'Apache che ho su Windows .... l'ideale sarebbe configurare un HAProxy direttamente sul Rasp, ma ho anche altre cose già proxate che al momento non vorrei spostare ...

Gli altri dati : tensione CA (importante se poi avete problemi di stacco per produzione alta) , tensione e corrente CC , li loggate ?

Heam ... onestamente non saprei ... questi sono tutti i dati che restituisce l'SDM e che loggo, così come sono, su Influx

Ci sono questi valore che tu indichi ?

Sei in monofase o trifase ? le tensioni CA sono le ultime voltage , come detto sono importanti per vedere in che range di tensione di rete operi....
dall'SDM non hai i parametri di stringa CC , quelli vanno letti direttameten da inverter , non sò se si possono leggere da SE, ma immagino di si.

Risolto il problema del proxy.

Bisognava impostare sul file di configurazione di grafana il path corretto definito sul proxy (nel mio caso domino/grafana)

L'unico inconveniente è che anche da dentro casa devo usare l'url del dominio esterno, cosa che con certi router e/o configurazioni di router, non funziona. Nel mio caso però non ho questo problema.

Un amministratore di rete che si rispetti non lascia porte non standard aperte sul firewall per far giocare noi con grafana...

No, sono in monofase ma l'applicazione Mbmd è predisposto per lavorare anche con gli SDM630 che sono trifase, quindi li considera di default e ne crea la code sul db.

Mbmd legge anche direttamente da Solaredge, come dicevo alla pagina precedente a questa, e questi sono i valori:

Al momento ancora non li carico perchè dopo un primo tentativo di lettura da SolarEdge avvenuto correttamente, mi ha poi dato dei problemi.
Devo approfondire meglio ...

Vedo che anche a te le barre le mette sulla mezzanotte .. immagino anche a te siano quindi splittate sui due giorni :-(

Allora avevi tutto leggendo SE , anche i valori in CA
Anche se meno importanti con gli opti , perchè tanto più del poco che fanno loro non puoi fare , vedere tensione CC (ma nel SE è ininfluente visto che dicono mantiene sempre il valore nominale di 360V) e corrente CC dà indicazioni importanti se e come intervengono ombre , soprattutto su mpianti non ottimizzati e di come lavora la funzione "antiombre"

Mò li ho fregati ... ;-)

Si, volendo potrei fare a meno dell'SDM che mi conta la produzione e leggere direttamente da SE ... però è un tipo di collegamento un pò più delicato (Modbus via TCP) che devo testare bene prima di switchare ... e i primi test non sono stati molto confortanti ... il Rasp è in Wifi e potrebbero esserci sempre dei problemi ... per ora uso ancora l'SDM, poi vedrò o comunque provo a usarli in parallelo ... tanto la mole di dati è risibile...

glfp l'SDM racconta tutto, guarda qui quanta bella roba dice al Raspy:

Voltage: 230.08 V
Current: 0.73 A
Power: 161.23 W
Active Apparent Power: 168.02 VA
Reactive Apparent Power: -47.28 VAR
Power Factor: 0.96
Phase Angle: -16.34 Degree
Frequency: 50.01 Hz
Import Active Energy: 6140355 Wh
Export Active Energy: 0 Wh
Total Active Energy: 6140355 Wh
Import Reactive Energy: 52863 VARh
Export Reactive Energy: 1243990 VARh
Total Reactive Energy: 1296853 VARh
OK

Questo è un SDM muletto (è dislocato in altro luogo), quello ufficiale in abbinata con 123Solar ormai non riesco più a leggerlo, ma per fortuna MeterN ci riesce.

beh sì, ma perché tu cosa vorresti fare di preciso?

Bhe, in primis che non visualizzi 00:00 e 12:00 ma solo il singolo giorno.

Di conseguenza sperare che non splitti i valori sulle due metà.

Se hai bisogno di questo genere di dato ed in generale di elaborazioni più ad alto livello io credo che dovresti passare ad un dbrms di livello superiore, una istanza mysql non ti schianta certo il raspi ed hai a disposizione il mondo rispetto all'essenzialità di influxdb.
Roba del genere la fai con una banale vista che poi fai "ciucciare" a Grafana

Oppure usare uno strumento di reportistica anziché uno per i dati realtime come Grafana per farla

Bella la sperimentazione e tutto il resto , ma scusate se lo ripeto , perchè non usate un logger che ha già tutto ?
guardate qui pe esempio Emoncms Emoncms - dashboard view consumi divertitevi a ascorrere tra i grafici , allargarli fino all'annuale , stringerli ,etc cliccate in alto sulle stelline e vi si apriranno altri scenari ... ho trovato lui che è un utente del forum anche se monitora solo le grandezze elettriche potete estendere a tutte le temperatre, etc che volete

li non c'è nessun grafico con + variabili ma è semplicissimo da fare ....

Influx è già di un livello superiore a MySQL per questo genere di dati ... prima o poi MySQL scoppia con dei time series, non è fatto per questo use-case.

Qui il problema è solo la mia ignoranza su Grafana ... pensavo fosse più malleabile, ma sono io che ho dei problemi in generale con le dashboard e la gestione dei dati.

Influx permette di creare delle viste raggruppanti ... lavorerò su quelle.

Si, in effetti questo è quello che dovrebbe fare.

@glfp non scherziamo adesso, influxdb è un giocattolo (non ha nemmeno tutto l'SQL ANSI) rispetto a mysql o postgresql... non so dove abbia visto scoppiare l'uno o l'altro ma non si tratta del pianeta terra

@spider guarda non è che si stia faticando più del dovuto (a parte la battaglia di @glfp con le dashboard), io personalmente mi trovo bene con una cosa del genere e farlo non è più complicato di emoncms


poi altre robe le faccio con R/Rstudio ma solo per deformazione professionale ad esempio questi sono i dati di mandata media sui 10 minuti, la linea nera nei box è la mediana e l'area del box rappresenta il 75% delle osservazioni. Per il 19/02/2020 la PDC è stata accesa 510min, per il 75% dei quali con mandata compresa tra 35° e 36.5°, metà delle osservazioni sopra i 35.5° e metà sotto...

E che emoncms una volta stabiliti gli inputs , i feeds , ti fai i grafici e chiuso questo è il mio odierno delle T con un solo click allargo o stringo la visuale posso vedere annuale , 1 mese , 1 ora o tutto il tempo da quando sono partito... i puo mandare sul server loro, ma io sono molto riservato e faccio tutto in locale, mi è saltata a volte corrente , spento etc, non ho mai perso un dato sul rasp...
va be io lo dicevo per voi......

Ma certo, ce lo avevo ed è ottimo, nulla da eccepire.

Grafana fa lo stesso soltanto che non si spippola la gestione del dato come fa Emoncms quindi devi appoggiarti altrove. Ma questo è anche un punto di forza perché io ad esempio prendo il dato di temperatura esterna dalla stazione meteo della protezione civile locale e lo butto su un db diverso (mysql) per motivi che non sto a spiegare ma posso tranquillamente sovrapporlo (come nel tuo grafico).

Diciamo che Grafana è orientato ad un pubblico di poco più nerd. Cioè, qui siamo con due tabelline al massimo, roba da file di testo quasi... ma se vai su progetti più complessi Emoncms è spacciato.

Heam ... stiamo parlando di capre e cavoli ... sono 2 prodotti MOLTO diversi.
Influx non ha l'SQL Ansi perchè ricade nella famiglia dei cosiddetti "NOSQL" ... altre tipologie di NOSQL (es: ElasticSeach, Neo4J, Hadoop) non hanno neanche quello pseudo SQL che ha Influx ... quello è un di più che non era dovuto ma probabilmente inserito per facilitare l'accesso ai dati, cosa che in effetti lo è.

Ti ricordo che io sto campionando i dati ogni 5 secondi, e se la matematica non mi inganna sono 12 campioni al minuto * 60 * 24 * 365 = 6.307.200, da moltiplicare per due o per N a seconda di quanti SDM uno possiede. Ti immagini 12.614.400 record su un MySQL (ma anche su Oracle ....) per ogni anno ?

Influx è ottimizzato per questo caso d'uso... lui si crea in automatico degli shard di dati ognuno con segmenti di tempo diversi visto che raramente si va a lavorare su tutti il periodo dall'inizio alla fine ... ti immagini partizionare tabelle RDBMS per anno o per mese ? Impossibile.

Già qualche anno fa feci migrare un cliente da MySQL a Influx proprio in uno scenario simile ... lui poi non usò Grafana ma query dirette dal suo applicativo ... ovviamente gli cambiò la vita e io mi meritai una successiva consulenza ;-)

Poi qualcuno potrebbe sindacare che un campione ogni 5s è troppo ... va bene, parliamone ... io sono stato il più conservativo possibile ... :-))

A presto !

Quella mole di dati non è un problema per MySQL o PostgreSQL ma occorre un server vero non un raspino.
Che poi Influxdb ce la faccia con 12milioni di recordo (su raspi però eh) ce lo racconterai tu l'anno prossimo

Puoi sempre mettereun hard disk esterno , ma ho dei dubbi sui vostri calcoli, vi avevo già scritto che con emncms stò andando in locale da circa 3 anni , anche io leggo ogni 5 sec potenza, tensione, corrente, cosFi, energia e vi ho già postato la pagina di quanto occupa su SD circa 65Mb la parte elettrica , e circa 12 la parte 5 temperature lette ogni minuto invece....

Più che una questione di spazio è di tempo computazionale, qui stiamo parlando di robetta, nonostante i numeri sembrino stratosferici si tratta di tabelle banali ed in numero di 2? 3?...
A parte glfp che sostiene di aver visto scoppiare mysql su timeseries (forse su uno smartphone dico io ) stiamo parlando di prestazioni in fase di interrogazione.

Ora, graficamente sia grafana che emoncms su viste lunghe giocano con l'approssimazione graficamente parlando.

Però, timer alla mano una query con una condizione where (da riga di comando) su 12milioni di record vorrei vedere il tempo di ritorno tra influxdb e mysql

Io so per certo che mysql restituisce una query su 5milioni di record (dati istat censimento imprese) in ~0.015sec, ed una volta messo il piano di esecuzione in cache diventano la metà...

Piccolo aggiornamento (non ho abbandonato la sfida ... ;-) )

Giusto per informazione, visto che l'ho appena scoperto, gli SDM hanno un valore chiamato IMPORT ed EXPORT che mantiene il progressivo dei prelieli e delle immissioni. Applicato all'SDM del contatore dovrebbe permettermi di raggruppare e calcolare meglio i dati.

Qui un grafico di tutta la giornata di ieri con il valore IMPORT:



La console è presa da Chronograf, che è lo strumento simil Grafana della suite Influx.
Come vedere mi da dai 450kw di partenza delle 00:00 del 14/03 fino alle quasi 500 delle 00:00 del 15 (se qualcuno si chiede come mai tanti consumi è perchè da ieri ho la caldaia a gas rotta e sto andando di stufette !!! ... che i 6kwh siano con me ! ... ed è pure nuvoloso in questi giorni ... sgrunt !!)

Credo a questo punto (ma qui chiedo aiuto al pubblico e a qualcuno più ferrato di me in matematica) che per calcolare il prelievo giornaliero debba fare semplicemente 500-450 ! Invece di complicati e astrusi calcoli (integrali, medie, algoritmi strani) usando i valori istantanei ogni 5sec.

Lo stesso sul valore di EXPORT e sull'SDM collegato al fotovoltaico.

Io comunque sto proseguendo sulle sperimentazioni con Influx ... la strada per ora è chiara: devo usare le CONTINUOUS QUERY che sono fatte apposta per raggruppare valori e creare nuove serie, senza bisogno quindi di implementare processi esterni al sistema o cron o altri componenti non integrati.

Alla prossima ... che non so quando sarà perchè lavorare in smartworking è decisamente più stressante che lavorare in ufficio e il tempo è anche meno ...