annuncio

**spider61** · 26-10-2015, 23:09

E invece puo' : quando deve testare il 2� stacca la 485 all'altro , per 5-10' non perde niente , tanto i totali li rifa' lo stesso

**ninodifranco** · 27-10-2015, 02:10

spider hai fatto una grande scoperta, io ho detto che non si pu� in contemporanea, se ne stacca o ferma uno l'altro pu� funzionare, lo avevo gia detto in questo post

**TheDrake** · 28-10-2015, 19:20

Multimaster mission impossible?

Originariamente inviato da thx Visualizza il messaggio

So che si sta lavorando per far viaggiare il segnale con un unico convertitore rs485, ora volevo chiedere se una cosa del genere e' possibile
Solo a scopo di prova

Ti hanno gi� risposto esaurientemente altri. Aggiungo solo qualche elemento che potrebbe essere utile per affrontare diversamente il problema. Mi scuso con gli esperti per le eventuali imprecisioni.

Il protocollo utilizzato dai nostri dispositivi (modbus) sarebbe in grado di capire eventuali collisioni delle richieste trasmesse e delle relative risposte.
Per evitare che sul bus ci siano per la maggior parte collisioni al posto di trasmissioni valide, � necessario un qualche meccanismo di risoluzione degli accessi contemporanei da parte di due o pi� master.
Per avere un meccanismo di rilevazione delle collisioni efficiente � necessario che l'adattatore RS485 utilizzato sia in grado di ascoltare le sue stesse trasmissioni. Questo si pu� ottenere solo con un adattatore a "4 fili", in cui 2 sono dedicati alla trasmissione e 2 alla ricezione. Questi adattatori sono anche detti "full-duplex".
Una volta che l'hw e il cablaggio, sia esso a 2 fili o a 4 fili, e l'adattatore 485 siano in grado di gestire il caso "multimaster", � necessario avere un protocollo per gestire in modo concordato i tempi di accessi al bus da parte dei master, sempre per limitare il pi� possibile le collisioni.
Non mi risulta che i software che utilizziamo siano concepiti per un uso multimaster/fullduplex, n� per come ricevono e trasmettono, n� per come gestiscono gli errori. Sono tutti basati sul presupposto che la comunicazione avvenga in modalit� half-duplex singolo master.
Quasi tutti noi utilizziamo adattatori half-duplex a soli 2 fili.

Detto ci�, nulla ti impedisce per� di:

effettuare un cablaggio come dici
impostare i programmi per non essere continuamente ad impegnare il bus (ad esempio leggendo meno frequentemente nel loop di pooler485)
Impostare un numero di retry molto elevato
Aspettarsi che qualche lettura fallisca

In questo modo ti affideresti ad una gestione delle collisioni "random" con un numero di retry teoriche che potrebbe essere infinito, ma con un po' di attenzione potrebbe anche funzionare...

PERO'...

Si potrebbe anche inventare un qualche sistema di supervisione del bus aggiuntivo: basterebbe avere un qualche semaforo condiviso fra i due raspi (es. via tcp/IP con qualche riga di script in pi� o con una porta gpio connessa fra i due) a segnalare il bus occupato.

Se poi sei proprio fortunato

e hai gli orologi dei due raspi in sincrono potresti banalmente fare in modo che accedano al bus RS485 in time sharing. Tipo: il primo raspi legge nei primi 5s e evita di leggere nei seguenti 5s e viceversa.

Segue esempio di pooler485 che utilizza l'orologio di sistema e divide il tempo di accesso in fette da 5s. Adatto se tutte le letture dei contatori stanno sotto ai 5 secondi complessivi (con un solo contatore dovrebbe bastare).

N.B.: Le condizioni del ciclo while di attesa in rosso vanno alternato fra i due raspi contendenti in modo che accedano in tempi diversi.

codice:

#!/bin/bash

ADDRESSES="$1"
BAUD_RATE="$2"
DEVICE="$3"

ADDR_ARR=$(echo $ADDRESSES | tr "," "\n")

while [ true ]; do

    ID=0
    POWER=""
    ENERGY=""

#    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9
     do 
          sleep 0.5s
    done

    # Attendo comunque 0.5 secondi per sicurezza
    sleep 0.5s

    for ADDRESS in $ADDR_ARR
    do
    #((ID++))
    ID=$ADDRESS
    CMD="sdm120c -a ${ADDRESS} -b ${BAUD_RATE} -z 10 -i -p -v -c -f -g -P E -q ${DEVICE}"

    #echo $CMD
    
    VALUE=`$CMD`
    
    VOLTAGE=$(echo ${VALUE}   | awk '{print $1}')
    CURRENT=$(echo ${VALUE}   | awk '{print $2}')
    POWER=$(echo ${VALUE}     | awk '{print $3}')
    FACTOR=$(echo ${VALUE}    | awk '{print $4}')
    FREQUENCY=$(echo ${VALUE} | awk '{print $5}')
    ENERGY=$(echo ${VALUE}    | awk '{print $6}')

    if [ "$ENERGY" != "0" -a x"$ENERGY" != x -a "$POWER" != "0" -a x"$POWER" != x ]; then
        echo -e "$ID($POWER*W)\n$ID($ENERGY*Wh)\n${ID}_1($VOLTAGE*V)\n${ID}_2($CURRENT*A)\n${ID}_3($FREQUENCY*Hz)\n${ID}_4($FACTOR*F)" > /run/shm/metern${ADDRESS}.txt
        #echo -e "$VALUE"  > /run/shm/metern${ADDRESS}.txt
    fi

    done

done

Tutta teoria si intende, ma se funziona anche sarebbe molto divertente...

Facci sapere!
/drk

**ninodifranco** · 28-10-2015, 20:33

The Drake questa quando ho un po di tempo la voglio provare.

**spider61** · 28-10-2015, 20:57

Mi fate ricordare , che mentre avevo i due danfoss sotto monitoraggio con il solarlog , mi ero connesso prima col Pc e poi col Pogo in parallelo ai due fili della 485 (senza staccare il SL) , per testare lo script rklogger e realizzare poi il protocollo per i Danfoss su 123solar , e mandavo il comando tranquillamente e rispondeva almeno 9 volte su 10 giusto

,
quindi per fare i test sul muletto nel 99% non serve nemmeno staccare l'altro ...........

**thx** · 29-10-2015, 09:31

@TheDrake
La modifica al pooler va fatta solo al raspberry aggiuntivo?
Non vorrei andare a modificare quello che sta funzionando ora

**ninodifranco** · 29-10-2015, 10:35

Si , thx la modifica la dovresti fare al raspy aggiuntivo, ma devi controllare che i due orologi siano sincronizzati

**thx** · 29-10-2015, 10:43

Inoltre preferibile 2 adattatori rs485 uguali?

**TheDrake** · 29-10-2015, 10:59

Originariamente inviato da thx Visualizza il messaggio

@TheDrake
La modifica al pooler va fatta solo al raspberry aggiuntivo?
Non vorrei andare a modificare quello che sta funzionando ora

Andrebbe fatta ad entrambi i raspi con gli intervalli di attesa e accesso sfalsati.

Se non sei tranquillo, puoi postare il tuo pooler485 e te lo modifico nelle due versioni.

**TheDrake** · 29-10-2015, 11:02

Originariamente inviato da thx Visualizza il messaggio

Inoltre preferibile 2 adattatori rs485 uguali?

Dovrebbe essere ininfluente a patto che i collegamenti delle polarit� vengano rispettati (a volte A/B sono marcati a rovescio).

**thx** · 29-10-2015, 11:10

Non sono a casa, ma il pooler dovrebbe essere il classico ma con questa stringa cambiata

CMD="sdm120c -a ${ADDRESS} -b ${BAUD_RATE} -z 10 -i -p -v -c -f -g -P N -q ${DEVICE}"

**ninodifranco** · 29-10-2015, 11:23

Per essere pi� tranquilli forse si potrebbe allungare la pausa a 10s e fare in modo che un pooler485 legga al secondo 5, 15, 25... e l'altro 10, 20, 30... Poi magari si prova ad accorciare la pausa a 5, 6 secondi.

**TheDrake** · 29-10-2015, 13:17

Originariamente inviato da thx Visualizza il messaggio

Non sono a casa, ma il pooler dovrebbe essere il classico ma con questa stringa cambiata

Io ho fatto solo due modifiche:

Tolta la pausa finale al loop (sleep 5s o sleep 1s o quello che hai nel tuo script, che si trova in fondo al loop) perch� adesso andiamo in base ad una finestra di secondi specifici invece che con una pausa secca non legata ad uno specifico orario.
Inserite queste righe prima del ciclo for

codice:

#    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9
     do 
          sleep 0.5s
    done


    # Attendo comunque 0.5 secondi per sicurezza
    sleep 0.5s

Il primo loop while attende che le unit� dei secondi stiano nella finestra prescelta, poi faccio una ulteriore pausa di 0.5s per stare lontano da piccoli errori di sincronia dell'orario fra i due raspi.

Il commento "#" davanti al while serve per scegliere la prima riga o la seconda per usarle una per uno dei raspi e una per l'altro. Puoi anche eliminare la riga se preferisci.

raspi1

codice:

#    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9

raspi2

codice:

    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
#    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9

@ninodifranco
Una finestra maggiore di time sharing, con un solo contatore, senza condivisione del bus con aurora, secondo me � inutile: sul mio raspi una lettura sta sotto al secondo a 9600baud e i miei 4 contatori vengono letti tutti in meno di 5 secondi partendo dal bus libero.

/drk

**thx** · 29-10-2015, 14:04

Normalmente le letture del pooler vengono fatte ogni 5 secondi?
Cosa succede se si abbassa la lettura ad 1 secondo come fa 123solar?

**ninodifranco** · 29-10-2015, 14:15

Io l'ho abbassato a 0,5 secondi e funziona benissimo, per� vedo che i led del convertitore collegato al contatore lampeggiano con una frequenza inferiore rispetto a quello che legge gli inverter. Sar� la differenza di baud rate?

**TheDrake** · 29-10-2015, 14:30

Originariamente inviato da ninodifranco Visualizza il messaggio

Io l'ho abbassato a 0,5 secondi e funziona benissimo, per� vedo che i led del convertitore collegato al contatore lampeggiano con una frequenza inferiore rispetto a quello che legge gli inverter. Sar� la differenza di baud rate?

Questo perch� 123solar legge continuamente dall'inverter, senza pause intermedie.

Inviato dal mio Nexus 5 utilizzando Tapatalk

**TheDrake** · 29-10-2015, 14:42

Originariamente inviato da thx Visualizza il messaggio

Normalmente le letture del pooler vengono fatte ogni 5 secondi?
Cosa succede se si abbassa la lettura ad 1 secondo come fa 123solar?

Non succede nulla alle letture dai meter, mentre potrebbe aumentare la possibilit� di conflitti fra metern e pooler485. Nel senso che metern potrebbe leggere il file meterx.txt quando ancora non � stato scritto completamente dallo script. Meno cambia rapidamente il file, meno problemi ci sono...

Per questo motivo, andrebbe cambiata leggermente la logica di pooler485.sh.

Sul mio raspi sto testando una versione a loop stretto multicontatore che mi piacerebbe proporre in alternativa a quella classica. Purtroppo richiede anche la modifica delle configurazioni su metern.

Appena pronta, la posto con un po' di istruzioni per chi vuole provarla.

/drk

**thx** · 29-10-2015, 14:56

Originariamente inviato da TheDrake Visualizza il messaggio

Questo perch� 123solar legge continuamente dall'inverter, senza pause intermedie.

Inviato dal mio Nexus 5 utilizzando Tapatalk

123solar diversamente da metern dove trattiene i dati instantanei che riceve?

**TheDrake** · 29-10-2015, 15:05

Originariamente inviato da thx Visualizza il messaggio

123solar diversamente da metern dove trattiene i dati instantanei che riceve?

123solar li tiene in memoria (RAM).

Cos� farebbe anche metern, ma per comodit� si � scelto di slegare le letture fisiche da quelle che fa metern. Il suggerimento viene da jeanmarc stesso.

Anche metern funzionerebbe con letture dirette, ma deve funzionare molto bene la lettura e pi� meter ci sono, pi� le letture sarebbero rallentate.

Io stesso ho fatto qualche prova con le letture dirette ma a volte perde dei colpi. Debug in corso...

/drk

**thx** · 29-10-2015, 15:10

Mentre invece il grafico della produzione che viene disegnato nella pagina principale di metern, che dati va a prendere?
Ho degli strani picchi nel grafico della produzione in metern,ovvero il grafico spesse volte va a zero e 5 minuti dopo per conpesare lo zero precedente mi mostra un picco

**flane** · 29-10-2015, 15:34

Originariamente inviato da thx Visualizza il messaggio

Mentre invece il grafico della produzione che viene disegnato nella pagina principale di metern, che dati va a prendere?Ho degli strani picchi nel grafico della produzione in metern,ovvero il grafico spesse volte va a zero e 5 minuti dopo per conpesare lo zero precedente mi mostra un picco

Ho lo stesso problema anch'io, che capita casualmente di tanto in tanto e non ho mai capito da cosa pu� dipendere.
Ecco un esempio

Produzione in 123solar

Produzione in Metern

Si notano i picchi.
Ovviamente il totale non cambia, ma ogni tanto evidentemente prende un valore 0.
Da cosa potrebbe dipendere ed eventualmente come � possibile cercare di investigare il problema?

Complicazione in pi� per me che questo disturbo mi blocca il sistema di autoconsumo sul boiler tramite SSR

**thx** · 29-10-2015, 15:38

A me non blocca la gestione degli SSR perche' lo fa 123solar (con lo script di Gianfd), e 123solar non ha problemi

**ambramia** · 29-10-2015, 16:41

prendete quello che dico con il beneficio del dubbio, avevo notato anch'io nel grafico di metern delle letture a zero, ed il motivo era che il pooler485 (nel mio caso) veniva lanciato due volte, una da rc.local e l'altra da config_deamon.php ed a volte si sovraponevano e non riuscivano a scrivere sul file metern*.txt risultato letture a zero sul grafico, ho tolto l'avvio di uno dei due (meglio togliere quello in rc.local) e non ho avuto pi� problemi.
Potrebbero esserci degli errori di lettura sul bus rs485, che con il software sdm120c di TheDrake, pu� essere monitorato, abilitando il log, in modo da sincerarsi che il tutto funzioni per il meglio ma qui � meglio che intervenga TheDrake

**TheDrake** · 29-10-2015, 17:45

Originariamente inviato da thx Visualizza il messaggio

Mentre invece il grafico della produzione che viene disegnato nella pagina principale di metern, che dati va a prendere?
Ho degli strani picchi nel grafico della produzione in metern,ovvero il grafico spesse volte va a zero e 5 minuti dopo per conpesare lo zero precedente mi mostra un picco

[ATTACH=CONFIG]50371[/ATTACH]

Originariamente inviato da flane Visualizza il messaggio

Ho lo stesso problema anch'io, che capita casualmente di tanto in tanto e non ho mai capito da cosa pu� dipendere.
Ecco un esempio

Produzione in 123solar
[ATTACH=CONFIG]50372[/ATTACH]

Produzione in Metern
[ATTACH=CONFIG]50373[/ATTACH]

Si notano i picchi.
Ovviamente il totale non cambia, ma ogni tanto evidentemente prende un valore 0.
Da cosa potrebbe dipendere ed eventualmente come � possibile cercare di investigare il problema?

Complicazione in pi� per me che questo disturbo mi blocca il sistema di autoconsumo sul boiler tramite SSR

Prima o poi qualcuno mi banner� per i post troppo lunghi e presuntuosi!

Il problema della lettura dei dati di produzione col passaggio dati da 123solar a metern � un caso un po' complicato. Dipende dall'assunzione errata che tutto vada sempre bene e dal fatto che il raspi sia un sistema multitask...

Ecco cosa ho potuto constatare con le mie prove:

Posto che si utilizzi per la lettura della produzione lo script pool123s o le sue varianti, il problema di base � che non c'� sincronia garantita fra le letture fatte da 123solar, le scritture su file dei dati letti da 123solar e l'istante in cui metern legge i campionamenti della produzione ogni 5 minuti. Il ritardo di qualche secondo che ha messo jeanmarc nelle letture programmate di metern rispetto a 123solar o il fatto che si utilizzi la versione live di pool123s, a volte � sufficiente ad ovviare a questi problemi, ma non sempre.

Pu� succedere (come si vede proprio dai due grafici) che metern e lo script pool123s leggano dati che appartengono ai 5 minuti precedenti di 123solar semplicemente perch� non viene verificato dallo script di metern che 123solar abbia gi� letto e/o gi� scritto il dato dei 5 minuti in corso. Persa una lettura la produzione va a 0 perch� risulta quella di 5 minuti prima e se quella seguente casualmente risulta in sincrono si vede il buco e il picco.

Questo tipo di problemi vengono acuiti da linee disturbate o parametri sbagliati per la lettura dell'inverter. Se 123solar fa un paio di retry (lancia aurora fino a 3 volte se ha un errore di lettura) la frittata � fatta e c'� la quasi certezza del problema.

Peraltro questo problema � lo stesso che crea il disallineamento frequente fra il dato campionato da metern e quello campionato da 123solar nel caso di utilizzo di pool123s in versione "live". Se confrontate i dati dei csv di 123solar e metern, non sempre coincidono 5 minuti per 5 minuti.

Per ovviare a questo problema ho iniziato a lavorare a fatica uno script pool123s modificato con gli opportuni controlli e verifiche per evitare buchi, letture anticipate e letture posticipate, ecc... Non lo ritengo per� ancora abbastanza affidabile perch� possa dire che sia utilizzabile in produzione. Dovrebbe infatti resistere a riavvii, ore legali, buchi di letture, ecc... e non ho ancora avuto il tempo di provare tutti i casi. Mi servirebbe un secondo raspi con la linea RS485 condivisa in time sharing, ma le ore della giornata sono tiranne...

La soluzione migliore sarebbe che 123solar "inviasse esplicitamente" a metern il dato di produzione quando questo fosse disponibile, oppure che metern e 123solar si fondessero in un unico programma, ma � tutta roba che per nostra sfortuna non salta fuori gratis.

/drk

**spider61** · 29-10-2015, 18:27

Io uso 123solar dal 2012 , aprii io la prima discussione sul Pogo e con l'aiuto di altri sono e siamo riusciti a farlo funzionare , poi il Pogo non si trova piu' quindi e' stato traslato tutto sul rasp....

premesso questo ; se non ho inteso male , perche' l'autore non ha utilizzato la stessa falsariga di 123solar , cioe' degli script di protocollo per ogni inverter che leggono il valore live e lo tengono in memoria e poi salvano il file csv ogni 5' ?!?!

Bastava che facesse lo stesso , uno script per leggere i dati di consumo , uno script che leggesse i dati di produzione (eventuale) , uno script per leggere una T , chiunque poteva aggiungere uno script in php per le sue letture e tenere questi valori live in memoria e e cosi' via , senza dover fare dei file esterni e andare a leggerli ?!?! salvando poi i valori in un csv ....

**TheDrake** · 29-10-2015, 19:25

Originariamente inviato da spider61 Visualizza il messaggio

Io uso 123solar dal 2012 , aprii io la prima discussione sul Pogo e con l'aiuto di altri sono e siamo riusciti a farlo funzionare , poi il Pogo non si trova piu' quindi e' stato traslato tutto sul rasp....

premesso questo ; se non ho inteso male , perche' l'autore non ha utilizzato la stessa falsariga di 123solar , cioe' degli script di protocollo per ogni inverter che leggono il valore live e lo tengono in memoria e poi salvano il file csv ogni 5' ?!?!

Bastava che facesse lo stesso , uno script per leggere i dati di consumo , uno script che leggesse i dati di produzione (eventuale) , uno script per leggere una T , chiunque poteva aggiungere uno script in php per le sue letture e tenere questi valori live in memoria e e cosi' via , senza dover fare dei file esterni e andare a leggerli ?!?! salvando poi i valori in un csv ....

Metern internamente fa esattamente quello che fa 123solar, solo che si aspetta di leggere i dati dall'esterno in un formato "standard" invece di aver bisogno di creare script dedicati per ogni dispositivo.

E' una scelta che ha fatto jeanmarc e sicuramente l'ha ponderata a lungo. In questo modo ha slegato 123solar e relativi aggiornamenti dalla lettura dei dati. Lui si occupa del campionamento e della archiviazione dei dati, altri delle interfaccie verso i diversi dispositivi e le diverse grandezze. In questo modo l'ha reso molto pi� flessibile e potr� permettersi in futuro una riscrittura dell'architettura interna del programma senza dover cambiare nulla delle interfaccie esterne.

Per� metern pu� leggere molte grandezze contemporaneamente. Le letture fatte in sequenza dall'interno del programma hanno una durata totale che � la somma dei tempi delle singole letture. Se ci sono tanti meter e tante grandezze reali o virtuali da calcolare, la durata della lettura "fisica" pu� diventare troppo lunga.

Utilizzando invece processi autonomi concorrenti ed esterni a metern per le letture, con dei file in memoria (come fa 123solar) per l'appoggio dei dati, si accorciano drasticamente i tempi del ciclo di lettura principale e si arriva alla quasi simultaneit� delle singole letture.

L'unico problema � quando le letture sono interdipendenti. In questo caso bisogna stare un po' pi� attenti.

Ed eccoci arrivati a metern, relativi script e problematiche indotte.

/drk

**thx** · 29-10-2015, 19:57

Originariamente inviato da TheDrake Visualizza il messaggio

Per� metern pu� leggere molte grandezze contemporaneamente. Le letture fatte in sequenza dall'interno del programma hanno una durata totale che � la somma dei tempi delle singole letture. Se ci sono tanti meter e tante grandezze reali o virtuali da calcolare, la durata della lettura "fisica" pu� diventare troppo lunga.

/drk

Il fatto e' che io ho solo 2 grandezze fisiche,consumi e produzione...niente eflow e temperature

Posso magari intervenire su qualche parametro temporale per mediare a questo problema?

**spider61** · 29-10-2015, 20:33

Thedrake ok che l'abbia fatto per poter essere un po' piu' aperto e non voglio criticare il grande lavoro svolto da JM , ma non poteva fare allora come Emoncms , a cui arrivano i dati da uno script esterno indirizzato all'IP del logger al limite , l'ho installato su un Rasp , e ho realizzato 2 script in PHP lanciati al di fuori , uno che legge 1 contatore 485 sui consumi e uno sulla produzione , e l'altro script che mi legge per adesso 5 sonde DS1820 , il primo viaggia con tempo di aggiornamento di 2-3" , il secondo scripth legge ogni minuto (se ci sono errori lascia i valori precedenti) .... poi con i dati letti si crea il file csv..... e non scrivere un file esterno per ogni serie di dispositivi etc.....

**TheDrake** · 29-10-2015, 23:53

Originariamente inviato da thx Visualizza il messaggio

Il fatto e' che io ho solo 2 grandezze fisiche,consumi e produzione...niente eflow e temperature
Premetto che sto usando la versione di 1.5.5 di 123solar, in quanto Gianf ha sviluppato gli script per la gestione dei carichi con questa versione...anche se sta lavorando sulla versione 1.6.x di 123solar

Posso magari intervenire su qualche parametro temporale per mediare a questo problema?

Io farei una verifica di questo tipo:

fai un backup
verifica che le prestazioni della tua SD siano ok (N.B.: possibilmente evita gli overclock), un rallentamento in lettura o scrittura pu� dare i problemi pi� strani.
verifica che il tuo firmware sia l'ultimo (rpi-update)
verifica che non ci siano errori nel log di sistema (dmesg e syslog)
verifica che il problema delle mancate letture non accada quando accendi o spegni o riavii 123solar con metern acceso. Se spegni 123solar, prima spegni sempre metern, poi riavvia prima 123solar e dopo qualche secondo metern
se possibile, quando devi spegnere/riavviare/ecc, evita di farlo a cavallo dei minuti divisibili per 5
verifica che non ci siano mai errori lanciando aurora manualmente con gli stessi parametri che hai impostato in 123solar, magari attiva la modalit� di debug di 123solar per un po' e verifica se vengono scritti degli errori. 123solar dovrebbe generare un file .err per ogni errore incontrato. Se coincidono con le anomalie dei grafico hai trovato la causa.
se il problema ce l'hai con la produzione, prova a mettere un ritardo di qualche secondo all'inizio dello script pool123s (es. sleep 5 / sleep 10) in modo che le letture di metern vengano sicuramente fatte dopo che la lettura della produzione di 123solar sia stata effettuata correttamente

In pi�:

Io con aurora uso i parametri -l2 -Y10 -w10 a cui difficilmente rinuncerei. Anche con un solo inverter sulla linea! Pu� sempre succedere che scappi una lettura con aurora intanto che 123solar � acceso e il parametro -w20 evita il fallimento certo della lettura.
In questo momento io non userei mai un aurora <1.8.8 + ultime patch perch� altrimenti aurora non � completamente lock safe.
Anche per sdm120c non rinuncerei mai ai parametri -z10 -w10 (e volendo anche -j20) e all'ultima versione 1.3.4. Anche una lettura manuale in pi� fatta con sdm120c pu� causare conflitti, sia con le versioni precedenti che non gestivano i lock e quindi sovrappongono richieste e risposte, che con le ultime che sono in grado di gestire l'accesso concorrente, ma necessitano di un parametro -w > 0.

Fammi sapere se trovi qualcosa di anomalo e se riesci a risolvere.

/drk.

**ninodifranco** · 30-10-2015, 14:52

Originariamente inviato da TheDrake Visualizza il messaggio

raspi1

codice:

#    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9

raspi2

codice:

    while [ $(($(date +'%S')%10)) -lt 5 ]  # Salta le cifre dei secondi da X0 a X4
#    while [ $(($(date +'%S')%10)) -ge 5 ]  # Salta le cifre dei secondi da X5 a X9

@ninodifranco
Una finestra maggiore di time sharing, con un solo contatore, senza condivisione del bus con aurora, secondo me � inutile: sul mio raspi una lettura sta sotto al secondo a 9600baud e i miei 4 contatori vengono letti tutti in meno di 5 secondi partendo dal bus libero.

/drk

Scusami Drake ma se non ho capito male il primo rpi legge nei secondi che vanno da 0 a 4 ed il secondo nei secondi che vanno da 5 a 9, se � cos� la finestra temporale totale sarebbe 0 - 9 e quindi 10 secondi?
o in realt� la finesta � il 10% di 60 secondi (6 secondi) e quindi il primo legge nei primi 3s ed il secondo nei successivi 3s?

annuncio

Raspberry + MeterN - Monitoraggio energetico valido ed economico - GUIDA

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta

Commenta