Re: [vz-users] Wie Anzahl der Brennerstarts ermitteln?

[Andreas Goetz]

Hi,

> On 8. Nov 2019, at 17:50, r...@nord-com.net wrote:
> 
> Hallo Frank,
>  
> ...
>  
> Wenn ich mir die mitgeschickte Grafik so ansehe, werden unter HcStarts 
> wirklich die Stunden ausgewertet, oder ist auch hier die Skala irreführend?

Starts werden nicht in Stunden ausgewertet- wie gesagt gibts hier ein Problem 
mit der Einheit.
 
> So wie ich es jetzt habe (Bild von gestern: https://ibb.co/7nxns6S 
> ) habe ich ja jetzt einen Kanal welcher die gesamte 
> Brennerlaufzeit misst (entsprechend HcHours in Deinem Bild?), sowie einen, 
> der die Anzahl der Starts hochzählt (entsprechend HcStarts?).

Das kannst Du so machen. HcHours könntest Du sogar bekommen, wenn Du einfach 
einen “Sensor” Kanal analog Leistung anlegst und- wenn “on"- eine 1 schreibst, 
sonst 0. 1 integriert über Stunde ist einheitenlos auch eine (Brenner)Stunde.

> Viele Grüsse,
> Alex

Viele Grüße, Andreas

PS.: Dein Quoting (oder Dein Emailclient) ist kaputt ;)

>  
> From: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] On Behalf Of Frank 
> Richter
> Sent: Thursday, November 07, 2019 9:57 PM
> To: volkszaehler.org - users
> Subject: Re: [vz-users] Wie Anzahl der Brennerstarts ermitteln?
>  
> Am Do., 7. Nov. 2019 um 14:43 Uhr schrieb Andreas Goetz  >:
>>> Idealerweise bräuchten wir dafür noch einen Kanaltyp "Zähler" mit Einheit 
>>> 1/h, damit als Zeitintegral eine dimensionslose Anzahl rauskommt.
>>  
>> Guter Punkt! Wie haben hinsichtlich Einheit “anpassbare” Sensoren und 
>> Verbrauchssensoren, wir haben aber keinen (Verbrauchs)Zähler der 
>> konfigurierbar wäre.
>>  
>> Wer möchte einen PR aufmachen?
>  
> Also zwei neue Typen mit variabler Einheit und Interpretern für Impulse und 
> Zählerstände? IMHO machen beide nur mit  "hasConsumption": true Sinn, oder?
>  
> Viele Grüße
> Frank

Re: [vz-users] Wie Anzahl der Brennerstarts ermitteln?

[rgb]

Hallo Frank,

 

Lass mich doch wissen, ob ich das so richtig verstehe: 

 

Also zwei neue Typen mit variabler Einheit

 

Variable Einheit heisst man kann die Einheit beim Anlegen eines Kanales frei 
definieren, oder auch weglassen so dass nur die Zahl stehen bleibt? Also z.b. 
anstelle von „kW(h)“ „Starts“ respektive Starts/Stunde oder eben auch keine 
Einheit?

 

und Interpretern für Impulse und Zählerstände

 

Bezogen auf die Brennerstarts: Bei einer Heizung welche die Gesamtzahl ausgibt 
(wie die Vaillant von Andreas) wäre es ein Zählerstand, d.h. der VZ berechnet 
die Differenz. Bei meiner Junkers ein Impulszähler, d.h. der VZ addiert auf. 
Die Darstellung wäre dann dieselbe.

 

Wenn ich mir die mitgeschickte Grafik so ansehe, werden unter HcStarts wirklich 
die Stunden ausgewertet, oder ist auch hier die Skala irreführend?

 

So wie ich es jetzt habe (Bild von gestern: https://ibb.co/7nxns6S) habe ich ja 
jetzt einen Kanal welcher die gesamte Brennerlaufzeit misst (entsprechend 
HcHours in Deinem Bild?), sowie einen, der die Anzahl der Starts hochzählt 
(entsprechend HcStarts?).

 

beide nur mit  "hasConsumption": true Sinn

 

Dazu kann ich jetzt nichts sagen…

 

Viele Grüsse,

Alex

 

From: volkszaehler-users 
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] On Behalf Of Frank 
Richter
Sent: Thursday, November 07, 2019 9:57 PM
To: volkszaehler.org - users
Subject: Re: [vz-users] Wie Anzahl der Brennerstarts ermitteln?

 

Am Do., 7. Nov. 2019 um 14:43 Uhr schrieb Andreas Goetz :

Idealerweise bräuchten wir dafür noch einen Kanaltyp "Zähler" mit Einheit 1/h, 
damit als Zeitintegral eine dimensionslose Anzahl rauskommt.

 

Guter Punkt! Wie haben hinsichtlich Einheit “anpassbare” Sensoren und 
Verbrauchssensoren, wir haben aber keinen (Verbrauchs)Zähler der konfigurierbar 
wäre.

 

Wer möchte einen PR aufmachen?

 

Also zwei neue Typen mit variabler Einheit und Interpretern für Impulse und 
Zählerstände? IMHO machen beide nur mit  "hasConsumption": true Sinn, oder?

 

Viele Grüße

Frank

Re: [vz-users] Stand InfluxDB

[Sirko]

Hi,

wenn ich einen Nutzer anlege, dann muß ich ja ein Paßwort anlegen.
Also hab ich nochmal folgendes gemacht:

drop user vz

drop database volkszaehler

create database volkszaehler

und dann user und password im config.yaml weggelassen für influxdb.
Das hat ber keine Änderung gebracht. Immernoch der Fehler von unten.
Mach ich was falsch beim Anlegen der DB?

Grüße
Sirko

Am 08.11.2019 um 13:06 schrieb Andreas Goetz:

Ich denke dass das Problem darin besteht, dass User/Passwort momentan gar nicht 
an den InfluxDB Client übergeben werden.

Brauchst Du das- also gehts nicht auch ohne Credentials? Dann müsste ich eine 
kleine Erweiterung bauen.

Viele Grüße,
Andreas



On 8. Nov 2019, at 11:20, Sirko  wrote:

Hi Andreas,

ich hab schonmal rausgefunden, daß ich mit influx statt copy starten muß:

Ich hab user und password hinzugefügt, weil dbcopy meint:
pi@raspberrypi ... $ php /.../andig/dbcopy/dbcopy influx -c
/.../andig/dbcopy/config.influx.yaml


1/26 S0-Zaehler

In Client.php line 196:

*Query has failed: unable to parse authentication credentials*


In ResultSet.php line 49:

   *unable to parse authentication credentials*


influx [-c|--config CONFIG] [-m|--mode MODE] [-d|--delete] [-f|--filter
FILTER] [-b|--batch BATCH]

Re: [vz-users] Influx Performance

[Andreas Goetz]

Ich liebe es… golangci-lint hat sich neue Regeln für die Validierung überlegt 
und failt deshalb. Bin ich selber schuld wenn ich keine spezifische Version 
angebe.

Du kannst das einfach per 

make build

übersetzen und den Linter auslassen. Ansonsten gibts natürlich immer aktuelle 
Docker Images für sowas…

Viele Grüße, 
Andreas


> On 8. Nov 2019, at 12:28, Sirko  wrote:
> 
> Hi,
> 
> ich wollte Gravo mal testen, aber beim make erhalte ich diese Fehler:
> 
> pi@raspberrypi ~/gravo $ make
> rm -rf dist/ cover.out
> golangci-lint run
> grafana/model.go:99:2: return statements should not be cuddled if block
> has more than two lines (wsl)
> return json.Marshal(a)
> ^
> volkszaehler/client.go:51:2: assignments should only be cuddled with
> other assignments (wsl)
> resp.Body = ioutil.NopCloser(bytes.NewBuffer(body))
> ^
> volkszaehler/client.go:53:2: return statements should not be cuddled if
> block has more than two lines (wsl)
> return nil
> ^
> volkszaehler/client.go:63:2: only one cuddle assignment allowed before
> if statement (wsl)
> if err != nil {
> ^
> volkszaehler/client.go:66:2: expressions should not be cuddled with
> blocks (wsl)
> req.Header.Add("Accept", "application/json")
> ^
> volkszaehler/client.go:94:2: expressions should not be cuddled with
> blocks (wsl)
> req.Header.Add("Content-type", "application/json")
> ^
> volkszaehler/client.go:117:2: only one cuddle assignment allowed before
> defer statement (wsl)
> defer func() {
> ^
> volkszaehler/client.go:138:2: only one cuddle assignment allowed before
> if statement (wsl)
> if err != nil {
> ^
> volkszaehler/client.go:141:2: only one cuddle assignment allowed before
> defer statement (wsl)
> defer func() {
> ^
> volkszaehler/client.go:181:2: only one cuddle assignment allowed before
> defer statement (wsl)
> defer func() {
> ^
> server.go:50:3: return statements should not be cuddled if block has
> more than two lines (wsl)
> return
> ^
> server.go:213:2: expressions should not be cuddled with blocks (wsl)
> wg.Wait()
> ^
> server.go:228:2: if statements should only be cuddled with assignments (wsl)
> if target.Data.Options != "" {
> ^
> Makefile:15: recipe for target 'checks' failed
> make: *** [checks] Error 1
> 
> 
> Wie krieg ich das zum Laufen?
> 
> Grüße
> Sirko
> 
> Mein bevorzugter Ansatz für Volkszähler mit Grafana ist derzeit:
>> ...
>> - https://github.com/andig/gravo als Adapter für Volkszähler
>> - https://github.com/simPod/grafana-json-datasource als JSON
>> Datasource für Grafana
>> ...
>> Viele Grüße,
>> Andreas
>> 

Re: [vz-users] Stand InfluxDB

[Andreas Goetz]

Ich denke dass das Problem darin besteht, dass User/Passwort momentan gar nicht 
an den InfluxDB Client übergeben werden.

Brauchst Du das- also gehts nicht auch ohne Credentials? Dann müsste ich eine 
kleine Erweiterung bauen.

Viele Grüße,
Andreas


> On 8. Nov 2019, at 11:20, Sirko  wrote:
> 
> Hi Andreas,
> 
> ich hab schonmal rausgefunden, daß ich mit influx statt copy starten muß:
> 
> Ich hab user und password hinzugefügt, weil dbcopy meint:
> pi@raspberrypi ... $ php /.../andig/dbcopy/dbcopy influx -c
> /.../andig/dbcopy/config.influx.yaml
> 
> 
> 1/26 S0-Zaehler
> 
> In Client.php line 196:
> 
>   Query has failed: unable to parse authentication credentials
> 
> 
> In ResultSet.php line 49:
> 
>   unable to parse authentication credentials
> 
> 
> influx [-c|--config CONFIG] [-m|--mode MODE] [-d|--delete] [-f|--filter
> FILTER] [-b|--batch BATCH]
> 
> hat aber nichts genutzt, die config.influx.yaml:
> 
> # DATABASE DEFINITION
> source:
>   driver: pdo_mysql
>   host: localhost
>   #host: ...
>   user: ...
>   password: demo
>   dbname: volkszaehler
> 
> #target:
> #   driver: influx
> #   host: ...
>   # host: localhost
> #   user: ...
> #  password: ...
> #  dbname: volkszaehler
> #   path: sqlite.db3# path is only used if driver = pdo_sqlite
> 
> # influxdb target database connection
> influx:
>   dsn: influxdb://localhost:8086
>   dbname: volkszaehler
>   measurement: data
>   user: ...
>   password: ...
> 
> # TABLE DEFINITION
> # 
> # tables will be processed in the order they are mentioned:
> #   - foreign keys on target will be dropped
> #   - if a table is not listed here, it will not be touched
> # transfer mode
> #   skip:   table will not be copied
> #   copy:   entire table will be truncated on target
> and copied from source
> #   pk: selective copy by primary key.
> only data not present on target
> #   will be copied from source.
> tables:
>   entities: copy
>   properties: copy
>   entities_in_aggregator: copy
>   data: pk
>   aggregate: skip
> 
> $ influx --version
> InfluxDB shell version: 1.7.9
> 
> Grüße
> Sirko
> 
> Am 08.11.2019 um 10:56 schrieb Andreas Goetz:
>> Lass es uns einfacher machen: wie sieht Deine Config aus und was davon 
>> funktioniert nicht? Welche InfluxDB Version hast Du?
>> 
>> Viele Grüße, Andreas
>> 
>> 
>>> On 8. Nov 2019, at 10:41, Sirko  wrote:
>>> 
>>> Hi,
>>> 
>>> wie muß denn die Konfiguration in der dbcopy config.yaml aussehen, wenn
>>> ich nach influxdb exportieren will?
>>> Ohne target: nur mit influx: geht nicht, da fehlt das Target, mit
>>> target: gibt es wohl keinen passenden influxdb driver bei driver:
>>> 
>>> Macht es einen (Performance-) Unterschied, wenn ich die komplette "data"
>>> Spalte mit "copy" oder mit "pk" exportiere?
>>> 
>>> Grüße
>>> Sirko
>>> 
>>> Am 25.10.2019 um 12:06 schrieb Sirko:
 Hi,
 
 wie ist denn der aktuelle Stand bezüglich Volkszähler und InfluxDB? Gibt
 es Pläne dazu?
 
 Soweit ich gesehen hat, kann vzlogger die Daten schon in eine InfluxDB
 schreiben. Gibt es irgendwelche Einschränkungen?
 Meine eigenen Sensoren, die irgendwo auf ESP266 oder NodeMCUs Daten
 erfassen und an die middleware senden, kann ich wohl recht einfach
 direkt in die InfluxDB loggen lassen, denke ich.
 Aber das Frontend kann sicher nicht mit InfluxDB umgehen? Gibt es schon
 Bsp.-Grafana Dashboards oder Panels?
 Wenn ich das richtig gesehen hab, kann DBCopy Daten von mysql nach
 influxDB kopieren? Oder hab ich das falsch verstanden?
 
 Viele Grüße
 Sirko
 
 
>> 

Re: [vz-users] Influx Performance

[Sirko]

Hi,

ich wollte Gravo mal testen, aber beim make erhalte ich diese Fehler:

pi@raspberrypi ~/gravo $ make
rm -rf dist/ cover.out
golangci-lint run
grafana/model.go:99:2: return statements should not be cuddled if block
has more than two lines (wsl)
    return json.Marshal(a)
    ^
volkszaehler/client.go:51:2: assignments should only be cuddled with
other assignments (wsl)
    resp.Body = ioutil.NopCloser(bytes.NewBuffer(body))
    ^
volkszaehler/client.go:53:2: return statements should not be cuddled if
block has more than two lines (wsl)
    return nil
    ^
volkszaehler/client.go:63:2: only one cuddle assignment allowed before
if statement (wsl)
    if err != nil {
    ^
volkszaehler/client.go:66:2: expressions should not be cuddled with
blocks (wsl)
    req.Header.Add("Accept", "application/json")
    ^
volkszaehler/client.go:94:2: expressions should not be cuddled with
blocks (wsl)
    req.Header.Add("Content-type", "application/json")
    ^
volkszaehler/client.go:117:2: only one cuddle assignment allowed before
defer statement (wsl)
    defer func() {
    ^
volkszaehler/client.go:138:2: only one cuddle assignment allowed before
if statement (wsl)
    if err != nil {
    ^
volkszaehler/client.go:141:2: only one cuddle assignment allowed before
defer statement (wsl)
    defer func() {
    ^
volkszaehler/client.go:181:2: only one cuddle assignment allowed before
defer statement (wsl)
    defer func() {
    ^
server.go:50:3: return statements should not be cuddled if block has
more than two lines (wsl)
    return
    ^
server.go:213:2: expressions should not be cuddled with blocks (wsl)
    wg.Wait()
    ^
server.go:228:2: if statements should only be cuddled with assignments (wsl)
    if target.Data.Options != "" {
    ^
Makefile:15: recipe for target 'checks' failed
make: *** [checks] Error 1


Wie krieg ich das zum Laufen?

Grüße
Sirko

Mein bevorzugter Ansatz für Volkszähler mit Grafana ist derzeit:

...
- https://github.com/andig/gravo als Adapter für Volkszähler
- https://github.com/simPod/grafana-json-datasource als JSON
Datasource für Grafana
...
Viele Grüße,
Andreas

Re: [vz-users] Stand InfluxDB

[Sirko]

Hi Andreas,

ich hab schonmal rausgefunden, daß ich mit influx statt copy starten muß:

Ich hab user und password hinzugefügt, weil dbcopy meint:
pi@raspberrypi ... $ php /.../andig/dbcopy/dbcopy influx -c
/.../andig/dbcopy/config.influx.yaml


1/26 S0-Zaehler

In Client.php line 196:

  Query has failed: unable to parse authentication credentials


In ResultSet.php line 49:

  unable to parse authentication credentials


influx [-c|--config CONFIG] [-m|--mode MODE] [-d|--delete] [-f|--filter
FILTER] [-b|--batch BATCH]

hat aber nichts genutzt, die config.influx.yaml:

# DATABASE DEFINITION
source:
  driver: pdo_mysql
  host: localhost
  #host: ...
  user: ...
  password: demo
  dbname: volkszaehler

#target:
#   driver: influx
#   host: ...
  # host: localhost
#   user: ...
#  password: ...
#  dbname: volkszaehler
#   path: sqlite.db3    # path is only used if driver = pdo_sqlite

# influxdb target database connection
influx:
  dsn: influxdb://localhost:8086
  dbname: volkszaehler
  measurement: data
  user: ...
  password: ...

# TABLE DEFINITION
# 
# tables will be processed in the order they are mentioned:
#   - foreign keys on target will be dropped
#   - if a table is not listed here, it will not be touched
# transfer mode
#   skip:   table will not be copied
#   copy:   entire table will be truncated on target
and copied from source
#   pk: selective copy by primary key.
only data not present on target
#   will be copied from source.
tables:
  entities: copy
  properties: copy
  entities_in_aggregator: copy
  data: pk
  aggregate: skip

$ influx --version
InfluxDB shell version: 1.7.9

Grüße
Sirko

Am 08.11.2019 um 10:56 schrieb Andreas Goetz:

Lass es uns einfacher machen: wie sieht Deine Config aus und was davon 
funktioniert nicht? Welche InfluxDB Version hast Du?

Viele Grüße, Andreas



On 8. Nov 2019, at 10:41, Sirko  wrote:

Hi,

wie muß denn die Konfiguration in der dbcopy config.yaml aussehen, wenn
ich nach influxdb exportieren will?
Ohne target: nur mit influx: geht nicht, da fehlt das Target, mit
target: gibt es wohl keinen passenden influxdb driver bei driver:

Macht es einen (Performance-) Unterschied, wenn ich die komplette "data"
Spalte mit "copy" oder mit "pk" exportiere?

Grüße
Sirko

Am 25.10.2019 um 12:06 schrieb Sirko:

Hi,

wie ist denn der aktuelle Stand bezüglich Volkszähler und InfluxDB? Gibt
es Pläne dazu?

Soweit ich gesehen hat, kann vzlogger die Daten schon in eine InfluxDB
schreiben. Gibt es irgendwelche Einschränkungen?
Meine eigenen Sensoren, die irgendwo auf ESP266 oder NodeMCUs Daten
erfassen und an die middleware senden, kann ich wohl recht einfach
direkt in die InfluxDB loggen lassen, denke ich.
Aber das Frontend kann sicher nicht mit InfluxDB umgehen? Gibt es schon
Bsp.-Grafana Dashboards oder Panels?
Wenn ich das richtig gesehen hab, kann DBCopy Daten von mysql nach
influxDB kopieren? Oder hab ich das falsch verstanden?

Viele Grüße
Sirko

Re: [vz-users] Stand InfluxDB

[Andreas Goetz]

Lass es uns einfacher machen: wie sieht Deine Config aus und was davon 
funktioniert nicht? Welche InfluxDB Version hast Du?

Viele Grüße, Andreas


> On 8. Nov 2019, at 10:41, Sirko  wrote:
> 
> Hi,
> 
> wie muß denn die Konfiguration in der dbcopy config.yaml aussehen, wenn
> ich nach influxdb exportieren will?
> Ohne target: nur mit influx: geht nicht, da fehlt das Target, mit
> target: gibt es wohl keinen passenden influxdb driver bei driver:
> 
> Macht es einen (Performance-) Unterschied, wenn ich die komplette "data"
> Spalte mit "copy" oder mit "pk" exportiere?
> 
> Grüße
> Sirko
> 
> Am 25.10.2019 um 12:06 schrieb Sirko:
>> Hi,
>> 
>> wie ist denn der aktuelle Stand bezüglich Volkszähler und InfluxDB? Gibt
>> es Pläne dazu?
>> 
>> Soweit ich gesehen hat, kann vzlogger die Daten schon in eine InfluxDB
>> schreiben. Gibt es irgendwelche Einschränkungen?
>> Meine eigenen Sensoren, die irgendwo auf ESP266 oder NodeMCUs Daten
>> erfassen und an die middleware senden, kann ich wohl recht einfach
>> direkt in die InfluxDB loggen lassen, denke ich.
>> Aber das Frontend kann sicher nicht mit InfluxDB umgehen? Gibt es schon
>> Bsp.-Grafana Dashboards oder Panels?
>> Wenn ich das richtig gesehen hab, kann DBCopy Daten von mysql nach
>> influxDB kopieren? Oder hab ich das falsch verstanden?
>> 
>> Viele Grüße
>> Sirko
>> 
>> 

Re: [vz-users] Stand InfluxDB

[Sirko]

Hi,

wie muß denn die Konfiguration in der dbcopy config.yaml aussehen, wenn
ich nach influxdb exportieren will?
Ohne target: nur mit influx: geht nicht, da fehlt das Target, mit
target: gibt es wohl keinen passenden influxdb driver bei driver:

Macht es einen (Performance-) Unterschied, wenn ich die komplette "data"
Spalte mit "copy" oder mit "pk" exportiere?

Grüße
Sirko

Am 25.10.2019 um 12:06 schrieb Sirko:

Hi,

wie ist denn der aktuelle Stand bezüglich Volkszähler und InfluxDB? Gibt
es Pläne dazu?

Soweit ich gesehen hat, kann vzlogger die Daten schon in eine InfluxDB
schreiben. Gibt es irgendwelche Einschränkungen?
Meine eigenen Sensoren, die irgendwo auf ESP266 oder NodeMCUs Daten
erfassen und an die middleware senden, kann ich wohl recht einfach
direkt in die InfluxDB loggen lassen, denke ich.
Aber das Frontend kann sicher nicht mit InfluxDB umgehen? Gibt es schon
Bsp.-Grafana Dashboards oder Panels?
Wenn ich das richtig gesehen hab, kann DBCopy Daten von mysql nach
influxDB kopieren? Oder hab ich das falsch verstanden?

Viele Grüße
Sirko