[vz-users] Elster AS1440 - vzlogger.conf
Jörg Hildering
joerghildering at gmail.com
Wed Jan 18 10:17:17 CET 2017
Hallo,
Ich habe von meinem Versorger folgende Antwort bekommen. Womit kann ich das trotzdem kostengünstig umsetzen. Hat jemand Zählervorschläge?
Sehr geehrter Herr Hildering,
leider ist diese IR-Schnittstelle nur zum zwecke der Konfiguration des Zählers vorgesehen.
Der Hersteller bietet zwar die Möglichkeit an, Daten aus dem AS1440 zu bekommen,
dieses ist, bei unserem Softwarestand im Zähler, nicht möglich!
Guten Morgen Herr Hildering,
dieses ist so nicht machbar da wir bei einem Softwareupdate die
MID (Eichung) des AS1440 verlieren.
Weiter ist es für Sie nicht sinnvoll sich an unserem Zähler zu binden,
da wir uns gerade in einer Umstellphase der Messtechnik in Deutschland befinden.
Das heißt das sich die Messtechnik innerhalb der nächsten Jahre stark verändern wird.
Demnach würden wir auch keinen Bestandsschutz für die Zähler geben, da wir heute
noch nicht wissen ob es mit der zukünftigen Messtechnik abbildbar ist!
Vielleicht ein Tipp, lassen Sie sich eine eigene Messung (Hutschinenzähler oder vergleichbar)
zum zwecke der Regelung in Ihrer Verteilung bauen, somit bleiben Sie unabhängig!
Gruß
Jörg
> Am 18.01.2017 um 09:53 schrieb volkszaehler-users-request at demo.volkszaehler.org:
>
> Send volkszaehler-users mailing list submissions to
> volkszaehler-users at demo.volkszaehler.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://demo.volkszaehler.org/mailman/listinfo/volkszaehler-users
> or, via email, send a message with subject or body 'help' to
> volkszaehler-users-request at demo.volkszaehler.org
>
> You can reach the person managing the list at
> volkszaehler-users-owner at demo.volkszaehler.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of volkszaehler-users digest..."
>
>
> Today's Topics:
>
> 1. Re: host vs. dev WAR: Middlware und vzlogger.conf
> (Daniel Lauckner)
> 2. Re: Elster AS1440 - vzlogger.conf (Daniel Lauckner)
> 3. Re: Elster AS1440 - vzlogger.conf (Udo1)
> 4. Re: vzlogger an zweite middleware (Andreas Goetz)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Jan 2017 08:40:20 +0100
> From: Daniel Lauckner <vz at jahp.de>
> To: volkszaehler-users <volkszaehler-users at demo.volkszaehler.org>
> Subject: Re: [vz-users] host vs. dev WAR: Middlware und vzlogger.conf
> Message-ID: <1369684764.20170118084020 at jahp.de>
> Content-Type: text/plain; charset=utf-8
>
> In der todo steht noch der Punkt: "todo: dependency for aggmode!=none and aggtime"
> Soweit ich das sehe ist das nicht möglich.
>
> 1. über "dependencies" werden Schlüssel nur auf Vorhandensein geprüft, der Wert ist irrelevant.
> 2. bei meinen Tests war eine Prüfung nur innerhalb des gleichen Objekts (oder Arrays) möglich.
>
>
> mfg Daniel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 18 Jan 2017 08:46:39 +0100
> From: Daniel Lauckner <vz at jahp.de>
> To: "volkszaehler.org - users"
> <volkszaehler-users at demo.volkszaehler.org>
> Subject: Re: [vz-users] Elster AS1440 - vzlogger.conf
> Message-ID: <1841727700.20170118084639 at jahp.de>
> Content-Type: text/plain; charset=utf-8
>
> Hallo Jörg,
>
>
> am Dienstag, 17. Januar 2017 um 21:30 hast du geschrieben:
>> Hab noch mal die config von Udo genommen. Ich Frage mich nur gerade warum da jetzt:
> [...]
>> rauskommt obwohl da gestern folgendes raus kam:
> [...]
>
> Weil du ne ander pullseq gesendet hast.
>
>
> mfg Daniel
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Jan 2017 09:46:59 +0100
> From: Udo1 <udo1 at gmx.net>
> To: volkszaehler-users at demo.volkszaehler.org
> Subject: Re: [vz-users] Elster AS1440 - vzlogger.conf
> Message-ID: <d50bcc97-ee91-28cc-4de4-1852c6d499d2 at gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>> Am 17.01.2017 um 21:30 schrieb Jörg Hildering:
>> rauskommt obwohl da gestern folgendes raus kam:
> Dann versuch mal diese vzlogger.conf:
>
> {
> "retry": 0,
> "daemon": true,
> "verbosity": 15,
> "log": "/tmp/vzlogger.log",
> "local": {
> "enabled": false,
> "port": 8080,
> "index": true,
> "timeout": 0,
> "buffer": 0
> },
> "meters": [
> {
> "enabled": true,
> "allowskip": false,
> "interval": -1,
> "aggtime": -1,
> "aggfixedinterval": false,
> "channels": [
> {
> "uuid": "fecfbcb0-dbcd-11e6-82e8-fbd50a08bbad",
> "identifier": "1-1:1.7.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> {
> "uuid": "2e5b9e90-dbce-11e6-80f6-815def6d716e",
> "identifier": "1-1:1.8.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> {
> "uuid": "64f3dcf0-dbce-11e6-96cc-3b84f4827523",
> "identifier": "1-1:2.7.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> {
> "uuid": "8a4045a0-dbce-11e6-b54f-e7647c70d2a1",
> "identifier": "1-1:2.8.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> ],
> "protocol": "d0",
> "device": "/dev/lesekopf0",
> "pullseq": "2F3F34303332333831210D0A",
> "baudrate": 300,
> "parity": "7e1",
> "read_timeout": 100
> },
> {
> "enabled": true,
> "allowskip": false,
> "interval": -1,
> "aggtime": -1,
> "aggfixedinterval": false,
> "channels": [
> {
> "uuid": "ade13a80-dbce-11e6-a114-19b6bfd4ca11",
> "identifier": "1-1:2.7.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> {
> "uuid": "ce10b540-dbce-11e6-bc79-6703ed7971e2",
> "identifier": "1-1:2.8.0",
> "api": "volkszaehler",
> "middleware": "http://localhost/middleware.php",
> "aggmode": "none",
> "duplicates": 0
> },
> ],
> "protocol": "d0",
> "device": "/dev/lesekopf1",
> "pullseq": "2F3F34303332333930210D0A",
> "baudrate": 300,
> "parity": "7e1",
> "read_timeout": 100
> }
> ]
> }
>
> Wobei da jetzt noch die Seriennummern in den pullseq vertauscht sein können.
>
> Gruß
> Udo
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2017 09:53:04 +0100
> From: Andreas Goetz <cpuidle at gmail.com>
> To: "volkszaehler.org - users"
> <volkszaehler-users at demo.volkszaehler.org>
> Subject: Re: [vz-users] vzlogger an zweite middleware
> Message-ID:
> <CAD+a8MjDOo+UexeVkJc-Lq4LgCP-CPdH9MtuFzuwgWw36wSj_A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Andre,
>
> ich habe auch den Root Cause gefunden. Durch die Optimierung des UIs wird
> "active" plötzlich bei Serialisierung der Properties mit einbezogen-
> ziemlich unerwartet für den armen Programmierer :O
>
> Das baue ich aus und dann sehen wir weiter...
>
> vg
> Andreas
>
>
> 2017-01-17 22:03 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>
>> Probiers- wir brauchen aber keinen zweiten Workaround wenn das unten
>> funktioniert? Die Entity kanns halt mehrmals geben- eine ganze Liste dienst
>> nur der Dropdownbox im “Add Channel” Dialog.
>>
>> Wenn Du Zeit hast könntest Du nochmal testen was passiert wenn die gleiche
>> Entity mehrmals in der Tabelle ist, z.B. einzeln als auch in einer Gruppe.
>> Der Übersichtichkeit halber mach mir auch gerne ein Issue auf, wird dann
>> gefixt…
>>
>> Viele Grüße, Andreas
>>
>> On 17 Jan 2017, at 21:51, Andre Bernemann <andre.bernemann at gmail.com>
>> wrote:
>>
>> Hallo Andreas,
>>
>> also ich schau mir das gerne auch noch im Push-Server an, wird aber diese
>> Woche nicht mehr klappen. Die Entity sollte ja auf im FE schon erkennen,
>> dass es schon eine Subscription gibt - (Observer? Singleton?).
>>
>> Spricht was dagegen das Table-Clear im DOM Update zunächst mit ins if zu
>> ziehen? Dann hätten wir einen Workaround...
>>
>> Gruß
>> André
>>
>> Andreas Goetz <cpuidle at gmail.com> schrieb am Di., 17. Jan. 2017 um
>> 09:22 Uhr:
>>
>>> Moin Frank,
>>>
>>> schau mal hier: https://github.com/volkszaehler/volkszaehler.org/
>>> blob/master/htdocs/frontend/javascripts/middleware.js#L49
>>>
>>> Probier mal ob Du einfach active auf false setzen kannst:
>>>
>>> json.entities.forEach(function(json) {
>>> entity.active = false;
>>> this.public.push(new Entity(json, this.url));
>>> }, this);
>>>
>>> Viele Grüße,
>>> Andreas
>>>
>>>
>>> 2017-01-16 23:13 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>>>
>>> Hallo,
>>>
>>> On 16 Jan 2017, at 22:30, Andre Bernemann <andre.bernemann at gmail.com>
>>> wrote:
>>>
>>> Hi Andreas,
>>>
>>> Andreas Goetz <cpuidle at gmail.com> schrieb am Mo., 16. Jan. 2017 um
>>> 18:06 Uhr:
>>>
>>> Hi Andre,
>>>
>>> 2017-01-16 17:24 GMT+01:00 Andre Bernemann <andre.bernemann at gmail.com>:
>>>
>>> Hi Andreas,
>>>
>>> in Entity.prototype.updateDOMRow wird die Tabellenzeile zunächst geleert,
>>> um sie dann mit neuen Daten zu befüllen. In meinem Fall hat das übergeben
>>> JS Objekt keinen Member "rows" [if (this.data && this.data.rows > 0)]. Die
>>> Tabelle wird bei mir korrekt geleert, aber es werden keine neuen Daten
>>> geparsed. Unabhängig von der Ursache könnte das clear mit ins if, damit
>>> umgeht man den Fehler aber natürlich nur.
>>>
>>> ...
>>>
>>>
>>>
>>>
>>>
>>> parseJSON erzeugt bei mir beim Laden Subscriptions auch für nicht
>>> angezeigte - aber aktive Channels.
>>>
>>>
>>> Was meinst Du damit? Was für Kanäle sollen das sein?
>>>
>>>
>>> parseJSON wird beim Startup für alle Kanäle durchlaufen, unabhängig davon
>>> ob es überhaupt im FE angezeigt wird.
>>>
>>>
>>> Verdammt- ich fürchte Du hast recht. Das ist das im letzten Update rein
>>> gekommene laden der Public Entities. Idee war nicht bei jedem Dialogfenster
>>> erstmal warten zu müssen. Soweit ich sehe ist parseJson im Prinzip ok bis
>>> auf das abschließende subscribe(). Jetzt fehlt nur noch eine gute Idee wo
>>> das hin kommt.
>>>
>>> Leider muss ich zugeben dass das Frontend einfach viel zu komplex und
>>> leider kaum modular ist :O
>>>
>>> Das führt zu Updates, auch wenn gar kein Kanal im FE ist. Scheinbar geht
>>> er direkt auf die Kanäle der DB. Zusätzlich wird parseJSON auch vom "Kanal
>>> hinzufügen"-Dialog gecalled - vielleicht um die CB zu füllen. Ist
>>> this.active == true, wird Entity.prototype.subscribe() gecalled.
>>>
>>> Das Problem ist seit dem Commit 293dd76 vorhanden, da ist was am MW
>>> Lookup gemacht worden:
>>> ...
>>>
>>> In der alten Version ist mw.session==false für die Calls über parseJSON,
>>> daher ist an der Stelle Ende - die Calls aus ab.connect(...) hingegen haben
>>> eine Session. In der neuen Version haben beide Aufrufe eine Session.
>>>
>>> Jetzt Du :-)
>>>
>>>
>>> Ich glaub die Ursache ist eine andere, aber könnte sein. Allerdings- auch
>>> wenn das die Ursache ist- sollten dennoch in den Updates Daten ankommen und
>>> dann wäre das Phänomen auch weg. Sieht nach einer Macke im Pushserver aus.
>>> Also was fixen?
>>>
>>> Wenn Du so nett sein willst mach bitte ein Issue mit dieser Beschreibung
>>> auf, heute fällt mir keine Halbwegs elegante Lösung mehr ein.
>>>
>>> Viele Grüße, Andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>> Zusätzlich werden in init.js nach dem WAMP connect noch die "richtigen"
>>> Subscriptions erzeugt, wenn der Channel aktiv und sichtbar ist. Vom Timing
>>> her hab ich die korrupte Subscription immer als zweites, ich bekomme also
>>> ein korrektes Update und dann sofort das leere. Setze ich in der db
>>> active=0 funktioniert es übrigens.
>>>
>>>
>>> Alles sehr merkwürdig. Könntest Du mit Logging (console.log) in
>>> entity.subscribe mal versuchen herauszufinden wer/was/wo diese
>>> Subscriptions erzeugt werden?
>>>
>>>
>>>
>>> HTH, sonst sag nochmal Bescheid!
>>>
>>>
>>> Ich fürchte da musst Du erstmal ran bis die Ursache klar ist da ichs
>>> nicht reproduzieren kann. Wenn gar nix hilft u/p per pm an mich.
>>>
>>>
>>>
>>> Gruß
>>>
>>>
>>> Viele Grüße,
>>> Andreas
>>>
>>>
>>> Gruß André
>>>
>>>
>>>
>>>
>>>
>>>
>>> Andreas Goetz <cpuidle at gmail.com> schrieb am Mo., 16. Jan. 2017 um
>>> 11:44 Uhr:
>>>
>>> Moin,
>>>
>>> kannst Du das eingrenzen? Mal nur einen Kanal aktivieren und schauen
>>> welche Requests da an die MW geschickt werden? Wenn sich das Fehlerbild
>>> konkretisieren lässt bitte hier hinzufügen: https://github.
>>> com/volkszaehler/volkszaehler.org/issues
>>>
>>> Viele Grüße,
>>> Andreas
>>>
>>>
>>> 2017-01-14 20:59 GMT+01:00 Andre Bernemann <andre.bernemann at gmail.com>:
>>>
>>> Ja stimmt :-) Ich sende jetzt an die MW der produktiven Umgebung und per
>>> Push an die die produktive und eine weitere zum testen, klappt wunderbar.
>>>
>>> Mein eigentliches Problem ist es, dass ich bei aktiviertem Push keine
>>> Werte in der Tabelle bekommen:
>>>
>>> <pasted1.png>
>>> Die Werte tauchen kurz auf wenn das Frontend geladen ist, verschwinden
>>> dann aber beim ersten Push vom push-server. Zusätzlich hab ich dann
>>> sinnlose Werte für den Gesamtverbrauch. Sowas schon mal einer gesehen?
>>>
>>> Gruß
>>>
>>>
>>> Frank Richter <frank.richter83 at gmail.com> schrieb am Sa., 14. Jan. 2017
>>> um 19:37 Uhr:
>>>
>>> Cool, wieder was gelernt:-)
>>> Daten nur per push senden, aber nicht an Middleware/DB klappt übrigens
>>> auch: dafür in der Kanaldefinition "api": null setzen
>>> Das mach ich so mit den Momentanleistungen meiner Zähler.
>>>
>>> Gruß
>>>
>>>
>>> Frank
>>> Am 14.01.2017 18:57 schrieb "Andre Bernemann" <andre.bernemann at gmail.com
>>>> :
>>>
>>> Push funktioniert mit 2 Einträgen, das reicht mir erstmal.
>>>
>>> Danke.
>>>
>>> Gruß
>>> André
>>>
>>>
>>> Frank Richter <frank.richter83 at gmail.com> schrieb am Sa., 14. Jan. 2017
>>> um 17:17 Uhr:
>>>
>>> Hallo Andre,
>>>
>>> mehrere Middlewares sollte gehen, wenn man den Kanal mehrfach anlegt. Bei
>>> push bin ich allerdings überfragt. Allerdings ist push ja immerhin ein
>>> JSON-Array - mach doch mal einen 2. URL-Eintrag, probieren kostet ja nix...
>>>
>>> Gruß
>>>
>>>
>>> Frank
>>> Hi,
>>>
>>> ich würde gerne ein paar Sachen mit dem Push-Server testen. Ist der
>>> vzlogger irgendwie in der Lage die gleichen Kanäle an 2 Middlewares und an
>>> zwei Push-Server gleichzeitig zu senden?
>>>
>>> Gruß,
>>> André
>>>
>>>
>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170118/ffe6b8e3/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> volkszaehler-users mailing list
> volkszaehler-users at demo.volkszaehler.org
> https://demo.volkszaehler.org/mailman/listinfo/volkszaehler-users
>
>
> ------------------------------
>
> End of volkszaehler-users Digest, Vol 66, Issue 84
> **************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170118/8e1dc280/attachment-0001.html>
More information about the volkszaehler-users
mailing list