OWServer / OWDevice

[Dr. Boris Neubert]

Code Auswählen Erweitern

attr myGasMeter userReadings erdgas { (ReadingsVal("myGasMeter","counters.A",0)+AttrVal("myGasMeter","myBasis",0))/100.0;; }

Darin steckt schon der Faktor 0.01. Unklar ist mir aber "myBasis" - kommt hier der Offset um 1394735 rein? Oder wofür steht myBasis? Dazu habe ich nichts gefunden. Wo würde man den Offset addieren?

Na, Du bist doch schon fertig. Mit

Code Auswählen Erweitern

attr myGasMeter myBasis 1394735 hast Du es geschafft. Du mußt Dir lediglich noch myBasis als userattr definieren.

Viele Grüße
Boris

[Schorsch]

Danke Boris! Musste nur noch ein

Code Auswählen Erweitern

attr global userattr myBasis einfügen, jetzt läuft's prima!
Hier noch meine Device Definition, falls sie jemand anderem hilft:

Code Auswählen Erweitern

define myGasmeter OWDevice 1D.nnnnnnnnnnnn 60
attr myGasmeter model DS2423
attr myGasmeter myBasis 1394735
attr myGasmeter userReadings erdgas { (ReadingsVal("myGasmeter","counters.A",0)+AttrVal("myGasmeter","myBasis",0))/100.0;; }
attr myGasmeter stateFormat {sprintf("%.2f",ReadingsVal("myGasmeter","erdgas",0))."m3"}
attr myGasmeter room K.Heizung
Als nächstes muss ich Ratenberechnung verstehen - gibt's da eine Quelle zum Einlesen? Müsste ja wohl OldValue mit Timestamp zum aktuellen Value / Timestamp ins Verhältnis setzen und dann auf eine Stunde hochrechnen...
Muss ich grundsätzlich verstehen, brauche ich auch für die Stromzähler :-)

Viele Grüße,
Georg

[ragnaroek]

Ich schaffe es nicht, mit einem DS9490R als USB/1wire-Adapter durch OWDevice DS2406 bei einer gelesenen Zustandsänderung ein event in fhem ausgelöst zu bekommen.

Nur wenn das Device periodisch gepollt wird, bekomme ich ein event. Ich möchte aber schnell auf eine Zustandsänderung am PIO reagieren und hoffe das das feature schon unterstützt wird.

set-alarm steht auf 331.

Gibt es hierzu schon Erfahrungen? Oder eine Theorie?

[Martin Fischer]

> Nur wenn das Device periodisch gepollt wird, bekomme ich ein event. Ich möchte
> aber schnell auf eine Zustandsänderung am PIO reagieren und hoffe das das feature
> schon unterstützt wird.

das ist die funktionsweise von 1-wire. ohne periodischem polling kommt da nichts automatisch.

gruss martin

[ragnaroek]

Verstanden! Statt nun aber alle OWDevices zu pollen, reichte es doch, für zeitkritische Fälle nur das owfs-Verzeichnis "alarm" zu pollen. Hier stehen genau die OWDevices drin, für die ein neuer Alarm auftrat. Dies dürfte i.d.R. eine viel kleinere Teilmenge sein.

Ich schlagen vor, dass dieses Verzeichnis unabhängig von den OWDevice Intervallen mit einem vergleichsweise kurzen Intervall gepollt werden kann.
Für jedes neu im owfs-Verzeichnis "alarm" auftauchende OWDevice sollte dann einmalig ein event ausgelöst werden, damit spontane Alarmbehandlung erfolgen kann.

Mit dieser Erweiterung für OWServer_Get und "get <myOWServer> alarms" werden die OWDevices im Alarmzustand ausgegeben und die poll-Readings aktualisiert:

Code Auswählen Erweitern


  } elsif($cmd eq "alarms") {
        my $path= "alarm";
        my @dir= split(",", $owserver->dir($path));
        my $ret= "";

        for my $device (@dir) {
          $device =~ s|/alarm/||g;
          my $name;

          foreach my $d (keys %defs) {
            next if($defs{$d}{TYPE} ne "OWDevice");
            if(defined($defs{$d}{fhem}) &&
               defined($defs{$d}{fhem}{address}) && $defs{$d}{fhem}{address} eq $device) {
              $name = $defs{$d}{NAME};
              OWDevice_UpdateValues($defs{$d});
             next;
            }
          }

         $ret .= "$name\n";
        }
        return $ret;

Wir bräuchten ein Attribut für OWServer, mit dem das Alarm-Polling eingestellt wird und dann die Poll-Readings aller Alarm-OWDevices regelmäßig gepollt werden würden. Das würde dann die Events auslösen, von denen ich träume - ohne dass sämtliche OWDevices gepollt werden müssen...

[ntruchsess]

nur mal kurz zum Verständniss: auch das owfs pollt die OW-devices auf dem Bus, d.h. Devices deren Status auf 'Alarmed' wechselt tauchen genauso erst mit einer gewissen Verzögerung im owfs 'alarm' Verzeichniss auf. Es ist einfach nicht vorgesehen, dass sich die Devices selbstständig melden.

Bei den beliebten DS18B20 muss z.B. muss dafür nicht nur ein search nach alarmed-devices auf dem Bus gemacht werden - damit die Sensoren überhaupt in den Status alarmed gehen, muss man erst mal eine Messung (selbstverständlich auch über den 1-Wire Bus) auslösen. Das Ganze ist also vom Prinzip her nicht für unmittelbare Reaktionen beim Über- oder Unterschreiten eines Schwellwerts geeignet, eine gewisse Verzögerung ist hierbei schlichtweg unvermeitlich.

Natürlich ist es trotzdem sinnvoll das 'alarm'-verzeichnis des owfs öfter zu pollen als die Gesammtheit der Devices...

Gruß,

Norbert

[Martin Fischer]

genau so, wie es norbert geschrieben hat verhält es sich.

OWServer wird auch noch das "alarmpolling" bekommen, das steht schon auf meiner todo, da ich es in meinen alten (nicht veröffentlichten OW modulen) auch schon so hatte.

das setzt aber voraus, das vorher auch gemessen wurde. also: das eine geht nicht ohne dem anderen. demnach wird man nicht drum kommen, die messung im device zu machen und das liefert eh den alarmzustand zurück. über den OWServer wäre halt nur noch eine "nice to have" funktion, die zentral alarme ausgibt, die aber eh von jedem device bei einem reading kommen.

gruss martin

[ragnaroek]

Das hört sich super an, Martin!

Bei den PIOs des DS2406 ist der Alertstatus wohl etwas anders gehandhabt als beim DS18B20, wo eine eigene Temperaturmessung erforderlich ist. Ich habe reichlich viele der PIOs und muss dank der Alerts nicht alle PIOs nacheinander pollen, um zu sehen, welches Fenster offen ist.

Ich bin kein perler, aber hier ist mein patch für die Alarme. Dann sähe die Eventbehandlung zB. so aus:

Code Auswählen Erweitern


define myOWServer OWServer localhost:4304
attr myOWServer alarms 1                                 #poll every sec the alarms of owfs

define C_Keller OWDevice 12.EFBA7B000000 300
attr C_Keller model DS2406
attr C_Keller room 000_Keller

define X_C_Keller notify C_Keller {if(ReadingsVal("C_Keller","alarm",0) eq 1) { ....dosomething;;   set C_Keller latch.BYTE 0"}}

mit latch.BYTE setze ich den Alarm zurück.

Vielleicht könnt Ihr es gebrauchen.

[Martin Fischer]

> Ich bin kein perler, aber hier ist mein patch für die Alarme. Dann sähe die Eventbehandlung zB. so aus:

ich werds mir die tage mal näher anschauen..

gruss martin

[ntruchsess]

zum Alarmsearch möchte ich da gerne noch ein wichtiges Detail anmerken:

Man kann auf dem Bus ein Reset/Skip/Convertcommand abschicken, bei dem kein Device explizit addressiert wird und sich alle angesprochen fühlen. Dann starten alle DS18B20 ihre A/D-Wandlung parallel. 1 Sekunde später führt man dann einfach den Alarm-search durch und fragt nur die Devices explizit ab, die sich im Alarmsearch gemeldet haben.
Das ist deutlich effektiver als alle Devices in Gänze zu pollen (wobei man das Alarm-flag natürlich auch mitkriegt).

Gruß,

Norbert

[Tobias]

Hallo,
kann mir einer Sagen warum bei mir stateformat die Readings nicht ersetzt?

attr 1wire_hub stateformat +5V:volt.B +5V:5V_Spannung

Es existiert ein REading volt.B als auch ein UserReading 5V_Spannung.
Leider hat STATE aber hinterher extakt diesen String, die Readings wurden nicht durch den jeweiligen Wert ersetzt.
Idee was ich falsch mache?

STATE +5V:volt.B +5V:5V_Spannung

[Tobias]

habs workaroundmäßig jetzt so gelöst:
userreading:

Code Auswählen Erweitern

12V_Spannung {ReadingsVal("$name", "volt.B",0) * 2.67;}, 5V_Spannung {ReadingsVal("$name", "volt.D",0) * 1.11}, 12V_Strom {((ReadingsVal("$name", "volt.A",0) - 0.028) / 19.55) * 1000}, 5V_Strom {((ReadingsVal("$name", "volt.C",0)- 0.028) / 19.55) * 1000}
stateformat:

Code Auswählen Erweitern

{sprintf("+5V: %0.2fV %0.2fmA | +12V: %0.2fV %0.2fmA", ReadingsVal("$name", "5V_Spannung",0), ReadingsVal("$name", "5V_Strom",0), ReadingsVal("$name", "12V_Spannung",0), ReadingsVal("$name", "12V_Strom",0))}

[Schorsch]

Schnieke! Da muss bei userReadings denke ich nur das Semikolon hier

Code Auswählen Erweitern

* 2.67;} raus. Geht bei mir jedenfalls nur ohne. Dann aber umso schöner :-)

[fossy]

Hi,

...
Ich habe einen Temperatur/Luftdrucksensor EDS0066 und habe diesen mit folgendem Code in OWDevice eingebunden:

$owdevice{"7E"} = {
# EDS0066 - Multisensor temperature Pressure
...


Für mich reichen diese Minimal-Daten. ...

bin gerade über diesen Thread gestolpert und habe dabei festgestellt, das meine Frage hier, eigentlich besser hier direkt rein gepasst hätte. Bzgl. der EDS-Geräte - ich habe genau zwei andere...
... und da funktioniert das mit der Minimal-Version nicht mehr :-(

[ext23]

Hallo,

Ich habe mir erhofft, dass der iButton-Probe ebenfalls eine ID besitzt und somit ausgewertet werden kann, auf welchem Probe der iButton angebracht ist. Jedoch ist die einzige Elektronik die auf dem Probe vorhanden ist, die 2 LED's. Ich wollte verschiedene Probe einsetzen für Presence mit dem Schlüsselbrett aber auch um mein Garagentor zu öffnen, das geht nun aber nicht mit dem selben iButton. Oder hat da noch jemand eine Idee?

ich bin jetzt auch auf ein ähnliches Problem gestoßen. Ich baue mir gerade ein Schlüsselbrett mit 3 Probes und ich möchte, dass die LEDs anzeigen ob der iButton erkannt wurde. Geht natürlich nicht weil man nicht weiß auf welchen Port der steckt...

Aber mal eine andere Idee, ich hab die Schlüsselanhänger-Variante mit den Magneten (Was übrigens als Schlüsselanhänger ziemlich schei**e ist wenn man sein Schlüssel neben die Geldbörse packt wo auch die ganzen Magnetkarten drin sind) und man könnte doch mit einem kleinen Reed Kontakt hinter dem Probe erkennen wo gerade der iButton aufgesetzt wurde. Ich weiß nicht ob das Mechanisch geht, also ob das Magnetfeld reicht und zuverlässig schaltet aber wäre das eine Variante? Ich würde das mal testen am Wochenende, aber die Frage ist viel mehr: Kann man dann mit FHEM auswerten wenn 1-Wire I/O Pin X gesetzt und Seriennummer Y in einem Zeitfenster von 1-2s erscheint, dann steckt die Seriennummer Y auf Port X? Oder ist das Schwachsinn und in der Umsetzung zu kompliziert?

Die Idee kam mir nur eben im Flieger, aber ich wollt mal in die Runde Fragen ob das Sinn macht.

Gruß
Daniel