Non ci hai capito, dico Ci perchè suppongo che nightfly64 abbia capito cosa voglio dire. Sono d'accordo che più voci no nel csv più punti ho nel grafico, invece io parlavo di come lui si calcola la produzione giornaliera e devo verificare pure quella totale. Naturalmente io parlo per il mio tipo di inveter che è un Aurora Central.

Booh, forse non ci ho capito io, o ti spieghi male tu,
parli di una lettura la mattina e una la sera per calcolare la produzione giornaliera,
ma quel valore lo deve per forza salvare ogni 5' insieme a tutti gli altri valori letti
non gli serve solo per fare il calcolo della produzione giornaliera,
gli serve per il grafico, lo usa anche per calcolare la produzione parziale a mettà giornata che visualizzi sopra il grafico, e forse anche per altro.

Guardate che nel csv viene memorizzato l'incremento di produzione totale negli ultimi 5 min, mentre la produzione totale giornaliera viene letta direttamente dall'inverter la mattina seguente e viene memorizzata sul file energyxxxx.csv nella directory production

Domanda: Come fa il tuo 123solar a darti la lettura della produzione giornaliera?
Guarda il codice al post 2389.
A mio modesto giudizio ed ad mio modesto uso non è molto efficiente. Io mi sono fatto uno script che per adesso che lancio manualmente la sera e mi restituisce con esattezza matematica i valori di produzione. Questi si discostano da quelli calcolati da 123solar.

Walter... allora può essere. Io ho modificato le variabili, e nel csv non ho gli incrementi ma bensì i valori di Energia giornaliera.

che sarebbe l'energia prodotta in quel lasso di tempo, che serve poi a creare la curva della energia generata (su PVOUT)

Il grafico giornaliero è calcolato esattamente come hai spiegato tu ma su pvoutput manda il valore istantaneo della potenza nella prima lettura dei 5 minuti, se per qualche motivo quella lettura fallisce manda Power=0 e il grafico poi avrà dei buchi. Non so se ci sia una ragione per fare così.

Guardando il codice di 123solar.php (circa riga 221 e seguenti) a me pare che prenda i valori dal csv del giorno precedente.

La produzione totale giornaliera non viene letta dall'inverter.
Per il calcolo della produzione totale giornaliera prende il primo e l'ultimo valore dal csv del giorno corrente,
anche se poi lo aggiorna nel csv annuale solo il giorno seguente.
Non so se magari è previsto un controllo in caso il log inizi in ritardo e quindi la prima lettura fosse superiore all'ultima del giorno precedente,
nel caso inverso con prima lettura odierna inferiore all'ultima lettura del giorno precedente (caso azzeramento contatori o cambio inverter),
il calcolo viene fatto regolarmente, se leggesse dal giorno precedente risulterebbe in questo caso un numero negativo.
Se state parlando invece del valore inviato a PVOut non so se il calcolo viene effettuato allo stesso modo o diversamente

Buongiorno a tutti,

appena finito l'aggiornamento alla nuova versione di 123solar, ma il problema di ricavare la potenza prodotta dalla somma delle tre fasi non è stato risolto lo so che è un bug dell'inverter, però resto dell'idea che la soluzione ideale sarebbe leggere il valore Pout riportato sull'inverter...

Ho scritto ad aurora, mi ha anche chiamato un tecnico, ma per il momento tutto tace...

Jeanmarc mi disse come fare per riportare la somma dei due array, e quello potrebbe essere una buona approssimazione moltiplicando il valore prodotto per 0.95, però poi i valori su pvoutput non sono corretti, cosa bisognerebbe modificare ancora?

a dopo.

Buona giornata.

Potresti fare il calcolo direttamente su aurora.php

ciao, potresti darmi qualche indicazione?

grazie.

Se ho capito bene devi moltiplicare il valore delle potenza di ogni singola fare 0.95. Se apri aurora.php trovi:
$G1P = round(($G1V * $G1A), 3);
prova a cambiarlo in
$G1P = round(($G1V * $G1A * 0.95), 3);
Lo devi fare per le 3 fasi. Prova

Ciao Fedex,

innanzitutto grazie.

la mia situazione è più complicata, in quanto, per ovviare al bug del trio da 10 kw, che restituisce valori errati sugli ampere quando la produzione è sotto i 1000w, devo, per ovviare alla meno peggio, ottenere il mo gptot sommando i valori DC dei due array, e questo Jeanmarc mi ha detto come farlo... you'll need to modify index_mono.php gauge JS : point.update (json [0]. I1P + json [0]. I2P);

è questo il valore che dovrei moltiplicare per 0.9 (stimo un 10% di perdita nella conversione DC/AC) e mostrare nel gauges della pagina principale; lo stesso valore dovrei passarlo e pvoutput e leggerlo con il php di floriano... tutto questo per far partire il progetto di automazione tramite raspberry...

facile, no?

grazie

Nunzio.

Esattamente....

Forse sono OT, ma io mio raspberry è stato attaccato ed affondato. Ripristinato con immagine del sistema fatta qualche giorno prima e backup da ftp.
In allegato il file del log che trovate pure sul vostro rasp. su /var/log/auth.rar
Da notare che hanno usato la tecnica del bruteforce quindi per proteggermi io adesso ho messo una password con caratteri speciali con numeri e maiuscole sparse e modificato il file /etc/ssh/ssh_config aggiungendo alla fine:

Ciao sarà un caso ,ma anche il mio stamttina era out ,ho dovuto ricaricare un backup....

passa il tuo log così da verificare gli IP e il dizionario usato

se siete stati attaccati dall'esterno il raspberry lo segna come ultimo accesso da chi e da dove , basta controllare quando aprite putty.

Controllate che sul router sia attivo il firewall, non vi da la sicurezza di essere invulnerabili, ma almeno aiuta

eccolo l'intrufolone
May 20 03:17:38 raspberrypi sshd[4722]: Accepted password for pi from 217.66.64.7 port 35362 ssh2

Va benissimo la configurazione sicura di ssh (sarebbe meglio se autenticassi su chiave e non su password), ma forse sarebbe ancora meglio mettere in ascolto 'pubblico' porte diverse da quelle di default sia per ssh che, anche e sopratutto, per apache.
Ti togli di dosso pure quei cicli di cpu che il povero raspberry pi deve sopportare per i tanti handshake ssh generati dai robot sparsi per la rete e ogni ciclo di cpu è sacrosanto su questo affarino.

-
Comunque thread interessante, chilometrico... e visto che il topic appare abbastanza ampio do il mio breve contributo e ne approfitto per riceverlo...) anche io mi sono cimentato da pochissimo nel monitoring con raspberry. attualmente sto usando auroramonitor (FOSS si trova su sourceforge) che conteggia e invia su pvoutput i dati del mio pvi 6000 casalingo, ho dovuto smanettare anche io, come immagino tutti noi che seguiamo questo thread con il nostro gioiellino, ma mai troppo per potermi dire annoiato e insieme a una serie di script bash o python e cron ripristino la wifi (che non smette di cadere vista la distanza..), controllo la temp dell'affare, spazio sul disco, mi notifico via email eventuali anomalie, etc. Insomma per adesso ho cercato un po di stabilità, che è quello che mi serve per monitorare un impianto a distanza..il mio prossimo obiettivo.
Non ho ancora provato invece 123solar, non ne ho visto la necessità, guardando ai pochi screenshot trovati per la rete, rispetto a quanto già ho con pvoutput. Però vedo che molti lo utilizzano e ci spendono tempo per migliorarlo. Se posso, provate a chiarirmi cosa ci sia in più di utile?
Inoltre, se qualcuno ha esperienza con più di tre inverter in daisy chain e magari con stringcomb collegato potrebbe spendere un minuto del suo tempo per dirmi: "vai tranquillo non c'è nessun problema a monitorare 2 o 15 inverter con il nostro raspberry"? .. temo di perdermi dietro una chimera.. ma vorrei provare.

@fedex ho dovuto installare tutto ,il rasp non faceva il boot......non posso postare quello che chiediSaluti

io ancora sono sotto attacco...

ciao fedex17 è successo anche a me stanotte, è qualche stupidotto in mezzo a noi che si diverte? non lo so!

dolam, io ho evitato di postare il mio IP STATICO per questi motivi... infatti in passato mi avevi chiesto di vedere il mio impianto e sono sembrato scortese, però almeno ti garantisco che su questo forum non ho dubbi. Quindi escludo la tua supposizione

questo mi consola e mi fa piacere, non risolve il problema ma almeno sappiamo che tutti si comportano bene da veri amici.
Per l'ip in realtà a me il rasp non ha registrato nessuna intrusione potrebbe anche essere una casualità.

Non credo si tratti di qualcuno che vi ha preso di mira.
Guardando ai log postati da Fedex è evidente che è/è stato vittima di una botnet (una "rete di robot"..ossia programmi che girano in background ad insaputa dei reali proprietari dei computer da dove partono gli attacchi) che scansionano interi blocchi di IP.
Se vedi i source address da cui partono gli attacchi sono differenti, molto probabilmente sono tutti parti di una botnet che è stata 'comandata' per scansionare il blocco di IP dove ti trovi adesso.
Questi robot, piuttosto stupidi, non fanno altro che cercare su tutti gli indirizzi appartenenti ad un blocco (ad esempio 82.177.x.x) eventuali servizi ssh in ascolto (di default su porta 22) e, trovato qualcuno, provano via dizionario tutte le credenziali possibili, finchè non ne trovano qualcuno vulnerabile dove potersi replicare.

Pertanto..
Posto che internet è piena di questi bot (se ne stimano decine di milioni) e che le probabilità di finire in un blocco di IP di 'interesse' di chi comanda queste botnet è sempre molto alto.
Posto che non è solo ssh il servizio preso di mira dai bot, ma bensì molto più spesso è lo stesso server apache o addirittura direttamente le web application (per lo più quelle in php dove anche i ragazzini sanno smanettarci) che ci girano sopra.
Il mio sentito consiglio, vista l'esperienza maturata in anni di lavoro, è: vista la natura personale del servizio che hai messo su, di spostare la porta di default da 22 ... ad un'altra porta (preferibilmente compresa fra 1025 e 65535).
Puoi farlo editando il file /etc/ssh/sshd_config e sostituendo a Port 22 il tuo Port XXXX e poi riavviando sshd con /etc/init.d/sshd restart.
Ovviamente se il tuo router te lo permette, puoi anche evitare di spostare la porta di default di ssh e il NAT dal tuo router lo fai esternamente su una porta differente dalla 22
ad esempio:
(in) 22 <--> 7522 (out)
lo stesso lo consiglio vivamente anche per apache, sposta la porta 80 ad un'altra porta.
Comunque avendo sostituito la password di default del rasp dovresti già avere mezzo risolto, se non fosse che per il povero rasp gestire tanti handshake ssh potrebbe diventare comunque un carico cpu non indifferente che potrebbe mettere a rischio la stabilità del tuo sistema.
Insomma la lezione di base è, se non devi avere un servizio realmente (al) pubblico, evita le porte di default... ti risparmi tante rogne e tante entry nei tuoi log files.
Spero di esservi stato utile e di avervi tranquillizzato sul fatto che nessuno vi ha preso di mira.. è solo la rete.
Se sapevate già tutto, magari servirà come chiarimento a chi ne sa un po' meno.

rosco01 meriti un applauso per la supercompetenza in materia e per la chiarezza espositiva che farebbe venir voglia, anche a uno come me che non mastica nulla di informatica, di provare a cambiare le porte. Sono sicuro che se posti una piccola guida un po' più dettagliata
riusciremo tutti a cautelarci anche contro i robot. Da quello che ho capito il primo ed essenziale passo minimo è la sostituzione della password di default, a quella ci arrivo. Dovresti spiegarci passo passo come cambiare la 22.

Di questo problema , se ne era gia' parlato nella discussione sul pogo..... problema per chi lo teneva con ip fisso....

Meno male che fin da subito ho usato due porte a caso invece della 22 e 80. Comunque dopo aver letto di queste intrusioni ho anche configurato l'accesso tramite chiave privata e disabilitato quello con password.

Fino ad un mese fa usavo un pc windows con un sw scritto da me che si limitava a leggere i dati di produzione dall'inverter e a caricarli su pvoutput. Poi ho voluto aggiungere i dati di consumo e quindi sono passato ad usare un Raspberry che a questo punto posso tenere sempre acceso. 123solar mi è sembrato il sw piu' semplice da installare e usare su un Raspberry senza tastiera nè monitor, conserva i dati di produzione in locale e volendo li carica su pvoutput. Ho dato un'occhiata ad auroramonitor ma ho visto che aveva l'interfaccia grafica e ho lasciato perdere, non volevo impelagarmi con x e con vnc.

Con piu' inverter non ho esperienza, ma ho lavorato molte volte con dispositivi collegati in 485. In genere non ci sono problemi a comunicare con un numero anche elevato di dispositivi ma il tempo ciclo ne risente. Cioè se aurora impiega 3-4 secondi a leggere i dati da un inverter per leggerli da 10 inverter impiegherà 10 volte tanto. Poi a volte con piu' device gli errori di comunicazione tendono ad aumentare e questo allunga ulteriormente il tempo di ciclo.

Scusa, mi era sfuggito. Io ne controllo 17, e avvolte 15 minuti non mi bastano a leggerli tutti, ma è un problema raggirabile con uno script a cui stavo lavorando.