Ciao Marco,
Leggendo la corrente istantanea puoi stimare la potenza massima assorbita, ma non é una vera misura.
Open energy monitor si può integrare facilmente, perché ormai gestiamo i floating point senza problemi.
Hai capito se in quel progetto ricavano l'energia (non solo la potenza)? Io non l'ho capito ed ho molti dubbi riguardo l'affidabilità della misura.
Leggere gli impulsi é la soluzione migliore.
Saluti,
Dario.
From mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Ma cosa sei riuscito a misurare con il loro codice? kW o kWh?
É interessante capire anche la configurazione hardware, per capire RAM rimane.
Dario.
From mobile.
Due misure saranno sempre diverse, ma un integrale senza RTC ed una gestione deterministica del codice non é fattibile, sono d'accordo.
Ero curioso di capire se loro l'avessero fatto, ma sembra proprio di no.
L'altro parametro sarà lo sfasamento.
Dario.
From mobile.
I tipici 5x sono tutti uguali a meno di unità di misura e fondo scala, per questo i valori sono letti con qualunque 5x.
Alessandro é molto affeziinato al suo vecchio tipico, forse per questo non aveva ancora implementato gli altri della 5x :)
Dario.
From mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
Ciao tonino
Ti posso confermare che il dht non ha nessun problema con la distanza, io ne uso 4 su distanze differenti il max che ho e di 15mt circa e lemletture sono perfette, testate con un termometro digitale , l'unica cosa alla quale devi stare attento e la sezione del cavo se troppo grosso potrebbe causare qualche problema, ma in 3 mt non credo.
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
No direi che non dovrebbe avere problemi, io ho utilizzato i cavi di rete (avevo una bobina da 300mt che mi avanzava!!) Tanto la tensione che passa e minima
Se interessa solo la potenza, si porta dwntro solo quel valore, in questo modo é discrezionale.
La questione del logging ha come sola strada l'uso di un terminale Android fisso in casa, da usare come server.
Per avere un idea, la versione A4 (8 slot, 10 nodi) usa dal 60% al 90% di RAM in base alla configurazione, non c'é spazio per fare logging.
Le cose migliorano con la A5 che a parità di RAM lavora con 35 slot e 30 nodi, ma ne resta in generale poca.
Sarà l'evoluzione di SoulissApp a determinare cosa poter fare, sui nodi la birra é finita. In questa ottica, il logging su Android andrebbe abilitato come per Zozzariello, in modo da averlo solo su un dispositivo centrale.
Dario
From mobile.
> --
> You received this message because you are subscribed to the Google Groups "souliss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
No lo monterò nella scatola della centralina ma li non ho il contatore. Non sarebbe una brutta idea sai? Il nodo dovrebbe solo contare i lampeggi e trasmetterli ogni unità di tempo (una qualsiasi, magari una o più volte al giorno) a Souliss, che si occuperebbe si fare la somma della cifra più alta, e solo di quella, rilevata tra le 00 e le 24. Chissà potrebbe funzionare?
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
Dai che con il codice pronto,copia e incolla,ci metti meno di Dario.... Stavolta lo freghi..... ;)
From Mobile Nexus
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
Il totale non e un gran che utile secondo me. Più interessante e prendere il dato ogni mezzora o un ora e poi portare a 0 il contatore per vedere il consumo nella vari momenti della giornata. Non e neanche necessario il reset manuale
Non può essere Lato android, il servizio che si può impostare a intervalli regolari ecc a fare la lettura?
Antonino senza un amperometro a pinza come potrei fare a tarare il sensore di corrente?
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Mi raccomando, già siamo in pochi... :)
Dario.
From mobile.
In effetti é un po tanto :/
From mobile.
Si cosi lo usavo per dimensionare batteria per i brushless di aerei radiocomandati... 12v per massimo 10a... Pero far passare nel mio tester 220v per 1000w della stufetta un po mi strizza!
Perché ti spaventa? Sono poco meno di 5 ampere. (1000/230) Il tester ne sopporta 20 in genere. Con 1000W mica lo bruci, al massimo si intiepidisce un po' il puntale. Roba di poco.
Certo prima assicurati di aver selezionato corrente alternata ed il plug corretto.
Si cosi lo usavo per dimensionare batteria per i brushless di aerei radiocomandati... 12v per massimo 10a... Pero far passare nel mio tester 220v per 1000w della stufetta un po mi strizza!
--
You received this message because you are subscribed to a topic in the Google Groups "souliss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/souliss/65P88NassUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to souliss+u...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
Che bellezza!
Bene bene :-)
--
You received this message because you are subscribed to a topic in the Google Groups "souliss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/souliss/65P88NassUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to souliss+u...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
--
Parlando di architettura, Souliss è effettivamente p2p ma esistono dei collettori. Principalmente SoulissApp su Android è un collettore dati, con funzioni simili (ma meno sofisticate) di storicizzazione e presentazione su grafici.Sono del parere che provare ad utilizzare emonCMS come strumento di visualizzazione dei dati, integrato con Souliss, sia un passo interessante.Inoltre sono da considerare gli errori di misura di tensione e corrente, che integrati possono divergere. Per questi motivi sono d'accordo nell'utilizzare un misuratore esterno e riportare la misura contando gli impulsi.Ciao Mattia,anche noi dubitavamo su come realizzare la misura dei kWh partendo dalle misure di tensione, corrente e sfasamento, lato scheda il problema principale è nell'assenza di un RTC, senza il quale la misura nel tempo andrebbe a divergere.
L'idea su cui stiamo orientando lo sviluppo è quella di introdurre in SoulissApp funzionalità (con abilitazione) da server, con l'obiettivo di ridurre l'hardware da installare in casa. Quando parlo di server, mi riferisco alla possibilità di collettare dati, eseguire logiche su eventi e presentarli verso l'esterno.
Resta sotto una rete p2p,dove è possibile costruire logiche con interazione diretta tra i nodi.
Nei prossimi sviluppi è previsto il supporto per i moduli radio NRLF, ho dubbi relativi all'utilizzo con batteria, perché le schede che orbitano attorno Arduino non sono propriamente parche in termini di consumi. Probabilmente con qualche accorgimento (come ad esempio escludere il regolatore di tensione) si può ottenere qualche risultato, ma è da vedere.
Lato softwarei driver radio funzionano su interrupt, lo stesso dovrà essere fatto per l'NRLF.
Per quanto riguarda Raspberry o Beagle board, possono essere pensate come hardware supportato in termini di collettore dati (come avviene in OEM) mentre vedo difficile giustificare l'uso di queste tipologie di schede come terminali diretti di attuazione.
In generale, la linea principale del progetto è quella di costruire funzionalità server attraverso SoulissApp, ma sarebbe assolutamente interessante introdurre altre interfacce in parallelo (interessanti sono openHAB e Lagardo SWAP), se si trovano persone con tempo a sufficenza si può tranquillamente aprire una nuova linea di sviluppo.
Parlando dell'integrazione tra il tuo sistema OEM e Souliss, dobbiamo capire cose/come integrare e dove inserirci. Sul tuo blog ho letto che hai già realizzato un'integrazione tra i dati metereologici e l'attivazione delle pompe, sarebbe interessante capire con quali strumenti.
Ti ho aggiunto nel progetto, adesso puoi modificare wiki issue ed altro.
http://code.google.com/p/souliss/people/list
Spingere verso il minor numero di periferiche che potenzialmente si possono rompere mi sembra una buona idea , sono pero' un po' dubbioso che una periferica android (e in generale una periferica che usa una sd come storage) sia adatta a storicizzare dati nel medio e lungo periodo.Per poter storicizzare non ci sono molte scelte se non un database (su android immagino sqlite) o qualcosa tipo timestore, che utilizza file binari e se si parla di storicizzazione di consumo di energia con una precisione decente si parla di una misura (che diventano almeno tre quando si aggiunge il calcolo KWh e KWh/d) ogni 5 secondi ... questo vuol dire un sacco di dati (il mio db Emoncms che memorizza circa 60 valori occupera' circa 500 mega/anno con mysql e 200 mega utilizzando timestore) e un sacco di scritture sul supporto di memorizzazione. Per esperienze dal forum di emoncms una sd di un raspberry con mysql che memorizza dati si corrompe in un tempo che va da qualche giorno a qualche mese ....
Nella mia idea di nodo a batteria con radio nrlf pensavo a una cosa come questa http://harizanov.com/2013/05/new-atmega32u4-board-to-use-with-nrf24l01/ con dei sensori attaccati .. naturalmente non avrebbe senso cercare di pilotare dei rele' o altra roba che richiede un sacco di corrente, ma andrebbe bene per raccogliere dati ... una scheda alimentata con 5V o12V la vedrei bene nel caso di installazioni dove portare il cavo di rete e' improbabile e dove si voglia spendere poco per la parte radio ....
Io sto studiando questa libreria https://github.com/maniacbug/RF24/ , che dovrebbe supportare una gestione del chip via interrupt (https://github.com/maniacbug/RF24/blob/master/examples/pingpair_irq/pingpair_irq.pde) eche ha anche un'implementazione di comunicazione distribuita tra piu' nodi (non peer to perr ma organizzati ad albero): http://maniacbug.github.io/RF24Network/
Per quanto riguarda Raspberry o Beagle board, possono essere pensate come hardware supportato in termini di collettore dati (come avviene in OEM) mentre vedo difficile giustificare l'uso di queste tipologie di schede come terminali diretti di attuazione.
Uso il raspberry per ricevere dati sia dagli emontx (che usano un chip radio diverso, un RFM12b) che da dei sensori di una stazione metereologica con un ricevitore RFM01, della stessa famiglia del RFM12 ma inizializzato con parametri diversi per capire il protocollo dei sensori, e li carico in emoncms dove ci faccio dei ragionamenti e eventualmente faccio delle segnalazioni (pompe accese, pioggia oltre un certo limite, consumo corrente oltre un certo limite)Uno degli emontx e' collegato su bus I2C con la scheda che monitora e controlla i contattori ai quali sono collegate le pompe, e contemporaneamente misura la corrente consumata solo dallle linee delle pompe. In questo modo posso monitorare lo stato dei galleggianti, l'avvenuta accensione delle pompe e l'effettivo funzionamento tramite la misurazione di corrente (se la pompa non parte la misurazione e' zero, se la pompa si intasa consuma meno watt di quando gira bene e posso generare un warning)Uso il raspberry anche per la gestione di emoncms, ma memorizzo i dati su un nas per non schiantare la sd card del raspebrry
Grazie, cerco di organizzare le idee, poi faccio delle proposte .. se intanto hai delle pagine in cui vorresti che l'inglese fosse 'aggiustato' mandami pure un elenco e mi metto al lavoro ....
Saluti,
Dario.
2013/10/23 Mattia Rossi <>Ciao, mi inserisco tardi nella conversazione ma solo in questi giorni sono venuto a conoscenza del progetto Souliss.--
Ho invece da qualche mese installato due nodi emontx comprati da openenergymonitor, e ho pasticciato un pò con le varie configurazioni di sensori e con EmonCMS, il software che openenergymonitor usa per raccogliere i dati dai vari sensori, e volevo se possibile contribuire alla conversazione per far capire la logica di funzionamento del sistema openenergymonitor.
Come da post precedenti la combinazione pinza amperometrica e trasformatore AC-AC, soprattutto con il CT da 100A e il circuito di OEM (OpenEnergyMonitor) hanno un margine di errore elevato quando i consumi sono sotto i 300W (nell'ordine del 10%) e ancor di più quando si scende sotto i 100W (oltre il 30%).
La scheda emontx ha anche la possibilità di usare un sensore ottico per contare gli impulsi del contatore (uno ogni Wh, 1000 impulsi=1KWh come già dettto nei post precedentemente), io ho avuto scarso successo con il sensore ottico, non so se l'ho fritto mentre l'ho collegato (col saldatore sono un pessimo soggetto) o se il tipo di sensore ottico dello shop non va bene per i contatori italiani .. se controllo con il tester i voltaggi sembrano a posto, e se lo tengo al buio non segna niente come dovrebbe, ma appena lo espongo a un minimo di luce mi genera interrupt in continuazione ... non ho idea se sia un problema mio, o del fatto che nonostante lo abbia attaccato al vetro del contatore con abbondante pasta tipo pongo continui a essere disturbato dalla luce dell'ambiente .... per stare dalla parte della ragione ho comprato un paio di contatori monofase con uscita open collector, che fanno la stessa cosa del contatore (un impulso ogni Wh di corrente che lo attraversa) ma generano l'impulso su due contatti collegabili direttamente a un pin di arduino.
Su questo post c'è la descrizione del setup ed il codice che ho usato per gli esperimenti: http://blog.mrossi.com/2013/10/arduino-pulse-counting-with-multiple.html )Per calcolare la potenza su un dato periodo l'emontx 'bara' nel senso che non fa il calcolo, ma invia le misure istantanee ad un'istanza EmonCMS, che è un applicazione basata su php+mysql (e nell'ultima versione anche su Timestore ) e a cui è demandata la funzione di storicizzazione dei dati e di presentazione di detti dati tramite interfaccia web. Una funzionalità di Emoncms è la possibilità di processare i dati in arrivo per calcolare valori accumulati nel tempo, con particolare attenzione al consumo energetico (quindi KWh, KWh/giorno), ma anche valori differenti come temperature o livelli.
EmonCMS è un sistema orientato all'accumulo e visualizzazione di dati, non ha internamente il concetto di controllo o automazione, ha solamente la possibilità di generare determinati eventi configurabili come invio di notifiche/email/http get all'accadere di certe situazioni
Direi quindi che l'approccio OEM (un server che colleziona dati basato su DB+storage, nessuna possibilità di controllo e gestione degli eventi macchinosa) è diametralmente opposto all'approccio Souliss (sistema distribuito/comunicazione peer to peer/funzionamento indipendente dei singoli nodi) e che i due sistemi svolgono funzioni diverse.
Nei prossimi giorni cercherò di studiare un pò il funzionamento di Souliss per cercare di dare qualche suggerimento costruttivo (al momento sparerei solo cagate, temo) su come eventualmente implementare la funzionalità di storicizzazione dei dati in modo da non stravolgere l'approccio distribuito/peer to peer.
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
So che Alessandro non é tanto affezionato all'idea, ma i problemi di connettività e batteria si risolvono con un dispositivo dedicato ed installato nella LAN.
Il discorso della frequenza dei dati é un punto interessante, Mattia potresti allegare un csv dei tuoi consumi? Da li possiamo facilmente stimare la quantità di dati da immagazzinare con una variazione al 5%.
@Alessandro, una cosa che non mi é chiara é sull'uso del servizio periodico di background.
A SoulissApp arrivano e sono visualizzate correttamente le variazioni dei valori analogici, senza dover usare il polling.
Nel database, questi valori sono utilizzati o sono memorizzati solo i valori acquisiti in polling?
A memoria io avevo un nodo con il polling di background a 45 minuti e riusciva a loggare correttamente i valori di temperatura. Non mi sembrava lo facesse ogni 45min, ma su variazione. Mi sbaglio?
Dario.
From mobile.
E' un aspetto interessante, come nota posso dire che nel caso nostro non c'è un polling ma una trasmissione su evento. Quindi i valori sono comunicati in base ad una deadband, riducendo il quantitativo di informazioni da immagazzinare.
Il database gira su SQLite e non è su SD card, però lascio ad Alessandro (autore di SoulissApp) la risposta con maggiori dettagli.
Di sicuro utilizzare dispositivi Android ha diverse controindicazioni, questa è potenzialmente una. In base allo scopo dell'installazione può valere la candela o meno usare Android con funzioni da server.
E' una scheda interessante, anche perché nasce direttamente per l'uso con batteria. Se il lavoro è fatto bene, dovrebbe avere un bootloader con le funzioni non necessarie disabilitate. Molto comunque dipende dai sensori collegati e dall'energia richiesta.
Per un nodo del genere, andrebbe introdotta la modalità sleep, in modo da spegnerlo periodicamente ed accenderlo per effettuare la misura ed inviare i dati su variazione (non periodicamente). Questo approccio (non periodico) funziona bene con Souliss, mentre non so se emonCMS richieda dati ad intervalli regolari.
Anche io pensavo di utilizzare quella, estraendo la sola parte SPI<->Radio, il resto è già dentro Souliss e quindi funzionarebbe direttamente in p2p.
Quelle che ho scritto io hanno tutte un'inglese da sistemare, ma più che la grammatica mi interessa il tuo contributo nell'integrazione tra Souliss ed emonCMS ;)
So che Alessandro non é tanto affezionato all'idea, ma i problemi di connettività e batteria si risolvono con un dispositivo dedicato ed installato nella LAN.
Il discorso della frequenza dei dati é un punto interessante, Mattia potresti allegare un csv dei tuoi consumi? Da li possiamo facilmente stimare la quantità di dati da immagazzinare con una variazione al 5%.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Al posto di usare quel costoso sistema, si potrebbe optare per sw e hw open,come da filosofia Souliss...Freenas ne può essere un'esempio,presumo si possa anche adattare ad hw low cost e open come raspberry/beagle...
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Io sto lavorando ad un'applicazione apk separata che faccia da collettore dati da Soulisapp e li invii.... da qualche parte. Ho deciso di iniziare da xively, per il quale esiste già una demo su Android. (solo scheletro per xively)
Non prometto nulla sui tempi, ma piano piano ci arrivo.
Io sto lavorando ad un'applicazione apk separata che faccia da collettore dati da Soulisapp e li invii.... da qualche parte. Ho deciso di iniziare da xively, per il quale esiste già una demo su Android. (solo scheletro per xively)
Non prometto nulla sui tempi, ma piano piano ci arrivo.
--
--
You received this message because you are subscribed to a topic in the Google Groups "souliss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/souliss/65P88NassUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to souliss+u...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
Pensando al nrfl, basta inserire un taglio nel driver oltre il 32byte e riempirlo in ricezione con tutti zero.
Complessivamente ci sono 15 byte di header, gli altri 15 saranno stati. Il risultato sarà che sui nodi con nrfl non sarà possibile usare più di 15 slot, ma sarà trasparente per gli altri nodi, che vedranno tali slot come inutilizzati.
Dario.
From mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
--