OWServer / OWDevice

Begonnen von Martin Fischer, 28 Dezember 2012, 22:35:33

Vorheriges Thema - Nächstes Thema

Martin Fischer

hiya boris,

in der commandref ist noch ein weiterer fehler enthalten:
Example:

    define myOWServer localhost:4304

    get myOWServer devices

im beispiel fehlt bei dem define die angabe des moduls.

gruss martin
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

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:

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.

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

und weiter:
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.

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:
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.

es kommt also zu unterschiedlichen (ggf. falsch ausgelesenen) werten. beispiel aus einem realen MS-TH:
humidity 57.9001
HIH3600/humidity 60.6089
HIH4000/humidity 60.7172
HTM1735humidity 55.7092

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:
volt.A ... volt.D volt.ALL
    Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 5.10V.
und volt2.A ... volt2.D volt2.ALL
    Voltage read, 16 bit resolution (or 8 bit for the 8bit directory). Range 0 - 2.55V.

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
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Dr. Boris Neubert

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

Danke!

Zitatdabei 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 :-)


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 virtualReading ein:

attr <nameOfOWDevice> virtualReading <reading> <perl-code> [, virtualReading <reading> <perl-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

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Martin Fischer

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

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

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

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.

ZitatIch sehe übrigens keinen Grund, warum ein Reading nicht "foo/bar/baz" heißen soll, man darf nur nicht die Gänsefüßchen vergessen.
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.(//images/smiley_icons/icon_wink.gif).

gruss
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

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.(//images/smiley_icons/icon_wink.gif)

gruss
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Martin Fischer

noch ein vorschlag:

neues device OWAlarm

OWFS bietet ein extra pfad "alarm" (oder war es alarms?) an, der aber (wenn ich mich recht entsinne) nur dann erscheint, wenn ein alarm anliegt. wenn man nun mittels des devices OWAlarm laufend pollt, dann könnten daraus events erzeugt werden. dann brauchst du die ganze methode nicht in OWDevice einbauen. oder aber statt OWAlarm die funktion in OWServer integrieren.

testen kannst du das ganze in dem du mal templow oder temphigh so setzt, das ein alarm erzeugt wird. dann sollte obiges verzeichnis zu sehen sein. anhand der einträge in /alarm(s) kann man dann auch wieder auf das in fhem definierte device mappen.

ansonsten könntest du noch ein weiteres get in owserver einbauen, das die (oder bestimmte) werte aus statistics/errors auflistet. die angaben sind nützlich bei der fehlersuche.

wie gesagt: ich kann die sachen auch selber einbauen aber ich lasse dir den vortritt damit wir nicht beide darin basteln.

als nächstes sollten wir mal schauen, wie wir owfs auf die fritzbox per "extra image a la fhem" bekommen.

gruss
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Dr. Boris Neubert

Zitat von: Martin Fischer schrieb am Sa, 29 Dezember 2012 00:25wird 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.


es gibt jetzt mit
- polls
- interfaces
zwei neue Attribute an OWDevice. polls definiert, welche Readings gepollt werden (ueberschreibt den Default) und interfaces definiert, welches interfaces das Geraet bietet (ueberschreibt den Default).

Damit sollte das erste Problem erledigt sein.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

Zitat von: Martin Fischer schrieb am Sa, 29 Dezember 2012 13:54
ZitatIch sehe übrigens keinen Grund, warum ein Reading nicht "foo/bar/baz" heißen soll, man darf nur nicht die Gänsefüßchen vergessen.
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.

Ich habe leider kein Device, wo ich das mal ausprobieren könnte. Hast Du eins? Kannst Du dafür einfach mal foo/bar in den getters definieren und schauen, ob es grundsätzlich funktioniert?

In dem Bezeichner des Readings könnten wir dann ja / durch _ ersetzen.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Martin Fischer

Zitat von: Dr. Boris Neubert schrieb am Mo, 31 Dezember 2012 13:50Ich habe leider kein Device, wo ich das mal ausprobieren könnte. Hast Du eins? Kannst Du dafür einfach mal foo/bar in den getters definieren und schauen, ob es grundsätzlich funktioniert?
DAS glaube ich dir nicht! du hast nur die man zu owfs.conf nicht gelesen :-)

FAKE = 10,1B # Random simulated device with family codes (hex)
dann hättest soooooo viele devices aller verschiedenen familycodes, wie du willst. 10,1B ist nur ein beispiel! nimm mal u.a. familycode 26 für einen multisensor.

ZitatIn dem Bezeichner des Readings könnten wir dann ja / durch _ ersetzen.
irgendwie bin ich kein freund davon, originale bezeichner zu verändern. gerade, wenn man sie dann auch von extern bearbeiten will. ich hab da noch keine meinung zu. das problem ist halt das mapping von verschachtel auf eindimensional.

gruss martin
--
Admin, Developer, Gründungsmitglied des FHEM e.V.