Re: [vz-users] EasyMeter Q3BA1122/vzlogger - funktioniert

2017-04-08 Diskussionsfäden application MGR 
Hallo Frank, Malte, Udo und alle anderen,

hatte erst jetzt wieder Zeit, mal in den Keller zu gehen und bei laufendem 
vzlogger mit verbosity 15 an der Position der Lesekopfes zu spielen.
Das war’s: ein Hauch von einer Positionsveränderung und ratteratterratter….

Für Interessierte: Dieser Zähler hat im Gegensatz zum anderen mir bekannten 
digitalen Haushaltszähler einen Summenkanal (1.7.0) für die Momentan-Leistung 
und dazu noch für jede einzelne Phase einen Kanal für die Momentane 
Wirkleistung (21.7.0, 41.7.0, 61.7.0) MIT VORZEICHEN.

[Apr 06 20:20:51][mtr0] Reading: id=1-0:1.7.0*255/ObisItentifier:1-0:1.7.0*255 
value=1028.71 ts=1491502851253
[Apr 06 20:20:51][mtr0] Reading: 
id=1-0:21.7.0*255/ObisItentifier:1-0:21.7.0*255 value=508.94 ts=1491502851253
[Apr 06 20:20:51][mtr0] Reading: 
id=1-0:41.7.0*255/ObisItentifier:1-0:41.7.0*255 value=174.25 ts=1491502851253
[Apr 06 20:20:51][mtr0] Reading: 
id=1-0:61.7.0*255/ObisItentifier:1-0:61.7.0*255 value=345.52 ts=1491502851253

Vielen Dank für Eure Unterstützung!
Armin

> Am 23.03.2017 um 20:27 schrieb Frank Richter :
> 
> Schade...
> 
> Aber nochmals die Frage: hast du mal die Ausrichtung des Lesekopfs ein 
> bisschen verändert? Vielleicht sind Übertragungsfehler dabei, die die 
> Checksumme ungültig machen?
> 
> Grüße
> Frank
> 
> Am 23.03.2017 20:20 schrieb "applicationMGR ecoCuyo" 
> >:
> Hallo Frank et alii,
> 
> am vzlogger lag's nicht:
> 
> $ sudo ~/code/vzlogger/src/vzlogger -c /etc/vzlogger.conf.udo
> [Mar 23 20:11:24][main] vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4 
> from Mon, 6 Mar 2017 19:03:42 +0100 started.
> [Mar 23 20:11:24][mtr0] Creating new meter with protocol sml.
> [Mar 23 20:11:24][mtr0] Meter configured, enabled.
> [Mar 23 20:11:24]   New meter initialized (protocol=sml)
> [Mar 23 20:11:24]   Have 1 meters.
> [Mar 23 20:11:24][main] log level is 15
> [Mar 23 20:11:24][main] daemon=0, local=0
> [Mar 23 20:11:24]   Process not  daemonized...
> [Mar 23 20:11:24]   Opened logfile /tmp/vzlogger.log
> [Mar 23 20:11:24][push] No pushDataServer defined.
> [Mar 23 20:11:24][] ===> Start meters
> [Mar 23 20:11:24][mtr0] Meter connection established
> [Mar 23 20:11:24][mtr0] Meter thread started
> [Mar 23 20:11:24][mtr0] Meter is opened. Starting channels.
> [Mar 23 20:11:24][] Startup done.
> [Mar 23 20:11:24][mtr0] Number of readers: 32
> [Mar 23 20:11:24][mtr0] Config.daemon: 0
> [Mar 23 20:11:24][mtr0] Config.local: 0
> ^C[Mar 23 20:11:57]   MapContainer::quit terminating on signal 2.
> [Mar 23 20:11:57]   Closing connections to terminate
> [Mar 23 20:11:57][main] MeterMap::cancel entered...
> [Mar 23 20:11:57][main] MeterMap::cancel wait for readingthread
> [Mar 23 20:11:57][main] MeterMap::cancel wait for meter::close
> [Mar 23 20:11:57][main] MeterMap::cancel finished.
> [Mar 23 20:11:57][main] MapContainer::quit finished.
> [Mar 23 20:11:57][] Server stopped.
> [Mar 23 20:11:57][] Trying to delete curlSessionProvider...
> [Mar 23 20:11:57][] deleted curlSessionProvider
> 
> 
> vzlogger.log:
> 
> [Mar 23 20:10:58]   Opened logfile /tmp/vzlogger.log
> [Mar 23 20:10:58][push] No pushDataServer defined.
> [Mar 23 20:10:58][] ===> Start meters
> [Mar 23 20:10:58][mtr0] Meter connection established
> [Mar 23 20:10:58][mtr0] Meter thread started
> [Mar 23 20:10:58][mtr0] Meter is opened. Starting channels.
> [Mar 23 20:10:58][] Startup done.
> [Mar 23 20:10:58][mtr0] Number of readers: 32
> [Mar 23 20:10:58][mtr0] Config.daemon: 0
> [Mar 23 20:10:58][mtr0] Config.local: 0
> [Mar 23 20:11:01]   terminating on signal 2.
> [Mar 23 20:11:01]   Closing connections to terminate
> [Mar 23 20:11:01][] Server stopped.
> [Mar 23 20:11:01][] Trying to delete curlSessionProvider...
> [Mar 23 20:11:01][] deleted curlSessionProvider
> [Mar 23 20:11:24][main] vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4 
> from Mon, 6 Mar 2017 19:03:42 +0100 started.
> [Mar 23 20:11:24][mtr0] Creating new meter with protocol sml.
> [Mar 23 20:11:24][mtr0] Meter configured, enabled.
> [Mar 23 20:11:24]   New meter initialized (protocol=sml)
> [Mar 23 20:11:24]   Have 1 meters.
> [Mar 23 20:11:24][main] log level is 15
> [Mar 23 20:11:24][main] daemon=0, local=0
> [Mar 23 20:11:24]   Process not  daemonized...
> [Mar 23 20:11:24]   Opened logfile /tmp/vzlogger.log
> [Mar 23 20:11:24][push] No pushDataServer defined.
> [Mar 23 20:11:24][] ===> Start meters
> [Mar 23 20:11:24][mtr0] Meter connection established
> [Mar 23 20:11:24][mtr0] Meter thread started
> [Mar 23 20:11:24][mtr0] Meter is opened. Starting channels.
> [Mar 23 20:11:24][] Startup done.
> [Mar 23 20:11:24][mtr0] Number of readers: 32
> [Mar 23 20:11:24][mtr0] Config.daemon: 0
> [Mar 23 20:11:24][mtr0] Config.local: 0
> [Mar 23 20:11:57]   MapContainer::quit terminating on signal 2.
> [Mar 23 20:11:57]

Re: [vz-users] Middleware-Abfrage 4-Wochen Intervall

2016-01-25 Diskussionsfäden application MGR 
   "types": [],
"executionMS": 0.009148120880127
},
{
"sql": "SELECT 
UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) \/ 1000, \"%Y-%m-%d\"), 
INTERVAL 1 day)) * 1000 FROM aggregate WHERE channel_id=? AND type=? AND 
timestamp= ? AND timestamp < ? OR timestamp >= ? AND timestamp <= ?) UNION 
SELECT DISTINCT YEAR(FROM_UNIXTIME(timestamp\/1000)), 
YEARWEEK(FROM_UNIXTIME(timestamp\/1000)) FROM aggregate WHERE channel_id = ? 
AND type = ? AND timestamp >= ? AND timestamp < ?) AS agg",
"params": [
3,
145056597,
"145056600",
"145298520",
145298523,
3,
3,
"145056600",
"145298520"
],
"types": [],
"executionMS": 0.0064718723297119
},
{
"sql": "SELECT MAX(timestamp) AS 
timestamp, MAX(value) AS value, SUM(count) AS count FROM (SELECT timestamp, 
value, 1 AS count FROM data WHERE channel_id = ? AND ( timestamp >= ? AND 
timestamp < ? OR timestamp >= ? AND timestamp <= ?) UNION SELECT timestamp, 
value, count FROM aggregate WHERE channel_id = ? AND type = ? AND timestamp >= 
? AND timestamp < ?) AS agg GROUP BY YEAR(FROM_UNIXTIME(timestamp\/1000)), 
YEARWEEK(FROM_UNIXTIME(timestamp\/1000)) ORDER BY timestamp ASC",
"params": [
3,
145056597,
"145056600",
"145298520",
145298523,
3,
        3,
"145056600",
"145298520"
],
"types": [],
"executionMS": 0.018276929855347
}
]
}
}
}



Viele Grüße
Armin


> Am 23.01.2016 um 19:54 schrieb Andreas Götz <cpui...@gmail.com>:
> 
> Mhm. Häng mal bitte ein =1 an und poste das ergebnis. Würde gerne das 
> sql sehen...
> 
> Viele Grüße, Andreas 
> 
> Am 23.01.2016 um 19:26 schrieb application MGR <application...@ecocuyo.de 
> <mailto:application...@ecocuyo.de>>:
> 
>> Hallo Andreas,
>> 
>> hat leider nicht den erwünschten Effekt gebracht. Dieselbe Abfrage 
>> 
>> http:///middleware.php/data.json?from=145056600=145298520=week&%20uuid%5B%5D=----695ed220d33d
>> 
>> wirft nun folgendes aus:
>> 
>> {"version":"0.3","data”:[
>>  {
>>  "tuples”:[
>>          [1451170785000,136.755,39831],  ->  26.12.15 
>> 23:59:45
>>  [1451602785000,188.663,28347],  ->  31.12.15 
>> 23:59:45
>>  [1451775585000,42.931,11520],   ->  02.01.16 
>> 23:59:45
>>  [1452380385000,101.307,39865],  ->  09.01.16 
>> 23:59:45
>>  [1452985185000,110.44,39772],   ->  16.01.16 
>> 23:59:45
>>  [145298523,0,3] ->  
>> 17.01.16 00:00:30
>>  ],
>>  …
>>  }
>> ]}
>> 
>> Hab noch nicht recherchiert, was sonst geändert werden muss …
>> 
>> Schönes Wochenende
>> Armin
>> 
>> 
>>> Am 21.01.2016 um 19:29 schrieb Andreas Goetz <cpui...@gmail.com 
>>> <mailto:cpui...@gmail.com>>:
>>> 
>>> Keine Ahnung funktionierts denn?
>>> 
>>> 2016

[vz-users] Middleware-Abfrage 4-Wochen Intervall

2016-01-21 Diskussionsfäden application MGR 
Hallo @

mit folgender Abfrage mit Startdatum 20.12.15 00:00:00 und Enddatum 17.01.16 
00:00:00:

http:///middleware.php/data.json?from=145056600=145298520=week&%20uuid%5B%5D=----695ed220d33d

erhalte ich folgende Antwort von der Middleware:

{"version":"0.3","data”:[
{
"tuples”:[
[1451257185000,159.436,39831],  ->  
27.12.15 23:59:45
[1451602785000,155.903,22587],  ->  
31.12.15 23:59:45   
[1451861985000,50.125,17280],   ->  
03.01.16 23:59:45
[1452466785000,138.161,39864],  ->  
10.01.16 23:59:45
[145298523,75.092,34016]->  
17.01.16 00:00:30
],
"uuid":"----695ed220d33d”,
"from":1450652385000,
"to":145298523,
"min":[1451861985000,50.125],
"max":[1451257185000,159.43571428571],
"average":122.507,
"consumption":79386.1,
"rows”:6
}
]}

Wer kann mir sagen, warum der 31.12. hier als tuple mit-ausgegeben wird? Hat 
der letzte Tag des Jahres eine besondere Bedeutung für die group=week?

Viele Grüße
Armin

Re: [vz-users] Middleware-Abfrage 4-Wochen Intervall

2016-01-21 Diskussionsfäden application MGR 
Hallo Andreas,

na mir wäre es natürlich recht, nur will ich nichts verschlimmbessern, falls 
jemand das Feature genau so braucht.

Gibt es nachteilige Nebenwirkungen, die bedacht werden müssen?

Best Grüße
Armin

> Am 21.01.2016 um 13:14 schrieb Andreas Goetz <cpui...@gmail.com>:
> 
> 2016-01-21 12:29 GMT+01:00 application MGR <application...@ecocuyo.de 
> <mailto:application...@ecocuyo.de>>:
> Hallo @
> 
> mit folgender Abfrage mit Startdatum 20.12.15 00:00:00 und Enddatum 17.01.16 
> 00:00:00:
> 
> http:///middleware.php/data.json?from=145056600=145298520=week&%20uuid%5B%5D=----695ed220d33d
> 
> erhalte ich folgende Antwort von der Middleware:
> 
> {"version":"0.3","data”:[
>   {
>   "tuples”:[
>   [1451257185000,159.436,39831],  ->  
> 27.12.15 23:59:45
>   [1451602785000,155.903,22587],  ->  
> 31.12.15 23:59:45   
>   [1451861985000,50.125,17280],   ->  
> 03.01.16 23:59:45
>   [1452466785000,138.161,39864],  ->  
> 10.01.16 23:59:45
>   [145298523,75.092,34016]->  
> 17.01.16 00:00:30
>   ],
> ...
>   }
> ]}
> 
> Wer kann mir sagen, warum der 31.12. hier als tuple mit-ausgegeben wird? Hat 
> der letzte Tag des Jahres eine besondere Bedeutung für die group=week?
> 
> Sehr gute Frage. Die Antwort liegt hier: 
> https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Interpreter/SQL/MySQLOptimizer.php#L63
>  
> <https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Interpreter/SQL/MySQLOptimizer.php#L63>
> 
> Mittlerweile (?) gibts bei MySQL eine Funktion YEARWEEK() die das gewünschte 
> Ergebnis bringen sollte.
> 
> 
> Viele Grüße
> Armin
> 
> Wollen wir das ändern?
> 
> Viele Grüße,
> Andreas

Re: [vz-users] Einträge in die vzlogger.log unterdrücken?

2016-01-15 Diskussionsfäden application MGR 
Hallo Andreas,

Fehler sind das nicht unbedingt, vielmehr sind das weitere Register für IDs, 
Tamper…
Beispielsweise wäre C.60.9 = Fraud flag, nur das kommt bei dem Zähler gar nicht 
vor.

Jedoch wirft der Zähler für C.60.5.2 folgendes aus (Hardware ID 
(=Revision.Produktzustand)):

C.60.5.2(07.000   0998 B7FD)(12-11-16 06:32)Line: 'C.60.5.2(07.000  
 0998 B7FD)(12-11-16 06:32)

Siehe 
http://www.ooe-ausfuehrungsbestimmungen.at/assets/download/AMIS-Zaehler.pdf

Für die Energiezählung, Leistung-, Spannungs-, Strom- und Phasenmessung sind 
diese Codes m.E. unerheblich.

Hilft das?

Beste Grüße
Armin

> Am 15.01.2016 um 17:38 schrieb Andreas Goetz <cpui...@gmail.com>:
> 
> Bei log_level=0 werden nur Fehler geloggt- das sind Fehler. Mich würde eher 
> interessieren ob wir in der Lage sein sollten diesen Obis Code nicht als 
> Fehler zu interpretieren?
> 
> Viele Grüße,
> Andreas
> 
> 
> On Fri, Jan 15, 2016 at 10:45 AM, application MGR <application...@ecocuyo.de 
> <mailto:application...@ecocuyo.de>> wrote:
> Hallo zusammen,
> 
> eine Frage zu Log-Einträgen bei einer Konfiguration mit einem Siemens TD3511 
> D0-Zähler:
> 
> Einstellung in der vzlogger.conf_
> 
> "verbosity" : 0,  /* 0 = log_error or log-warning, 5 = 
> log_info, 10 = log-debug, 15 = log_finest */
>   "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */
> 
> 
> Weil der Zähler an vzlogger unbekannte OBIS-Codes auswirft, schreibt er 
> fortlaufend folgende Meldungen in die vzlogger.log-Datei, die dadurch massiv 
> anschwillt:
> 
> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.1)
> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.2)
> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.1)
> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.2)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.3)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.4)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.5)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.6)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.1)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.2)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.3)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.4)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.5)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.6)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.1)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.2)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.3)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.4)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.5)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.6)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.7)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.11)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.13)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.14)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.15)
> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.16)
> 
> Wie kann man das unterbinden ohne das Logging komplett abzuschalten? 
> 
> Beste Grüße
> Armin
>

[vz-users] Einträge in die vzlogger.log unterdrücken?

2016-01-15 Diskussionsfäden application MGR 
Hallo zusammen,

eine Frage zu Log-Einträgen bei einer Konfiguration mit einem Siemens TD3511 
D0-Zähler:

Einstellung in der vzlogger.conf_

"verbosity" : 0,  /* 0 = log_error or log-warning, 5 = 
log_info, 10 = log-debug, 15 = log_finest */
  "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */


Weil der Zähler an vzlogger unbekannte OBIS-Codes auswirft, schreibt er 
fortlaufend folgende Meldungen in die vzlogger.log-Datei, die dadurch massiv 
anschwillt:

[Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.1)
[Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.2)
[Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.1)
[Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.2)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.3)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.4)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.5)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.6)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.1)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.2)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.3)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.4)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.5)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.6)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.1)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.2)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.3)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.4)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.5)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.6)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.7)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.11)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.13)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.14)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.15)
[Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.16)

Wie kann man das unterbinden ohne das Logging komplett abzuschalten? 

Beste Grüße
Armin

Re: [vz-users] /var/www/volkszaehler.org/misc/tools/aggregate.php

2016-01-12 Diskussionsfäden application MGR 
Danke!
Armin

> Am 12.01.2016 um 12:16 schrieb Andreas Goetz <cpui...@gmail.com>:
> 
> Hi
> 
> On Tue, Jan 12, 2016 at 11:37 AM, application MGR <application...@ecocuyo.de 
> <mailto:application...@ecocuyo.de>> wrote:
> Hallo zusammen,
> 
> wer kann mir sagen, wie ich diese Fehlermeldung zu verstehen habe und wie ich 
> diese ggf. abstellen kann:
> 
> $ php /var/www/volkszaehler.org/misc/tools/aggregate.php 
> <http://volkszaehler.org/misc/tools/aggregate.php> run -m delta -l day
> Performing 'delta' aggregation on 'day' level.
> 
>   [Doctrine\DBAL\Exception\ConnectionException]   
> 
>   An exception occured in driver: SQLSTATE[28000] [1045] Access denied 
> for user 'root'@'localhost' (using password: YES)  
> 
>   [Doctrine\DBAL\Driver\PDOException] 
> 
>   SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
> password: YES)  
> 
>   [PDOException]  
> 
>   SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
> password: YES)  
> 
> run [-l|--level="..."] [-m|--mode="..."] [-p|--period="..."] [uuid1] ... 
> [uuidN]
> 
> Das ist doch völlig eindeutig- falsches Passwort. Also 
> etc/volkszaehler.conf.php anpassen.
> 
> Viele Grüße,
> Andreas
> 
>  
> 
> 
> 
> 
> Hinweise:
> Das root-Passwort der DB wurde geändert - muss dies in irgend einer .my.cnf 
> eingetragen werden?
> Meldung/Fehler auch bei vorangestelltem sudo
> vzlogger Version 0.4.7
> based on git version: heads/master-0-g64c5ec088a
> last commit date: Tue, 10 Nov 2015 08:14:41 +0100
> 
> Beste Grüße
> Armin

[vz-users] /var/www/volkszaehler.org/misc/tools/aggregate.php

2016-01-12 Diskussionsfäden application MGR 
Hallo zusammen,

wer kann mir sagen, wie ich diese Fehlermeldung zu verstehen habe und wie ich 
diese ggf. abstellen kann:

$ php /var/www/volkszaehler.org/misc/tools/aggregate.php run -m delta -l day
Performing 'delta' aggregation on 'day' level.

[Doctrine\DBAL\Exception\ConnectionException]   

An exception occured in driver: SQLSTATE[28000] [1045] Access denied 
for user 'root'@'localhost' (using password: YES)  

[Doctrine\DBAL\Driver\PDOException] 

SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
password: YES)  

[PDOException]  

SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
password: YES)  

run [-l|--level="..."] [-m|--mode="..."] [-p|--period="..."] [uuid1] ... [uuidN]



Hinweise:
Das root-Passwort der DB wurde geändert - muss dies in irgend einer .my.cnf 
eingetragen werden?
Meldung/Fehler auch bei vorangestelltem sudo
vzlogger Version 0.4.7
based on git version: heads/master-0-g64c5ec088a
last commit date: Tue, 10 Nov 2015 08:14:41 +0100

Beste Grüße
Armin

[vz-users] Fwd: /var/www/volkszaehler.org/misc/tools/aggregate.php

2016-01-12 Diskussionsfäden application MGR 
Nachrichtlich:

Die Installation wurde nach einem Crash mit dem letzten vz-Image wieder 
hergestellt, die DB der alten Installation wurde per restore wiederhergestellt.

Muss die “alte” DB hinsichtlich security keys irgendwie neu initialisiert 
werden?

Viele Grüße
Armin


> Anfang der weitergeleiteten Nachricht:
> 
> Von: application MGR <application...@ecocuyo.de>
> Betreff: /var/www/volkszaehler.org/misc/tools/aggregate.php
> Datum: 12. Januar 2016 11:37:39 MEZ
> An: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org>
> 
> Hallo zusammen,
> 
> wer kann mir sagen, wie ich diese Fehlermeldung zu verstehen habe und wie ich 
> diese ggf. abstellen kann:
> 
> $ php /var/www/volkszaehler.org/misc/tools/aggregate.php 
> <http://volkszaehler.org/misc/tools/aggregate.php> run -m delta -l day
> Performing 'delta' aggregation on 'day' level.
> 
>   [Doctrine\DBAL\Exception\ConnectionException]   
> 
>   An exception occured in driver: SQLSTATE[28000] [1045] Access denied 
> for user 'root'@'localhost' (using password: YES)  
> 
>   [Doctrine\DBAL\Driver\PDOException] 
> 
>   SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
> password: YES)  
> 
>   [PDOException]  
> 
>   SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using 
> password: YES)  
> 
> run [-l|--level="..."] [-m|--mode="..."] [-p|--period="..."] [uuid1] ... 
> [uuidN]
> 
> 
> 
> Hinweise:
> Das root-Passwort der DB wurde geändert - muss dies in irgend einer .my.cnf 
> eingetragen werden?
> Meldung/Fehler auch bei vorangestelltem sudo
> vzlogger Version 0.4.7
> based on git version: heads/master-0-g64c5ec088a
> last commit date: Tue, 10 Nov 2015 08:14:41 +0100
> 
> Beste Grüße
> Armin

Re: [vz-users] Siemens TD-3511 - OMS, D0, SML?

2015-12-07 Diskussionsfäden application MGR 
Hallo Udo,

vielen Dank - kaum macht man’s richtig, schon funktionert's :-)

Beste Grüße
Armin

> Am 06.12.2015 um 22:10 schrieb Udo1 <u...@gmx.net>:
> 
> Am 06.12.2015 um 21:52 schrieb application MGR:
>> die volle Ausgabe sieht so aus:
> ok, sehr lang :)
> 
> die vzlogger.conf sollte dann so aussehen: (nur der wichtige Teil)
> 
>  "meters" : [{
>"enabled" : true,
>"protocol" : "d0",
>"device" : "/dev/usb-ir-lesekopf0",
>"parity": "7e1",
>"baudrate": 300,
>"pullseq": "2f3f210d0a",
>"ackseq": "063035300d0a",
>"read_timeout": 10,
>"baudrate_change_delay": 400,
>"baudrate_read": 9600,
>"aggtime" : 30,
>"aggfixedinterval" : true,
>"channels" :[{
>  "uuid" : “----",
>"middleware" : "http://localhost/middleware.php;,
>"identifier" : "1.8.0",
>"aggmode" : "max"
>}, {
>"uuid" : "----",
>"middleware" : "http://localhost/middleware.php;,
>"identifier" : "1.8.1",
>"aggmode" : "max"
>}, {
>"uuid" : "----",
>"middleware" : "http://localhost/middleware.php;,
>"identifier" : "1.8.2",
>"aggmode" : "max"
>}, {
>"uuid" : "----",
>"middleware" : "http://localhost/middleware.php;,
>"identifier" : "2.8.0",
>"aggmode" : "max"
>}, {
>"uuid" : "---
> 
> Gruß
> Udo

[vz-users] Siemens TD-3511 - OMS, D0, SML?

2015-12-06 Diskussionsfäden application MGR 
Hi Christian, hallo Freunde,

den Siemens Zähler habe ich jetzt am Start und mit Deinem Script kann ich - 
nachdem meine Channels & Devices eingetragen sind -  alle Werte lesen und an 
die Middleware übertragen.

Output am Terminal z.B.:

setze Schnittstelle auf 300 bps
Ergebnis vom Setzen der seriellen Schnittstelle per stty:
Array
(
)
Port öffnen OK
Request senden ...Request OK.
Lese eine Zeile
/SATxC01251xx
gelesen
sicherheitshalber etwas warten
bps-Rate-Request senden ...BPS Request OK.
warte bis Zeichen ausgegeben wurden...
schließe Port
setze Schnittstelle auf 9600 bps
Ergebnis vom Setzen der seriellen Schnittstelle per stty:
Array
(
)
öffne Port
Port 9600 OK
lese Rest ein
09-01 00:00)
Line: '09-01 00:00)
'
0.1.2*16(15-08-01 00:00)
Line: '0.1.2*16(15-08-01 00:00)
'
0.1.2*15(15-07-01 00:00)
Line: '0.1.2*15(15-07-01 00:00)
'
0.1.2*14(15-06-01 00:00)
Line: '0.1.2*14(15-06-01 00:00)
'
0.1.2*13(15-05-01 00:00)
Line: '0.1.2*13(15-05-01 00:00)
‘
… usw.

Leider gelingt mir dies mit dem vzlogger nicht.  In Deinem php-Script 
überschreibst Du zur Baugrate-Umstellung nachdem das Telegramm wie in 
vzlogger.conf aussieht (z.B. "ackseq": "063035310d0a") zusätzlich  x06050 auf 
$out:

echo "bps-Rate-Request senden ...";
$out = "\x06\x30\x35\x31\x0D\x0A";
$out = "\x06050\r\n";

Welchen Hintergrund hat das und wie sähe das Pendant in 
vzlogger.conf-Nomenklatur aus? Da ich die Werte nach Möglichkeit in kürzeren 
Intervallen als eine Minute lesen möchte, brauche ich vzlogger. Installiert ist 
vzlogger -V:
0.4.7
based on git version: heads/master-0-g64c5ec088a
last commit date: Tue, 10 Nov 2015 08:14:41 +0100

Mit der vzlogger.conf:

/**
* vzlogger configuration
*
* use proper encoded JSON with javascript comments
*
* take a look at the wiki for detailed information:
* http://wiki.volkszaehler.org/software/controller/vzlogger#configuration
*/
{
  "retry" : 30, /* how long to sleep between failed 
requests, in seconds */
  "daemon": true,   /* run as server */
  "verbosity" : 15, /* between 0 and 15 */
  "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */

  "local" : {
"enabled" : true,   /* should we start the local HTTPd for serving live 
readings? */
"port" : 8080,  /* the TCP port for the local HTTPd */
"index" : true, /* should we provide a index listing of available 
channels if no UUID was requested? */
"timeout" : 30, /* timeout for long polling comet requests, 0 disables 
comet, in seconds */
"buffer" : 600  /* how long to buffer readings for the local interface, 
in seconds */
  },

  "meters" : [{
"enabled" : true,
//"protocol" : "sml",
"protocol" : "d0",
//  "protocol": "oms",
"device" : "/dev/usb-ir-lesekopf0",

"parity": "7e1",
"pullseq": "2f3f210d0a",
"ackseq": "auto",   
//"ackseq": "063035300d0a",
"read_timeout": 10,
"baudrate_change_delay": 400,   
"baudrate_read": 9600,  
"aggtime" : 30,
"aggfixedinterval" : true,
"channels" :[{
"uuid" : “----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "1.8.0",
"aggmode" : "AVG"
}, {
"uuid" : "----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "1.8.1",
"aggmode" : "AVG"
}, {
"uuid" : "----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "1.8.2",
"aggmode" : "AVG"
}, {
"uuid" : "----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "2.8.0",
"aggmode" : "AVG"
}, {
"uuid" : "----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "1.7.0",
"aggmode" : "NONE"
}, {
"uuid" : "----",
"middleware" : "http://localhost/middleware.php;,
"identifier" : "2.7.0",
"aggmode" : "NONE"
}]
 }]
}


kommt folgendes Ergebnis heraus:

$ tail -f /var/log/vzlogger.log 
[Dec 06 18:12:13][chn3] Start logging thread for volkszaehler-api. Running as 
daemon: yes
[Dec 06 18:12:13][chn3] Using default volkszaehler api.
[Dec 06 18:12:13][chn5] Start logging thread for volkszaehler-api. Running as 
daemon: yes
[Dec 06 18:12:13][chn5] Using default volkszaehler api.
[Dec 06 18:12:13][chn4] Start logging thread for volkszaehler-api. Running as 
daemon: yes
[Dec 06 18:12:13][chn4]