se vi dovete orientare su un minipc, vi consiglio uno con cpu j4125

Di recente ho fatto una specchietto con i vari modelli di processori, la loro potenza e il consumo, usando il sito di Passmark.
Mancano solo i nuovi Alder Lake serie N che forse non sono ancora usciti ma che promettono prestazioni incredibili.

Il primo della lista BCM2711 è la CPU del Raspberry Pi4 ....

Eccoli:

bella questa cosa, se non avessi già preso l'Esprimo con il 4590T l'avrei analizzata bene

però nel caso si voglia fare un sistema multi-app è meglio verificare che il procio supporti le istruzioni di virtualizzazione, lì non te l'hanno specificato

Con i docker non serve la virtualizzazione. Il VT serve se vuoi fare le macchine virtuali, ma il concetto dietro i docker è proprio quello di evitare le VM ;-)

sì non ci sono VM 'classiche', ma mi par di leggere che, dovendo comunque emulare, Docker richieda questa capacità, anche in Linux

https://docs.docker.com/desktop/install/linux-install/

Questo il "log di sistema"...............

Stanno girando Domoticz, Grafana, InfluxDB, Webmin Server,Apache, Gateway Mysensors con un centinaio di periferiche, 123Solar
Il tutto con Ubuntu Server su un Thin Client HP T510
notare l'occupazione di memoria e le "risorse di macchina"............................na roba che Ws si sogna tutti i giorni da sempre

Ah, ma quello è Docker Desktop che è un ambiente isolato in una macchina virtuale per far girare immagini docker.

Ha senso se hai Windows, per crearti un ambiente docker in una vm con dentro uno pseudo linux per far girare docker.

Onestamente, non ha senso.
Se stai facendo un miniserver, fallo direttamente con una distro linux e installa direttamente docker, senza usare una VM o Docker Desktop

Mi sono finalmente arrivati gli Shelly Pro 3EM con cui inizierò a integrare meglio il controllo consumi rispetto a quello che potevo fare con lo Shelly Pro 4PM che avevo preso ad inizio anno.




L'intenzione è eliminare gli SDM230 (a proposito, ne ho 4-5 in vendita, di cui 3 nuovi) e usare solo Shelly in configurazione centralizzata con Docker e Raspberry (o mini-pc), semplificando anche tutta la parte di creazione dell'ambiente, se riesco con un solo script !

A presto.

PS:
Li avevo ordinati in pre-ordine da Shelly Italia ai primi di febbraio ... venerdì ancora non erano arrivati (non sapevano se e quando sarebbero arrivati). Molto gentili nell'annullarmi l'ordine e (spero a breve) rimporsarmi.
Ordinati da Shelly.cloud, arrivati in 2 giorni (con DHL).

Pace.

Ciao a tutti,

vi aggiorno sugli avanzamenti nell'uso dei nuovi Shelly Pro 3EM.

Intanto una info: dei due che sono arrivati, e che vi ho mostrato nel precedente post, me ne funzionava SOLO uno.
L'altro è arrivato completamente morto. Ho provato a resettarlo come descritto nelle istruzioni. Ho contattato il supporto tecnico (di Shelly.cloud) e dopo una prima risposta in 2 giorni, ormai è da altri 5 che attendo supporto ... spariti, latitanti ... boh. In ogni caso tutti i loro suggerimenti per resettarlo sono falliti. Morto era e morto continua ad essere.

Nel frattempo giusto oggi mi è arrivato il rimborso da Shelly Italia ... non velocissimi ma onesti.

Tornando a noi.

Ecco una foto del nuovo Shelly installato affianco al mio attuale SDM230.



Al momento lo Shelly lo uso in parallelo all'SDM230 e monitoro esattamente le stesse cose: lo scopo è capire se i due dati sono sovrapponibili e fidarmi di quanto letto da Shelly.
NOTA BENE: Ho un solo SDM230 per la linea principale, perchè i dati del solare li leggo direttamente, in ModBus, dall'inverter Solaredge.

In questi giorni ho impiegato un po' di tempo per capire come sono organizzare le API di Shelly e come (e soprattutto) strutturare le informazioni su influxdb.
Questa è una prima versione del formato dati, per ora non mi soffermerò nel descriverlo ... lo farò in un apposito post quando avrò verificato che funzioni tutto.



Come unica informazione utile, il tag SOURCE è fondamentale perchè mi differenzia le informazioni lette, se contatore (main) o solare (solar), in pratica quello che su Shelly leggo come fase A (campi che iniziano con a_) e fase B (campi b_)
Inoltre questa struttura dovrà garantirmi la possibilità di migrare i miei 3 anni di dati che ho finora caricato dall'SDM.

Come dicevo in un precedente post, InfluxDB in versione 2 è COMPLETAMENTE diverso, a livello di gestione, rispetto al primo.
Per cui anche l'integrazione e configurazione cambia del tutto.
Sarò più preciso in futuro.

Intanto allego (telegraf.configurazione.txt) anche il nuovo telegraf per importare i dati dallo Shelly.
E' un po' lunghino perchè:

- da una parte Shelly propone i dati di import/export in una API separata rispetto ai dati di consumo istantaneo
- dall'altra telegraf non permette di taggare al volo i dati, per cui devo leggere da Shelly due volte i dati a_ (per me la linea del contatore) e i dati b_ (la linea del solare), per due API distinte. Ecco perchè nello stesso telegraf ho quattro configurazioni [input.http]


Ho già detto troppo ... se alcuni passaggi non sono chiari proverò a spiegarli meglio.

Un saluto.

Primi esperimenti di caricamento dati dallo Shelly Pro 3EM, rispetto al mio precedente SDM.

Premessa: ricordo che al momento (rispetto all'inizio del progetto) ho un solo SDM che monitora il contatore principale in prelievo e immissione. Il monitoraggio del solare lo faccio direttamente via Modbus dal Solaredge via TCP.

Detto ciò, questo è un primo risultato:


Il alto il grafico classico, ovvero quello attuale, sotto quello aggiornato con lo Shelly:

• In alto, in giallo + azzurro, il solare ovvero SolarEdge +Shelly,
• al centro il consumo totale rosso + azzurro, ovvero (SolarEdge + SDM) + Shelly,
• in basso, la terza serie, in verde + fucsia, è il prelievo/Immissione, ovvero il contatore principale, ovvero SDM + Shelly.

Come potete vedere i grafici sono quasi sovrapposti correttamente, c'è solo uno sfasamento sulla serie del solare: evidentemente il Solaredge è più preciso e/o ottimista e/o impreciso. Non saprei, di sicuro l'inverter calcola i suoi watt "da dentro".

Qui uno zoom (poco più di 1 minuto) sulla differenza:



Il valore è variabile, ma mediamente ballano 30-40 watt. L'inverter ha un grafico più a sega, sembra che aggiorni i valori con meno frequenza rispetto a quelli che elabora lo Shelly.
I campionamenti sono sempre a 5 secondi.

Ma come avete visto nella prima immagine in ogni caso, con un livello di zoom di ore, la cosa non si nota.

Rimane comunque il fatto che lo Shelly calcola sempre 40-50 wh in meno.

Nel prossimo post (divido per comodità) farò invece una comparazione che mi preoccupa di più, ovvero quella dell'import/export.

Come detto nel post sopra, qui voglio comparare invece le statistiche di import / export totali (ovvero in un determinato tempo)



Qui sopra, in alto il mio precedente grafico, con i dati che vedete in legenda e nel grafico sotto quello con lo Shelly

Per quanto riguarda la comparazione con l'SDM i dati "puliti", comparabili con lo Shelly perchè contati direttamente sul cavo del contatore principale, sono:

• prelievo (viola)
• immissione (verde)

Tutti gli altri sono calcolati usando il solare (lo vediamo dopo).

Ebbene:

• prelievo: 3kw di differenza
• immissione: 12kw di differenza

Questa differenza mi preoccupa: essendo il prelievo molto poco, la differenza è poca, l'immissione è molta la differenza è maggiore. Ad occhio la differenza è dell'1% che se non erro è quanto dichiarato dallo stesso Shelly. Ad onor del vero anche SDM dichiare +-1%.

Invece sul solare la differenza è abissale, 1kw quasi tondo tondo in circa 6 ore.

Il problema è che non so cosa pensare.
So solo che, rispetto ai conteggi del GSE, i miei sono praticamente uguali: ad esempio un mese ho registrato 416 di prelievo e 303 di immissione, il GSE 418 e 302. Quindi 2 kwh e 1 kwh di differenza !
Al momento invece lo Shelly registra di meno, quindi la differenza sarà sicuramente maggiore.

Si parla sempre di numeri piccoli, ma come si sul dire .... "per la precisione" !

Per ora questo è lo stato dell'arte.
Continuerò a monitorare.

Altro problema sarà invece registrare i valori import/export dello Shelly (che parte da zero come valore di import/export) come "continuazione" del precedente, ovvero aggiungendoci un offset.
Su questo punto devo ancora ragionarci sopra, se aggiungere l'offset in fase di salvataggio del dato (ovvero da telegram, se fattibile) o calcolarlo tutte le volte su Grafana.

A proposito di Grafana,

segnalo una feature che a suo tempo, ovvero alla creazione di questo thread, mi pare non esistesse:



Ovvero la possibilità, invece di creare una Query (come le prime 3 in linguaggio Flux verso Influxdb 2) per fare i calcoli (in questo caso del CONSUMO e dell'AUTOCONSUMO), di creare una cosiddetta Expression che usa i risultati di cui sopra e con un semplice

$produzione - $immissione

crea una nuova serie.

Mi ricordo al tempo che per creare questi due valori siamo dovuti impazzire non poco con delle query molto complesse.

Non so bene da che versione di Grafana le Expression sono state create (da una rapida ricerca direi dalla 8.4 o 8.5), ma finalmente hanno implementato quello che già a suo tempo mi chiedevo come mai non ci fosse !!

Intanto ti faccio i miei complimenti per questa integrazione con Grafana, lo uso da anni integrato con altri sistemi di monitoraggio reti ed è veramente ottimo.
Ma tornando in tema, a questo punto suggeriresti di passare direttamente ai Pro 3EM per mettere su un monitoraggio come si deve?

Ciao, dipende da cosa hai tu oggi e cosa sostituiresti con Pro 3EM. Come dicevo, lo sto sperimentando ... e proprio da pochi minuti ho finalmente montato il secondo



Al momento è in parallelo al Pro 4PM ... voglio vedere che numeri danno, poi il 4PM lo userò in altro contesto visto che come Energy Meter non si può usare (ma solo come monitoraggio di consumi istantanei).

Di sicuro i Pro hanno una marcia in più rispetto agli altri, non fosse solo per la presa di rete e per la nuova API del Gen2.(anche il vecchio Shelly 3EM era un Gen1)

Non andrei a sostituire nulla di interessante, ho uno Shelly EM ma è messo lì così, giusto per dare uno sguardo ai consumi e alla produzione ma non ho mai avuto il tempo di farci qualcosa di interessante.
Ora che sto tirando su un po' di monitoraggi vari mi piacerebbe fare qualcosa di un po' più serio, affidabile e che possa darmi qualche valore utile.
Avevo in mente di prendere un paio di SDM230 ed integrarsi con una esp32 per bypassare il fatto che il quadro elettrico è abbastanza lontano da dove si trova il server.

Un 3em invece risolverebbe questo problema (altro punto a favore il fatto che abbia l'ingresso per la rete e non solo il wifi).

Si, nelle mie intenzioni vorrei fare proprio questo: sostituire l'SDM230 (ne ho appena rivenduti 3 che avevo comprato tempo fa per fare una serie di monitoraggi) con lo Shelly Pro 3E. Mettici sempre il Pro davanti perchè lo Shelly 3EM è un vecchio modello Gen1, senza presa ethernet e con API diverse rispetto ai nuovi Gen2 ;-)

Ne parlo anche qui

https://www.energeticambiente.it/fon...76#post2235976

Mi autoquoto per tornare un attimo sul mini-tema "mini pc per monitoraggio" ...

Benchè al momento sto usando un Raspberry Pi4 con 2GB, ho paura che a tendere non possa essere sufficiente ... in futuro credo che mi lancerò anche con Home Assistant ( che al momento NON sto studiando perchè sono concentrando su questa revisione del monitoraggio) e altri usi ....

Pertanto ho deciso di migrare su un mini server un po' più robusto e performante. Alla fine, studiando tutti i vari modelli di processori (che sono tantissimi), fra cui anche il j4125 consigliato da stiwy81 (TDP da 10W con un CPU Mark di 2980), e vista la non grande differenza di prezzo fra le serie J ed N, ho optato per un N5105 presente nel NUC di Intel modello NUC11ATKC4

https://www.intel.it/content/www/it/...fications.html

Questo modello sempre con TDP da 10W ha un CPU Mark di 4084.
C'erano alcuni modelli con i nuovi N95 e N100 ma troppo prematuri e cari, al momento presenti solo con modelli cinesi.
Alla fine sull'Amazon spagnolo l'ho comprato a 150 euro, in modalità barebone. Le RAM le avevo già da vecchi ricicli e ho solo dovuto comprare un SSD che in questo periodo sono in forte discesa di prezzo.

Finite tutte le migrazioni potrò mettere in vendita il Raspi allo stesso prezzo ;-)

Se vi interessano le mie peripezie e analisi con gli Shelly, nella relativa discussione porto qualche analisi recente non molto positiva ...

https://www.energeticambiente.it/fon...35#post2238635

Da possessori di due di questi NUC non posso che dirti che hai fatto un ottima scelta

Oggi anticipo un argomento del nuovo progetto che mi sta facendo pensare da tanto tempo.

Premessa: come sapete ho deciso di migrare a InfluxDB2 + telegraf ... è tutto molto integrato, ve lo spiegherò meglio più avanti. Sono a buon punto e anche le sperimentazioni con il nuovo Shelly Pro 3EM vanno abbastanza bene, a parte il discorso della precisione sul solare che al momento non ha una soluzione.

E a parte un momento di panico nella giornata di ieri quando (e chissà da quando) sia lo Shelly che il vecchio Raspberry+SMD erano praticamente irraggiungibili: lentissimi e spesso si sganciavano dalla rete portando telegraf a fallire la maggior parte dei caricamenti.
Dopo varie sperimentazioni ho scoperto l'arcano: il Raspberry, non so perchè, era attestato sul WIFI 2.4Ghz (WIFI4), così come lo Shelly. Praticamente si s*****ttavano per conquistare la banda (sono uno a 5 cm dall'altro): Dopo vari tentativi sono riuscito a far agganciare il Rasp al WIFI5 (ac) e da allora tutto è tornato al suo posto.
Aspetto interessante da ricordare.

Ma veniamo a noi.
In questa versione 2.0 del mio progetto rimaneva una questione che mi assillava da mesi: come gestire l'inserimento di un nuovo meter e fare in modo che alle statistiche rimanesse tutto trasparente ?

Spiego meglio.
In questi 3 anni ho monitorato giorno per giorno la produzione del solare (ad esempio, il 1 Maggio 2023 il dato che arrivava diretto dall'inverter era 23863, ovvero 23.863Mwh), quando domani 6 maggio 2023 userò lo Shelly per monitorare questo dato, il suo contatore sarà a 0. Il 30 Maggio sarà magari a 1000.
Quindi, se vorrò fare una statistica sulla produzione totale di Aprile, dovrò prendere il valore al 30 aprile e sottrarlo con quello al 1 aprile, ad esempio 23850 (poco meno di quello del 1 maggio) e 23000 = 850 Wh prodotti. Perfetto !
Se invece voglio monitorare la produzione di Maggio (dal 1 al 30 Maggio) dovrò prendere i due valori, 1000 (dallo Shelly) e 23863 = un valore scorretto !

Le strade erano due: lavorare su questo concetto di "offset" del nuovo meter direttamente sul dato, o gestire la cosa in fase di elaborazione del grafico/dato.

La seconda era impervia ... in ogni grafico di dovrei ricordare quando ho switchato il meter e gestirne l'offset.

La prima complicata anche lei, perchè telegraf non permette troppe manipolazioni di dati ...

Un'altra soluzione, simile a quest'ultima, era l'implementazione di una specie di "proxy" delle chiamate alle API che richiamavano quelle reali e poi prima di restituire il dato lo correggevano con l'offset: necessità di programmazione, non molto complessa, ma c'è sempre un livello in più di complicazione.

Alle fine, per ora, sto sperimentando la soluzione telegraf: che in realtà permette la manipolazione del dato, attraverso un cosiddetto "processor". In particolare il processor utilizzato è quello chiamato "Starlark"

Qui la documentazione:

https://github.com/influxdata/telegr...lark/README.md

Mette a disposizione un vero e proprio linguaggio, e a parte una fase iniziale in cui nono riuscivo neanche a farlo partire (per indentare bisogna usare gli spazi e non i tab .... sigh), alla fine ho implementato questo codice (ancora di prova):

La prima parte è quella degli input, ovvero la lettura dallo Shelly, prendo import ed export e li rinomino: da a_total_act_energy a semplicemente import e così anche per export.
Poi aggiungo il tag "solar" (l'altro è "main", qui non si vede) a questi due dati per poi filtrarli al meglio in fase di query.

E poi opero la magia: il processor.starlark, prende il campo export (semplifico con un solo campo), lo mette in una variabile chiamata solarexport, poi sovrascrive il campo export con solarexport+23863 e poi crea un campo nuovo chiamato export_original con il valore letto all'inizio, ovvero il vero valore in arrivo da Shelly.

In questo modo il vecchio valore di export (23863) proseguirà la sua storia dal primo giorno con i nuovi valori in arrivo da Shelly che invece iniziano da 0.
In più mi memorizzo il valore reale dello shelly perchè ... non si sa mai !

Cosa ne pensate ?
E' una buona strategia ?
Voi l'avreste fatta in altro modo ?
Vi è mai capitato uno scenario del genere con i vostri sistemi di monitoraggi ?

Fatemi sapere i vostri pareri !

PS: post lunghissimo ... spero di non aver scritto troppi strafalcioni e si capisca un minimo :-)

PS2: questo "starlark" ha una controindicazione che per ora vi risparmio ... non è bloccante, si può risolvere, ma mi ha stravolto un po' la gestione del tutto ... se vi interessa approfondisco anche questo aspetto.

glfp hai già comprato il minipc? altrimenti ti consiglio di prendere un minipc con n5105 con 4 porte da 2,5gb che userai anche come router e nas sinology virtualizzando tutto... farai upgrade alla tua connessione internet con OpenWRT e alla tua rete locale LAN a 2,5gbits al costo di circa 130 euro memorie e dischi esclusi.
per la configurazione del tutto con proxmox ti posso aiutare io dall'inizio alla fine.

utilizzo cpu in media sul 12% , le VM che ho e i container in esecuzione negli allegati. speedtest internet ftth 2200mbit in download con openwrt virutalizzato. la rete lan si muove sui 2,36gbits

Ciao frezeen
scusa il ritardo nella risposta ma ero in ferie :-)

Alla fine avevo preso già ad Aprile un NUC11ATKC4 con Intel N5105, uno dei più performanti della precedente generazione (che poi è quello che mi consigli). Pagato 169€,cui ho aggiunto solo un SSD Crucial da 1Tb a 54€, le ram invece le avevo già (16GB)
Non ha la porta 2.5Gb ma d'altronde non ho la catena per gestirla...
Per curiosità che modello mi avresti consigliato ?

Complimenti per la lista di container ... io sono in un momento di pigrizia dovuta alla delusione degli Shelly e devo riordinare le idee su cosa fare ... ne ho parlato qui

https://www.energeticambiente.it/fon...35#post2238635

Io ho già un NAS separato e quindi non ho bisogno di usarlo per tale scopo, ma d'altronde usare un MiniPC come NAS non lo vedo molto pratico (tu fai tutto via USB ?)
Mentre per la parte Router, ho già tutta una catena basata su Ubiquiti con cui mi trovo molto(issimo) bene !

A parte tutto, come ti dicevo, sono in un momento di stanca ... speravo tanto in questi Shelly ma ora mi trovo sulle croste due Pro EM3 che danno valori sballati ... quelli di Shelly mi hanno detto di aprire un ticket per capire bene il problema ma onestamente non ne ho voglia. Devo a questo punto tenermi il Raspberry come collegato all'SDM ... non è il massimo come "lunghezza" della catena, ma almeno i dati si Metering sono affidabili. Peccato che qualche mese fa ne ho venduti 3 pensando di risolvere tutto con gli Shelly !

ciao, io ho una daikin EBLA (altherma 3 M) ed è da diverso tempo che vorrei iniziare il monitoraggio tramite ESPaltherma, avevo anche già letto GitHub ma non è semplicissimo... cmq ho già in funzione un NAS con home assistant.

per favore mi potresti indicare dove hai acquistato m5StickC e se occorre altro hardware ? grazie mille

Partendo dalle guide di glfp ho recuperato un raspberry pi4 che stava prendendo polvere in uno scatolone di un amico e sto provando a mettere in piedi il sistema di monitoraggio.
Dispongo di 4 misuratori di energia comunicanti in Modbus da cui raccolgo già alcuni dati, senza le possibilità di elaborazione, storicizzazione e presentazione che vedo sulle vostre installazioni Influxdb + Grafana, motivo per cui sto cercando di far funzionare il sistema su raspberry per abbandonare poi l'esistente

La rete modbus (funzionante con l'altro sistema) è composta da
Indirizzo- Funzione - Misuratore - Dati essenziali
Address 1 - Misuratore PdC - Ime Conto D2 - Potenza assorbita
Address 2 - Misuratore FV - Ime Conto D2 - Potenza prodotta
Address 3 - Misuratore Casa - Ime Conto D4 - Potenza assorbita
Address 4 - Misuratore Contatore - Ime Conto D4 - Potenza assorbita & Potenza venduta

Ma... mi fermo quasi subito all'importazione dei dati da sistema Modbus seriale tramite interfaccia usb.
Influxdb, versione 2.7.4, mette a disposizione la possibilità di realizzare la query di chiamata, ma non riesce di compilarla in modo che piaccia al sistema.
I misuratori di energia non sono inclusi in quelli riconosciuti da MBMD quindi l'ho saltato..

Chi mi può aiutare con l'impostare la chiamata giusta per importare i dati su influxdb'
Ovviamente i misuratori forniscono molti altri dati oltre alle potenze, ma se già non riesco a importare quelle inutile complicare le cose!

Ciao DavidePa , felice di essere di esempio a qualcuno col mio vecchio progetto.

Ovviamente quella è più una traccia, perchè le varianti sono tantissime.

Ad esempio tu hai del meter non compatibili con MBMD (che ne ha già tanti !) e quindi c'è un primo scoglio.
Anche influx v2, rispetto al mio progetto, è un altro bel salto quantico in quanto le query vanno riscritte tutte in linguaggio Flux. Pensa che invece con la versione v3 stanno tornando all' SQL ... 'mortacci loro.

In realtà ho già quasi pronto il progetto v2 che usa influx v2 con quasi tutte le query/grafici rifatti in flux, ma ho ancora bisogno di sistemare alcune cose soprattutto relative alla nuova interfaccia verso il modbus di cui discuto qui

https://www.energeticambiente.it/fon...e-funzioni-api

E' un progetto molto lungo e anche migliore perchè separo (disaccoppio) il formato di lettura da quello di storicizzazione su Influx ... Influx che con gli scherzi sui linguaggi vorrei anche eliminare a favore di altri timeseries (ad esempio Timescale).

Non ho capito bene cosa intendi con "Influxdb, versione 2.7.4, mette a disposizione la possibilità di realizzare la query di chiamata" ?
Intendi l'integrazione con Telegraf tramite il plugin Modbus ? https://github.com/influxdata/telegr.../inputs/modbus

In effetti quello permetterebbe di evitare l'uso di MBMD che al momento ancora uso in vari scenari (per leggere direttamente il mio meter via Rasp e un'altro via Protoss, ma a tendere entrambi via Protosso + modbus tcp).
Certo, bisogna conoscere i registri del meter e configurarlo ... non ho mai provato ma potrebbe essere interessante farlo insieme, io sugli SDM e tu sui tuoi !

Velocissimo, e grazie per la pazienza!

Viste le tante differenze legate alle diverse versioni di Influx e Grafana, adesso vado a leggere le tue considerazioni e prove sul progetto v2.

Per il mio problema, hai capito bene nonostante la mia poca chiarezza.
Visto che MBMD non riconosce i miei meter ho provato l'integrazione con Telegraf tramite il plugin Modbus.

Dei miei meter conosco "tutto" quello che serve per recuperare le informazioni dai registri (ho le tabelle complete dei registri ma anche già gli indirizzi utilizzati dall'altro sistema per puntare e leggere correttamente), quindi mi occorre capire come tradurre in linguaggio adatto a Telegraf queste informazioni.
E una volta capito il linguaggio necessario, sono sicuro che basta trovare le tabelle dei registri degli SDM per replicare la cosa sui tuoi meter (che non conosco ma immagino che il produttore metta a disposizione queste tabelle)

In realtà la discussione sarebbe questa, ma ho voluto separare alcuni aspetti più specifici in altre discussioni per poi riassumere tutto qui una volta finito tutto .. come vedrai in altre discussioni, un'altra è questa

https://www.energeticambiente.it/fon...elly-em/page28

sto anche smanettando (con alti e bassi) con gli Shelly EM ...

Per quanto riguarda i tuoi contatori, se ho capito bene dei IME Conto, le specifiche dei registri le ho trovate qui

https://www.imeitaly.com/wp-content/...CE4TBDTMID.pdf

qui invece trovi un esempio di uno

https://vleeckf.medium.com/weekend-p...a-770480136410

in uno scenario come il nostro (modbus + seriale + rasp)

Non so quanto sei avvezzo con la programmazione, ma ad occhio mi pare che te la cavi ;-)
Potresti anche provare a fare delle prove di lettura con questo client modbus

https://github.com/favalex/modbus-cli

Prova e poi magari ci confrontiamo in PV ;-)

Ciao.

Approfondisco l'esempio, provo ad adattarlo al mio meter, e ti aggiorno!

Da autodidatta, approfondisco e non mi arrendo al primo insuccesso.. conto di superare lo scoglio di capire il funzionamento del raspberry, con alti e assi di tempo a disposizione, quindi non sempre celermente!

Buongiorno e buon anno a tutti !

Fra un panettone e l'altro, sollecitato dai messaggi subito qui sopra del novizio ma volenteroso DavidePa , ho provato ad usare il modulo telegraf chiamato modbus e descritto qui

https://github.com/influxdata/telegr.../inputs/modbus

Era una opzione che non avevo mai valutato, anche perchè inizialmente mbmd mi aveva sempre dato le giuste soddisfazioni, e poi mbmd stesso caricava i dati su Influx v1 quindi il processo running era sempre e solo 1, così come da schema riportato nella prima pagina di questa discussione

https://www.energeticambiente.it/fon...91#post1836891

Quindi avevo questo schema

raspberry -> mbmd via modbusRTU -> chiavetta USB -> SDM230 (sia per contatore energia che contatore FV)

Abbastanza presto (causa rottura dell'SDM) ho eliminato l'SDM del contatore FV e recuperato i dati direttamente via inverter Solaredge via modbusTCP con questo schema

raspberry -> mbmd via modbusTCP -> solaredge

In questi caso mbmd carica di dati sull'influx v1 del raspberry e dallo stesso accedo alla console grafana.

In questo ultimo anno, come già accennato in questo gruppo tempo fa, sto lavorando - piano piano - alla versione 2.0 di tutto la piattaforma usando Influx v2 che mi ha costretto a rivedere tutte le query e i grafici.
Non solo ho rivisto l'approccio al caricamento dei dati (che spiegherò bene quando sarò pronto per lo spiegone ...) ma ho anche iniziato a monitorare altri apparecchi integrando per esempio degli Shelly EM (con pessimi risultati)

https://www.energeticambiente.it/fon...35#post2238635

e quindi tornando indietro sugli SDM ma con un approccio che non passi dal raspberry ma usando degli scatolotti alternativi come i Protoss che discuto qui

https://www.energeticambiente.it/fon...14#post2259814

Nell'ottica del disaccoppiamento ho quindi evitato di far scrivere a mbmd i dati sul DB nel suo formato ma ho uniformato una batteria di telegraf che caricano i dati da ovunque e li scrivono sempre allo stesso modo, ad esempio la lettura dell'inverter di cui sopra al momento è in parallelo in questa forma

server -> telegraf via http -> mbmd via modbusTPC -> inverter

questo grazie al fatto che mbmd espone i dati letti via modbus anche attraverso una sua interfaccia web con API json.

Ovviamente in questa modalità c'è bisogno di due processi, uno per telegraf e uno per mbmd, sono piccolissimi e non danno problemi di occupazione di ram o cpu, ma sono sempre dei processi in più da dover monitorare e gestire in caso di problemi.

Il plugin di telegraf chiamamo modbus risolve questo problema riportando tutto ad un solo processo secondo questo schema

server -> telegraf via modbusTPC -> inverter

oppure nel caso del Protoss collegato all'SDM

server -> telegraf via modbusTPC -> Protoss via modbusRTU -> SDM

Che dire ?

Funziona tutto bene, al momento sto ancora testando la robustezza e ancora non carico di dati sul db ma solo su log.

Qui di seguito la configurazione del plugin.

e un esempio di output (al momento in json ma poi andrà direttamente su DB)

Gli address sono quelli facilmente recuperabili dalla documentazione degli SDM e modificabili con quelli del proprio Energy Meter o fan o coil.