[vz-dev] vzlogger d0-parser

[Peter Evertz]

Am 16.10.2013 17:41, schrieb Thorben Thuermer:
>> Am 16.10.2013 12:35, schrieb Thorben Thuermer:
>>> Peter Evertz, Tue Oct 15 23:34:41 CEST 2013:
>>>> Ich fliege zwar "blind" mangels zähler, aber ich würde sagen der
>>>> vzlogger code kann nicht funktionieren. Ist also etwas schwieriger als
>>>> "send pullseq2"
>>> ja, der code funktioniert.
>>> (zumindest frueher ohne pullseq mit zaehlern die von sich aus senden)
>>> wie kommst du darauf, das er ganz kaputt sein sollte?
>>>
>>> der parser ist halt nicht toll und sollte mal neu geschrieben werden.
>> danke für die Infos. Ich würde gern den Parser neu schreiben damit er
>> etwas "robuster" ist. Gegen den E350 kann der Code IMHO nicht gehen,
>> daher die Frage ob ihn überhaupt jemand benutzt.
>>
>> Könnt Ihr mir die Zähler nennen die funktionieren, und am besten eine
>> Link zur Doku. Damit ich, wenn ich versuche die anderen Zähler
>> einzubinden, nicht die alten kaputt mache.
>> Sowas wie dieses wäre super:
>> Zusätzlich wäre wichtig zu wissen:
>> - Schickt Ihr ( z.B. per Script) eine Pullsequenz ?
>> - Antwortet der Zähler dann kontinuierlich, oder nur einmal?
> mutig mutig, dass du die aufgabe uebernehmen willst!
>
> ich hatte auch die ueberlegung, erstmal ein test-set von zaehlerausgaben
> zu sammeln, um dann den parser dagegen testen zu koennen.
> (wichtig ist, dass die korrekt geloggt werden, da sie auch nicht-druckbare
>   zeichen enthalten koennen!)
> einige sollten sich schon im wiki finden, ansonsten sollte man nochmal
> einen aufruf auf der liste machen.
>
> das wird aber bei den pull-sequenzen wenig helfen,
> weil dort zT. auch das timing kritisch ist, etc.,
> und man das ohne die hardware eh nicht testen kann.
>
> ich denke wichtig ist:
> ein parser, der robust ist, und alles was einigermassen d0 ist verarbeiten kann.
> zB. damit klarkommt, wenn die anforderungssequenz aufgrund von reflektionen
> mit zurueckgelesen wird, vorhandensein von <STX> bytes oder nicht,
> endmarkeriung am ende des telegramms oder nicht, etc...
> vlt. einfach eher per brute-force nach gueltigen zeilen suchen.
Hallo Thorben,
genau an  diese "Brutale Gewalt" hatte ich gedacht bei "robust". Jetzt 
muss alles genau passen damit es funktioniert.

Ich dachte an folgende Logik:

wenn PULL1 definiert dann schicke PULL1

loop {
lese Zeile ( bis CR/LF)

wenn (   beginnt mit "/" und PULL2 definiert )
     schicke PULL2
wenn  ( beginnt mit "!" )
     verlasse loop
wenn Muster "xxx(yyy*zzz) CR/LF
         schaue ob es OBIS ist dann add to ret[]
}
return ret[]

Ich denke das sollte mit den Zählern die ich bis jetzt angeschaut habe 
funktionieren.

Das Timing ist glaube ich unkritisch. Es gibt ja immer Frage / Antwort 
abwechslung. Die timing Probleme sind IMHO nur bei den Skript lösungen 
vorhanden, weil man dort "raten" muss wann der Zähler geantwortet hat.
Es gibt (bei den PULL Zählern) ein Limit wie oft er befragt werden darf, 
und das ist es schon mit "interval" steuerbar.

  Grüße
Peter

>
> sowie eine engine zum erzeugen von anforderungssequenzen die flexibel genug ist
> um beliebige zaehler bedienen zu koennen.
> man muesste halt zu sendende zeichen konfigurieren koennen,
> pausen, abzuwartende antworten, baudraten-wechsel...
>
> macht halt alles nicht unbedingt spass...
>
>> Grüße
>> Peter
> - Thorben