[vz-dev] Anpassung Einheiten

[Andreas Goetz]

Hallo Udo, *,

2014-06-22 15:50 GMT+02:00 Udo1 <udo1 at gmx.net>:

> Am 22.06.2014 14:24, schrieb Andreas Goetz:
>
>  > Thomas' Zähler nutzt einen Kanal vom Typ "El. Energie (Leistungswerte)"
>> (powersensor, nutzt intern den SensorInterpreter). Dies ist der einzige
>> Kanaltyp  der keine "Resolution" unterstützt.
>> Genau das ist ja das Problem nach meinem Vertändnis.
>>
>

>  Richtig, im älteren Frontend hieß der "Stromsensor". Dort kann man keine
> "Auflösung" einstellen. Wäre es nicht einfacher dort eine "Auflösung" zu
> implementieren? Keine Ahnung ob das geht und wieviel Aufwand das ist.
>

Danke- genau das war ja der Vorschlag ;) Aber wie gesagt- wenns das im
vzlogger auch gibt kann es zu Verwirrung führen. Aufwand ist überschaubar.

Ich hab ein kleines Reportingtool gebaut um etwas Überblick über die
EntityDefinition.json zu bekommen. So sieht das Ergebnis bzgl. "resolution"
aus:

== Volkszaehler\Interpreter\AggregatorInterpreter ==
group:  not allowed
user:   not allowed
building:       not allowed


== Volkszaehler\Interpreter\SensorInterpreter ==
flow:   not allowed
voltage:        not allowed
current:        not allowed
powersensor:    not allowed
temperature:    not allowed
pressure:       not allowed
humidity:       not allowed
windspeed:      not allowed
radiation:      optional <-- lustich
luminosity:     not allowed
valve:  not allowed


== Volkszaehler\Interpreter\MeterInterpreter ==
heat:   required
power:  required
gas:    required
water:  required
workinghours:   required


== Volkszaehler\Interpreter\CounterInterpreter ==
electric meter: required
gas meter:      required

Besonders lustig ist, dass der radiation Sensor (wer hat den im Betrieb ;?)
<resolution> erlaubt, der SensorInterpreter aber gar nix damit anfangen
kann. Wenns konsistent werden soll müssten wir also <resolution> bei allen
Sensoren für SensorInterpreter hinzufügen, und zwar als optionales Property
um keine Konflikte mit bestehenden Installationen zu verursachen.

Der Haken: <resolution> ist heute Integer. Für Thomas' Anwendungsfall
brauchen wir aber float da er eine Auflösung von 0,001 hat. Damit lässt
sich kein sinnvolles Minimum mehr festlegen (aktuell 1), ich würde dafür
also sowas wie 1e-6 nehmen um Division durch 0 zu verhindern.

Habe ich etwas vergessen?

WOLLEN WIR DAS WIRKLICH SO EINBAUEN?


> Gruß
> Udo
>

vg
ANdreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140622/17cd0357/attachment.html>