@dolam prova a seguire le istruzioni che ho dato

lo squadrettamento lo fà anche a mè


(blù e giialo sono il sensore DTH22 - viola il sensore VDS18B20)
ma non mi dà valori impossibili...

sembra quasi che ha dei vuoti di lettura..
potrebbe essere l'altro misuratore connesso con webiopi o una non sincronizzazione dei dati di lettura..

stasera provo a ridurre il periodo di letture da 15 a 10 minuti in crown.d

ciao

miki8989 non c'è bisogno di ridurre i tempi di lettura io ce li ho a 5 minuti e non cambia nulla ( non ricordo nemmeno dove ho variato il tempo)
Gianfranco dice di configuralo come per i sensori di temperatura, attraverso uno script apposito (#1301) ma se eseguo i suoi comandi non riesco a crearlo, tu invece ci sei riuscito, potresti "tradurmi" i singoli comandi da dare al raspberry per impostare la lettura attraverso uno script temporaneo?
penso che così si risolva

Con il DHT22 letto via GPIO anch'io ho avuto spesso letture falsate o valori mancanti perchè la funzione di lettura dipende da tempistiche strette e che devono essere precise altrimenti se va bene fallisce e se va male restituisce valori errati. Dalle prove fatte all'epoca sembrava che il successo delle letture dipendesse molto dal carico della cpu, piu' la cpu è impegnata meno si riesce a leggere con successo il DHT22. Collegarla via SPI è un po' piu' complicato ma garantisce letture precise in ogni condizione e impegno di cpu quasi zero, da mesi ho una lettura ogni minuto e non ho mai visto valori sballati nè buchi nel grafico.
Poi puo' anche darsi che dipenda da altro, io usavo un programmino in C con wiringPI non la libreria di adafruit.

gianfranco sono riuscito a creare il file temp:

root@raspberrypi:/usr/local/bin# cat /etc/cron.d/temp
#!/bin/bash


SHELL=/bin/bash
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""


# Minute Hour Day of Month Month Day of Week User Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
*/15 * * * * root metern_temp_webiopi.sh 8
il sensore è il numero 8
poi ho creato

metern_temp_webiopi.sh
#!/bin/sh


ID=$8
echo"${ID}($(curl -s http://127.0.0.1:8000/devices/temp0/sensor/temperature/c)*C)"> /run/shm/metern${ID}.txt

ma forse qui devo scrivere altro? temperature/c)*C)"

nella riga di lettura su metern devo scrivere : cat /run/shm/metern8.txt | grep C e cat /run/shm/metern8.txt | grep %

oppure solo cat /run/shm/metern8.txt C e cat /run/shm/metern8.txt %

Scusate ma qualcuno mi sà dire perchè il comando suggerito da thedrake per inserire in metern lo stato di un processo:
Se lo uso in terminale mi restituisce correttamente 1 o 0 a seconda se il processo è attivo o no, mentre se inserisco il comando in meterN mi restituisce sempre e solo 1 anche quando il processo non è attivo ....
l'ho verificato sia durante il normale funzionamento di metern che con il bottone test, restituisce sempre e solo 1.

Non credo centrino i problemi di permessi, perchè da terminale sia che sono loggato come root che come pi le risposte sono sempre corrette ....

Ciao flane, Prova con questa modifica.

@dolam segui le istruzioni del post #1341

Condivisione cavo 485 (ovvero come usare un singolo adattatore usb-485)

E' noto a tutti che si consiglia di dividere i "cavi" 485/modbus che leggono i dati da uno o più inverter Aurora e contemporaneamente da uno o più contatori modbus Eutron. Si consiglia di utilizzare adattatori usb/485 diversi e cavi separati. Saggio consiglio e soluzione dei problemi, peccato che non potessi applicarlo alla mia installazione.

Siccome a casa mia ho un solo cavo 485 a disposizione e devo leggere sia dall'inverter che dai contatori, ho dovuto sopperire alla cosa.

La soluzione è stata modificare sdm120c e il programma aurora perchè utilizzassero un meccanismo comune per gestire l'accesso contemporaneo alla porta 485. Aurora aveva già un sistema al suo interno, ma per un piccolo errore non era compatibile con gli altri programmi (e neppure con se stesso... ). A sdm120c mancava completamente questo meccanismo (la libreria modbus non lo prevede) e quindi gli ho inoculato il codice di locking aurora opportunamente corretto e modificato.

Il programma sdm120c, grazie @gianfrdp ha già recepito le modifiche da me suggerite e ora lo trovate, nella versione 1.2.0. Basta scaricare l'ultima versione, ricompilarla ed installarla.

Aurora è ancora fermo alla versione 1.8.8 perchè Curt non ha ancora inglobato le patch necessarie a renderlo compatibile con sdm120c e quindi è necessario fare manualmente una patch, presente fra i sorgenti di sdm120c 1.2, nella subdir aurora.

Con i programmi allineati potrete finalmente utilizzare una sola linea 485 condivisa!

Da qualche tempo io sto lavorando, senza nessun problema, con accesso contemporaneo a 3 contatori SDM120C e un inverter Aurora sullo stesso cavo. Non ho nessun errore di lettura (che non sia qualche retry gestito e risolto dai programmi stessi) con più programmi (123solar, websolarlog, metern, ecc...) che effettuano letture a loop stretto dai dispositivi. I vari programmi si mettono in coda per le letture e procedono appena la porta si libera.

Se c'è qualcuno che interessato perchè ha il mio stesso problema, fatemi sapere. Non ho una guida passo-passo disponibile ma non dovrebbe essere complicato realizzarla.

/drk

Gianfrdp, TheDrake e Flane. sono orgoglioso nel solo leggervi per il lavoro che fate per noi, penso che dovreste scrivere insieme una guida con i vari distinti capitoli per i vari interventi possibili per la soluzione dei problemi , ritengo diverrebbe presto un best seller del web, grazie ancora. Naturalmente Walter62 resta l'origine della splendida avventura sul raspberry.

Niente da fare drake
Con questa modifica mi risponde sempre 0, sia da terminale che da metern, mentre con il parametro -fcn da terminale funziona regolarmente.

Io lo uso per vedere se è in funzione il mio script per il PWM. Script che viene avviato al mattino mediante cron (come utente root).
Il problema potrebbe essere il fatto che viene eseguito come root?
Però da terminale il comando -fcn funziona correttamente anche come utente pi.
Sempre eseguendolo da terminale con prima un "su www-data" il comando funziona, ma da metern no



EDIT:
il comando
con la sola opzione "-c" FUNZIONA

__________________________________________________ ______________________________________________
Ottima la soluzione per un solo bus 485
Ho dato un occhio ai diff introdotti nei vari file su github, ma non capisco come impostare i vari ritardi.
Mi potresti dare qualche dritta in più per fare qualche prova ?
Credo che la cosa possa essere interessante non solo per chi ha problemi di cavi, ma in generale un pò per tutti, perchè la presenza di due adattatori usb_RS485 sul raspi a volte crea dei problemi con delle impreviste inversioni di porte.

Ciao flane,
mi fa piacere che sia una cosa che interessi anche ad altri. Io la trovo magica e stracomoda...

Questi sono i parametri essenziali delle mie due linee di comando per aurora e per sdm120c:

Il parametro che risolve il conflitto in caso di accesso contemporaneo è -w che attende x secondi che si liberi il bus mettendosi in coda. Di default l'attesa è 0, quindi se sente il bus già occupato esce direttamente con un errore. Inoltre un retry minimo (rispettivamente -Y e -z) è meglio metterlo ad un valore minimo su bus rumorosi.

Mi raccomando, oltre a sdm 1.2.0, di applicare anche la patch per Aurora, altrimenti i due programmi non si parlano correttamente.

P.S.: FYI, mi hai appena spedito un SDM220 modbus... Appena arriva estendo il test a 4 meter + 1 inverter sullo stesso bus...

Per chi ha problemi nelle letture a 0 di alcuni sensori , basta che il programma salti se trova la lettura fuori da certi valori e lascia l'ultima effettiva... si fa' cosi' quando ci possono essere letture saltate o valori sballati ... tanto sono tutte letture ininfluenti , se anche non leggo la T o H per 10 volte non succede niente tanto hanno variazioni talmente lente....

@thedrake

grazie per le info

Farò sicuramente qualche prova. Sono anche comodo a spostare tutto su un'unico bus perchè ho inverter e contatori vicini.

Alcuni chiarimenti:
1) la riga per impostare la velocità a 19600 in rc.olocal va comunque inserita?
2) Ma mettendo ritardi così ampi, non crea problemi visto che il pooler485 fà letture ogni 5 secondi?
3) metti tutti i dispositivi in parallelo sullo stesso bus senza resistenze varie?
4) che cavo usi per il bus un normale cavo LAN? oppure appositi doppini ritorti per RS485?

PS: drake se me lo dicevi che eri tu ti facevo sicuramente UNO SCONTO !!!!
Parte domani, ti arriverà martedì.

@spider " Per chi ha problemi nelle letture a 0 di alcuni sensori " è come tu dici , non è assolutamente importante che ci siano tutte le letture alla fine va bene anche così, anzi potrebbe anche non esserci il DHT.22, ma avendovi conosciuto e sapendo che molti di voi sono in grado di risolvere il problema, pongo l'argomento nella speranza che vogliate dedicarci un po' del vostro tempo.

Nel frattempo , a seguito di un aggiornamento automatico di Windows 8, hanno smesso di funzionare sia PUTTY che WIN-SCP, al momento riesco a collegarmi ai raspberry solo da TERMINALE - MAC o da un vecchio computer XP (per fortuna non butto mai niente)

Su questo vi chiedo un aiuto concreto , se potete.

1) Io ce l'ho ancora, ma ho il sospetto che non serva a nulla, in quanto ogni programma (aurora e sdm120c) impostano la velocità in modo autonomo appena hanno acquisito il lock esclusivo sulla porta. In particolare aurora lavora fisso a 19200 e sdm alla velocità impostata sulla linea di comando che nel mio caso è 9600. Se non lo facessero non funzionerebbe nulla.

2) I ritardi sulla linea di comando (-w) servono solo per rimanere in coda il tempo necessario perchè la porta si liberi, non è un ritardo fisso a priori. Inoltre non influenzano il funzionamento dei loop monothread di pooler485 o di 123solar o altri se non rallentando la frequenza dell'esecuzione in base a quante operazioni (chiamate ai rispettivi programmi) sono in coda in quel momento. Una volta acquisito il lock e portata a termine l'operazione in corso parte il conteggio dei 5 secondi di ritardo e si ricomincia.

Ogni processo ha lo stesso comportamento. Al massimo attende qualche secondo in più in coda o presenta i risultati con qualche secondo di ritardo ma non sovrappone MAI le letture/scritture e minimizza, ottenendo come risultato il nostro piccolo miracolo.

Se non è chiaro provo a spiegare di nuovo, ma facendo qualche prova con più sessioni e il debug attivo non è difficile verificare cosa succede.

3) Tutti i dispositivi sono connessi in parallelo, ma a seconda del punto cavo in cui si trovano hanno o non hanno una resistenza (deve essercene una all'inizio e una alla fine del cavo). Nel mio caso il punto più lontano è l'inverter e ho attivato il carico resistivo con il suo switch. Ho 2 meter vicini all'inverter e sono collegati a stella/parallelo senza problemi nello stesso morsetto in cui ho l'aurora perchè sono cavi cortissimi. Ho un meter a metà ed è inserito sul cavo (sempre in parallelo), poi arrivo al convertitore USB dove in questo momento non ho resistenza, ma penso che sia interna all'adattatore, perchè mettendola gli errori aumentano.

C'è una cosa che mi ha dato molto da fare inizialmente che è la polarità del cavo (A-B). C'è chi dice che le indicazioni sui meter Eutron siano errate, quindi massima attenzione a mettere la polarità dell'aurora uguale a quella dei meter e corretta nell'adattatore. Io ho risolto provando un dispositivo alla volta prima di mettere insieme tutto.

4) Come cavo uso quello che ho, cioè un cavo tripolare (GND-A-B) schermato (schermatura collegata solo dal lato inverter) non ritorto. Per le mie distanze (sotto ai 20m) non ho avuto problemi. Gli adattatori che ho provato per ora sono tutti con almeno 3 contatti, ma ne ho ricevuto uno recentemente a 2 contatti, potrei provare anche con quello ma non mi aspetto differenze sostanziali. Anzi, potrebbe funzionare anche meglio...

Arrggg... Troppo gentile!!! A saperlo avrei potuto approfittare!
Facciamo così, beviti qualcosa alla mia salute che serve sempre!

/drk

@gianfrdp

con quelle riminiscenze di dos leggo nel file ADHT_metern.py

mi sembra di capire che se non legge il valore (come dice nel commentato) scrive "ERROR" ...

come potremmo scrivere il valore all'interno di /run/shm/metern6.txt??
dico una cavolata se modifico così

grazie

Ciao Ragazzi,
allora recentemente mi hanno connesso un impianto di tipo ASAP dove contrattualmente devo consumare il 70% annuo della mia energia prodotta, senza incentivo.
Partendo da questo punto, ho deciso di modificare un pochino metern per avere le letture su un singolo SDM120C considerando che l'impianto ha un solo contatore di scambio e quindi non esiste quello di produzione.
Ho aggiustato l'interfaccia secondo la foto allegata, e cercato di adattarlo alla mia necessità che è quella di leggere energia importata e quindi scambiata e energia esportata.
Non riesco però a mettere in grafico i prelievi, immissioni e autoconsumo, nonostante io legga i valori istantanei. Si tratta di un limite hardware o è possibile adeguare qualcosa?

Ho collegato una chiavetta wifi e ora ho 2 dispositivi USB
C'e' stato un momento che metern non si avviava nemmeno da pannello admin,ho riavviato e ora funziona sia il wifi e metern
C'e' quindi la probabilita' che si potessero invertire le porte USB e quindi fare riferimento al punto 9.1 della guida di flane?

root@raspberrypi:/home/pi# lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC


Pero' a questo comando il dispositivo USB visto e' solo uno:

root@raspberrypi:/# dmesg | grep ttyUSB*
[ 7.690478] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

EDIT:
Riavviando raspberry metern non si avvia piu'...nemmeno in admin
Sembra che vada in conflitto con la wifi

Giorno,
da quando ho installato la versione 1.6.6.3, 123solar ogni 2/2,5 giorni si blocca e per sbloccarlo devo fare un reboot del Rpi.
non basta stoppare e riavviare dalla pagina admin..
Ho notato che nel fil di log compare una riga un po strana...
la data riporta 1970 per poi tornare in quella successiva, normalmente...
il blocco è avvenuto verso le 10:20 di oggi.. il riavvio è stato fatto alle 10:59 circa..
Avete qualche idea?!?
di seguito il grafico.

La data 1970 mi farebbe pensare ad un riavvio "autonomo" del Raspberry con data/ora non correttamente reimpostata all'avvio.

La data 1970 e' il default di Unix (se non sbaglio) , se ne e' parlato all'infinito : quando il dispositivo parte e la rete non e' ancora pronta , lui va' con quella non aggiornata , lo sai quanti rosari ci ho tirato nel mio dove non avevo rete.....

A ok, perdonatemi se era gia stato evidenziato.. ma il post è diventato enorme e difficile da seguire..
Quindi quel 1970 viene fuori dal riavvio e non dal problema di 123solar...
123solar si avvia prima che l'Rpi riesca ad aggiornare la data.. poi quando lo fa, aggiorna il log in modo corretto....
Grazie!!!!!

Un forum funziona così, si possono trovare informazioni utili in mezzo alla discussione ma non è una guida. La ripulitura della discussione avviene in alcuni forum, ma richiede un po' di lavoro in più da parte dei moderatori della discussine e talvolta si rischia di cancellare troppo.
Se si vuole fare delle guidi occorrebbe utilizzare un sito fatto con wikimedia (tipo wikipedia) dove inserire solo le informazioni utili (anche ricavate da discussioni fatte altrove, ad esempio su un forum).
A mio parere, sarebbe sufficiente evitare i post fuori tema (i cosidetti OT), su questa discussione (Raspberry + MeterN) capitano spesso ...

@ miki8989
Più che modificare il programma python, modificherei lo script che lo invoca

scusa Gianfranco

intendi /etc/cron.d/dht22

grazie

Prova a mettere quelle righe dentro /usr/local/bin/dht22.sh (rendilo eseguibile) e poi lo invochi da /etc/cron.d/dht22
Metti la riga
in /etc/rc.local

inserite le modifiche e riavviato il rpy

vediamo domattina

grazie

C'è un errore nella sintassi del file dht22.sh. il file deve essere:

Nessun errore... l'ordine non è importante, quello che conta è che dopo il carattere \ ci siano 2 spazi (se lo metti prima)