Script virtmeter.php [GUIDA]

[miki8989]

anche a me stesso problema...
rimesso la vecchia versione è tornato tutto a posto...

ciao

[Flane]

se il cruscotto va a zero significa che avete qualche comando sbagliato........ fate i test dei vari camandi

[TonyP62]

se il cruscotto va a zero significa che avete qualche comando sbagliato........ fate i test dei vari camandi

Non credo sia quello il problema. Infatti ho settato MeterN per funzionare con lo script virtmeter.php seguendo le vostre istruzioni e tutto funziona perfettamente.
In seguito ho disabilitato il lancio automatico di MeterN e riavviato la raspy ( per evitare che rimanesse in memoria un processo di pooler485 attivo ).
Ho rinominato e spostato il file virtmeter.php e copiato quello nuovo. Controllati i permessi ed eliminato il link simbolico su /usr/bin. Ricreato il nuovo link simbolico , testato che funzionasse e già da li generale un errore. Per curiosità ho riabilitato lancio automatico di MeterN e riavviato la raspy.
Ed ecco presentarsi il problema segnalato precedentemente.
A questo punto ho fermato meter e rimesso il "vecchio" file virtmeter.php ricreando il link simbolico e riavviata la raspy. Tutto ha ripreso a funzionare benissimo. Quindi non è un problema di configurazione, visto che la configurazione la prende dalla dir config di metern.
Potrebbe esserci qualcosa nel nuovo script che genera questo problema solo su alcune configurazioni, visto che da @Flane funziona.

Insisto anche sul fatto che l'autore dovrebbe, secondo me, inserire nello script una sorta di configurazione per i valori precedenti tipo:

Codice: Seleziona tutto

$PrevCountMet3=0
$PrevCountMet4=0
$PrevCountMet5=0

dove lo 0 deve essere sostituito con il valore desiderato al fine di non dover sempre ripartire da 0 ogni volta che si sostituisce un contatore o si fa una nuova installazione del sistema.

[Flane]

Tony il prev counter non serve.
Sul mio sistema in funzione da anni, ho sostituito eflow con virtmeter senza problemi e SENZA inserire alcun prevcounter è partito correttamente dagli ultimi valori loggati.
Ma tra l'altro nemmeno eflow ed eflowlive lo ha .....

Ripeto:
eseguite i vari comandi di virtmeter da terminale, senza inserirli in meterN, e vedete se vi restituisce lo stesso valore che restituisce eflow, oppure riportate eventuali problemi.
Vi dico solo che per test io ho tenuto attivi contemporaneamente eflow e virtmeter (su meter diversi) e fatto un confronto sulle restituzioni per settimane.

Continuare a dire :
.....non funziona, .... è instabile, ...... i valori vanno a zero......

non aiuta ad individuare eventuali problemi ... se ci sono .....

[TonyP62]

Lungi da me voler far polemica. Dico solo che non sono riuscito a far funzionare la nuova versione. La precedente funziona perfettamente ed oramai ha sostituito in toto eflow . Mi riprometto, come suggerisci, di testare il nuovo script manualmente. Interrai basterebbe dare:

Codice: Seleziona tutto

php virtmeter.php 9 0 0 energy F23

per vedere se restituisce il valore corretto. A quel punto se tutti i comandi restituiscono valori corretti, posso pensare alla sostituzione.
Appena ho tempo lo provo e vi faccio sapere.

[TonyP62]

Aggiornamento:
Qualcosa è cambiato nella sintassi dei comandi.
Se dò il comando

Codice: Seleziona tutto

php virtmeter.php 9 0 0 energy F23

mi restituisce il valore corretto, ossia 9(732346*Wh).
Mentre dando il comando

Codice: Seleziona tutto

php virtmeter.php 4 0 0 expenergy 0

restituisce:
PHP Notice: Undefined index: KWHT1 in /var/www/comapps/pool123s.php on line 45
4(3732346*Wh)

Questo accade su entrambe le release. La cosa strana è :

Codice: Seleziona tutto

 php virtmeter.php 5 0 0 selfcenergy 0
PHP Notice:  Undefined index: KWHT1 in /var/www/comapps/pool123s.php on line 45
5(3076916*Wh)

mentre dando

Codice: Seleziona tutto

 php virtmeter.php 5 0 0 selfcenergy F1
5(3076916*Wh)

Come si può notare il valore restituito è identico, ma nel primo comando da quell'errore, nel secondo che usa un parametro che non dovrebbe, non dà errore.

[TonyP62]

Aggiornamento:
Forse ho scoperto il problema.
Nella SolarJessie 2.6a il proprietario della Dir /var/www/comapps era pi , gruppo pi .
Ho dato il comando

Codice: Seleziona tutto

sudo chown -R www-data:www-data /var/www/comapps/

ed il problema sembra magicamente sparito.
Bisogna capire quanto possa incidere però questo nella sicurezza e stabilità del sistema. Per ora lo testo in questa maniera e riprovo la nuova versione dello script che con i comandi manuali sembra funzionare perfettamente.
A breve aggiorno il POST.

Aggiornamento:

Niente da fare. Continua a dare lo stesso problema. Mi arrendo. Continuerò a testare la versione precedente che funziona a meraviglia.

[Flane]

Questi sono tutti i problemini che si incontrano a non usare la SolarJessie .....
ed è anche il motivo per cui avevamo deciso di fare un'immagine preconfigurata.
Ci sono una sacco di passaggi e modifiche per far girare tutto bene.

Vedi che il problema non era virtmeter ma solo di permessi?

Ma tu avevi eseguito i primi comandi indicati da Garluk nel primo post?

Codice: Seleziona tutto

cd /var/www/comapps
chown www-data.www-data virtmeter.php


[ambramia]

Questi sono tutti i problemini che si incontrano a non usare la SolarJessie .....

io sto usando la solajessi 2.6a ed avrei voluto usare lo script "virtmeter.php" di Garluk per sopperire al bug di eflowlive, ma non ha funzionato, il gauge ed i vari meter andavano a zero e non memorizzava i dati nel csv, anche l'altro utente cosimo61 ci ha provato senza riuscirci, però c'è da dire che entrambi abbiamo i primi due meter invertiti, sarà questo il problema?

[TonyP62]

Questi sono tutti i problemini che si incontrano a non usare la SolarJessie .....
ed è anche il motivo per cui avevamo deciso di fare un'immagine preconfigurata.
Ci sono una sacco di passaggi e modifiche per far girare tutto bene.

Vedi che il problema non era virtmeter ma solo di permessi?

Ma tu avevi eseguito i primi comandi indicati da Garluk nel primo post?

Codice: Seleziona tutto

cd /var/www/comapps
chown www-data.www-data virtmeter.php


Forse mi sono espresso male io, allora, perché ho detto di aver effettuato l'installazione su una SolarJessie 2.6a pura con kernel 4.4 e sulla quale i proprietari della comapps erano settati in pi:pi .
Forse mi era sfuggito il post di Garluk dove diceva di cambiare i permessi e proprietari della dir, ma ti posso garantire che anche dopo il cambio, continua a presentare lo stesso problema. La 0.3 funziona perfettamente mentre la 0.4 continua a non volerne sapere su tutte e 3 le Raspy sulla quale la sto provando. Su quella online che puoi vedere uso la 0.3 con kernel 4.9 . Ho quindi sostituito eflow . Ho notato però che uso cpu e ram sono superiori rispetto ad eflow . Consiglio a tutti di non usare lo script di reqsdm per Volt,etc con virtmeter perché porta ad un Load di 1 1,1 1,3 circa nelle 24 ore.
Senza il Reqsdm ma con Virtmeter si hanno carichi di 0,8 0,8 0,8 su PI2 con kernel 4.9 , mentre si scende a carichi di 0,5 0,7 0,5 con Eflow senza Reqsdm ed a carichi di 0,6 0,6 0,7 con Eflow + Reqsdm. Il tutto testato per 24 ore su ogni Raspy con SolarJessie 2.6a

Edit:
Ho riletto per bene la Guida di Garluk dove dice di modificare i permessi del file virtmeter.php ma non dice che bisogna cambiare anche i permessi degli altri file. L'errore che veniva generato era proprio un problema di permessi sui file della dir /var/www/comapps che la SolarJessie 2.6a ha di default in pi.pi . Virtmeter restituiva un errore di autorizzazione. Ecco perché ho provato a cambiare i permessi di tutti i file delle comapps.

In questi giorni la voglio testare anche su una PI3 sulla quale ho installato la Raspbian Stretch + 123Solar e MeterN puri con le comapps prelevate dal sito di Jean-Marc e vediamo come si comporta.

OT:
Chiedo una cortesia a tutti i partecipanti del forum. Potete inserire in firma il link delle vostre Raspberry ? Così possiamo valutare un po' tutti il funzionamento delle vostre installazioni ed i vostri RpiMonitor.