FHEM - Entwicklung > FHEM Development

OWServer / OWDevice

(1/2) > >>

Martin Fischer:
hiya boris,

in der commandref ist noch ein weiterer fehler enthalten:

--- Code: ---Example:

    define myOWServer localhost:4304

    get myOWServer devices
--- Ende Code ---

im beispiel fehlt bei dem define die angabe des moduls.

gruss martin

Martin Fischer:
ich war mal so frei und habe weitere devices in OWDevice ergänzt und eingecheckt... und das ohne dir ein patch zu senden ;-)

dabei ist mir noch ein "designfehler" aufgefallen. am beispiel von zwei bausteinen will ich das mal darstellen.

DS2450 - Quad A/D Converter:

dieser bietet u.a.:
[ PIO.[A-D|ALL] | volt.[A-D|ALL] | volt2.[A-D|ALL] ]

nun setzt du ja @getters, @setters und @polls. bei diesem chip ist aber folgendes zu beachten:


--- Code: ---PIO.A ... PIO.D PIO.ALL
       read-write, yes-no
       Pins used for digital control. 1 turns the switch on (conducting). 0 turns the switch off (non-conducting).
       Control is specifically enabled. Reading volt will turn off this control.
       ALL is an aggregate of the voltages. Readings are made separately.
--- Ende Code ---

dabei ist der satz "Reading volt will turn off this control." ausschlaggebend.

und weiter:

--- Code: ---volt.A ... volt.D volt.ALL
   8bit/volt.A ... 8bit/volt.D 8bit/volt.ALL
       read-only, floating point
       Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 5.10V.
       Output ( PIO ) is specifically disabled.
       ALL is an aggregate of the voltages. Readings are made separately.
--- Ende Code ---

hier (gilt auch für volt2.A ... volt2.D) der umgekehrte ausschluss "Output ( PIO ) is specifically disabled.".

ich habe z.b. einen 1-wire hub, der mir über volt.A ... volt.D und volt2.A ... volt2.D den busstrom und die busspannung liefert. damit kann man ausgezeichnet feststellen, wie der bus schon "ausgelastet" ist oder sonstige probleme erörtern.

wird also volt[2].A ... volt[2].D benötigt, dann ist PIO.A ... PIO.D überflüssig. umgekehrt genauso. hier gilt es also zu überlegen, wie man unnötige abfragen nicht benötigter key/values verhindert, denn sie erzeugen ja auch eine gewisse last beim pollen.

DS2438 - Smart Battery Monitor

durch seine vielseitige einsatzmöglichkeit bietet dieser baustein u.a.
temperature | VAD | VDD

beim einsatz als Humidity sensor u.a.:
[ HIH4000/humidity | HTM1735/humidity | DATANAB/reset | DATANAB/humidity | humidity | temperature ]

als Barometer:
[ B1-R1-A/pressure | B1-R1-A/gain | B1-R1-A/offset ]

als Lichtsensor:
[ S3-R1-A/current | S3-R1-A/illuminance | S3-R1-A/gain ]

dieser baustein wird oft in den fertigmodulen von http://iButtonLink.com wie z.b. MS-TH (Temp/Hum) verbaut. als ich den gerade in 11_OWDevice.pm ergänzen wollte (da ich mehrere im einsatz habe) kam mir der gedanke, dass ein eintrag nach deinem schemata nicht funktionieren wird.

a) ist nicht klar, als was der DS2438 eingesetzt wird: VAD, VDD und temperature oder zur rel.luftfeuchtemessung oder als barometer oder lichtsensor. auch hier gilt es wieder unnötige abfragen zu vermeiden.

b) OWFS liefert die daten in "virtuellen unterverzeichnissen". beispiel am MS-TH: HIH4000/humidity. hier wird vermutlich dein "mapping" auf die readings nicht funktionieren, da die readings nur eindimensional sind.

nun könnte man bei b) meinen: warum soll "HIH4000/humidity" ausgelesen werden, wenn es auch "humidity" gibt?

die erklärung:

--- Code: ---humidity
       read-only, floating point
       Relative humidity, as percent (1-100 scale).
       The  DS2438  actually does not read humidity, but a widely available and publicised circuit based on the chip, does. This
       design is for the common Honeywell HIH-3610 humidity chip. The mostly compatible HIH-4000 chip uses different temperature
       compensation, so is better read from the HIH4000/humidity value. See the datasheets for details.
       If the chip is instead a DATANAB design, the DATANAB/humidity value will be automatically used.
--- Ende Code ---

es kommt also zu unterschiedlichen (ggf. falsch ausgelesenen) werten. beispiel aus einem realen MS-TH:

--- Code: ---humidity 57.9001
HIH3600/humidity 60.6089
HIH4000/humidity 60.7172
HTM1735humidity 55.7092
--- Ende Code ---

welcher wert ist jetzt korrekt? da ich nun weiss, dass dort ein HIH4000 verbaut ist, ist also 60.7172 korrekt.

alle "multisensoren" von iButtonLink basieren auf dem DS2438(Z). und wie man an der folgenden aufstellung sieht, werden diese für die verschiedensten zwecke eingesetzt, was auch einfluss auf die @getters, @setters und @polls hat:
MS-T - Temperatursensor
MS-TH - Temperatur-/Luftfeuchtesensor
MS-TL - Temperatur-/Lichtsensor
MS-TC - Temperatur-/Stromsensor
MS-TV - Temperatur-/Spannungsensor
MS-TPD - Temperatur/Airflow Sensor

zwei weitere punkte, die eher auf die "wishlist" gehören, wobei ich dich aber gerne supporten kann:

1. es wäre prima, wenn bei countern die möglichkeit bestünde dieser einmal als "raw" wert (counters.A ...) in den readings zu speichern aber zusätzlich mittels attribut einen "umrechnungsfaktor" für jeden einzelnen counter mitzuliefern, der dann in einem extra reading gespeichert wird. hintergrund: erfasst man irgendwelche verbräuche, dann liefern die counter ja nur einen zählwert, der natürlich erst in die richtige auflösung umgerechnet wird. ein wert von z.b. counters.A 291081 sagt noch nichts aus über den reelen zählerstand von 44811.35 m^3. dabei ist darauf zu achten, das nicht so fehlerhaft vorgegangen wird, wie es in den OWX modulen der fall ist. dort wird zwar die umrechnung ermöglicht, doch wenn fhem startet sind die "raw" werte noch leer und in dem "umrechnungs-reading" wird dann einfach "platt" der wert der formel ohne den noch fehlenden "raw" wert geschrieben. das führt dann in graphen zu enormen peaks, die verbräuche von > 500% und mehr zeichnen. damit ist der graph wertlos, wenn man ihn nicht laufend korrigiert. ob das gefixed wird, wird sich ausgeschwiegen.

2. knüpft eigentlich an 1. an. in dem oben genannten 1-wire hub mit dem DS2450 wird mittels einer schaltung etwas "getrickst" um den busstrom und die busspannung von 12V darzustellen. das "problem" des DS2450 ist nämlich der verwendbare range:

--- Code: ---volt.A ... volt.D volt.ALL
    Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 5.10V.
--- Ende Code ---
und
--- Code: ---volt2.A ... volt2.D volt2.ALL
    Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 2.55V.
--- Ende Code ---

12V passt da also nicht rein. deshalb müssen die werte für 12V busstrom und -spannung mit einem faktor umgerechnet werden. daher selbiger vorschlag wie unter 1. die werte als "raw" speichern aber mittels attribute auch die korrigierten werte in ein extra reading zu schreiben.

willkommen in der 1-wire welt :-)

gruss martin

Dr. Boris Neubert:

--- Zitat von: Martin Fischer schrieb am Sa, 29 Dezember 2012 00:25 ---ich war mal so frei und habe weitere devices in OWDevice ergänzt und eingecheckt... und das ohne dir ein patch zu senden ;-)

--- Ende Zitat ---


Danke!


--- Zitat ---
dabei ist mir noch ein "designfehler" aufgefallen.

...

zwei weitere punkte, die eher auf die "wishlist" gehören, wobei ich dich aber gerne supporten kann:

...

willkommen in der 1-wire welt :-)


--- Ende Zitat ---


Ich will mal folgenden Gedanken reinwerfen. Der könnte helfen, den Designfehler zu beheben und die Wünsche zu erfüllen:

Wir führen ein Attribut
--- Code: ---virtualReading
--- Ende Code ---
ein:


--- Code: ---attr <nameOfOWDevice> virtualReading <reading> <perl-code> [, virtualReading <reading> <perl-code> [, ...]]
--- Ende Code ---


(über die Syntax müssen wir noch nachdenken).

Weil das praktisch für jedes Gerät ist, würde ich das gleich in readingsBulkUpdate() einbauen. Es soll wie folgt funktionieren:

Wenn das Reading namens reading gesetzt wird, wird der Perl-Code ausgeführt und das Ergebnis in das Reading virtualReading geschrieben. virtualReading darf auch ein vorhandenes Reading sein: dann kann man humidity durch foo/bar/humidity ersetzen.

Ich sehe übrigens keinen Grund, warum ein Reading nicht "foo/bar/baz" heißen soll, man darf nur nicht die Gänsefüßchen vergessen.

Was denkst Du?

Grüße
Boris

Martin Fischer:

--- Zitat von: Dr. Boris Neubert schrieb am Sa, 29 Dezember 2012 12:04 ---
Wir führen ein Attribut
--- Code: ---virtualReading
--- Ende Code ---
ein:


--- Code: ---attr <nameOfOWDevice> virtualReading <reading> <perl-code> [, virtualReading <reading> <perl-code> [, ...]]
--- Ende Code ---


(über die Syntax müssen wir noch nachdenken).
--- Ende Zitat ---


wäre ein gangbarer weg. wobei ich auf die schnelle nicht weiss, wie ich dann von virtualReading zu virtualReading variablen übergeben könnte, wenn es denn nötig wäre.


--- Zitat ---Ich sehe übrigens keinen Grund, warum ein Reading nicht "foo/bar/baz" heißen soll, man darf nur nicht die Gänsefüßchen vergessen.
--- Ende Zitat ---

das halte ich für problematisch oder eher "unsauber". besonders wegen den generierten events. auch wenn ich z.b. von extern die werte polle um sie in einem anderen tool weiter zu verarbeiten. da sind "singlewords" schon sinnvoller.

in der theorie sollte das zwar kein problem darstellen, weiss aber nicht was das für seiteneffekte hat (xmllist, json, etc.(http://images/smiley_icons/icon_wink.gif).

gruss

Martin Fischer:
es wäre auch nicht falsch, gleich zu begin auf das neue modul von rudi (blockingcall) zurück zu greifen und das via attribut setzen zu können. ich hatte das bei meinen nicht veröffentlichten 1-wire modulen so gemacht, da es trotz OWFS zeitweise zu latenzen kommt, die fhem "aufhalten". vielleicht auch gleich noch per attribut definierbar ob die abfragen über den OWFS cache kommen sollen.

attr <myOWDevice> cached [0|1]
attr <myOWDevice> pollAsChild [0|1]

oder so ähnlich. vielleicht auch nicht per OWDevice sondern global über das OWServer device (wo dann auch weitere settings gesetzt werden könnten, wie z.b. tempscale, etc.(http://images/smiley_icons/icon_wink.gif)

gruss

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln