OWserver: DS18B20 Kalibrierung, ALARM-Reset

[M_I_B]

Sehe ich das richtig, das bei Verwendung von OWserver die Kalibrierung der einzelnen DS18B20 Sensoren direkt in OWserver passiert und nicht mehr mit Angabe eines Offset in FHEM selber? Denn dieses Attribut gibt es ja hier nicht mehr... Ich meine das irgendwo innerhalb des OWweb gesehen zu haben. Da stand irgendwas von Calib oder so und ein 5stelliger Wert... Ich finde es jetzt aber irgendwie auch nach ewigem Durchklicken nicht mehr wieder 

Ein weiteres Fragezeichen besteht in Sachen ALARM. Ich habe für alle Sensoren H/L auf 80/20 gesetzt. Der bereits gesetzte Alarm geht aber nicht auf 0 zurück (soll er wohl auch nicht von alleine, denke ich). Nur wie setzt man den manuell zurück? Ist mir im Moment ein Rätsel ...

[Prof. Dr. Peter Henning]

1. Kommt darauf an, ob man OWServer zusammen mit OWTHERM oder OWDevice verwendet.

2. Natürlich sollte der Alarm in der Software zurückgesetzt werden - im Sensor ist das ja auch so.

LG

pah

[M_I_B]

zu 1:
Ich muss gestehen, das ich durch diese ganzen OWblablub noch nicht ganz durchgestiegen bin. Daher kann es also sein, das ich was missverstanden habe; bitte berücksichtigen.
Also... auf einem RPi ist der OWserver installiert so wie FHEM. In FHEM auf diesem RPi sind halt die Devices der einzelnen Sensoren definiert like ...

Code Auswählen Erweitern

define OWS OWServer localhost:4304
attr OWS nonblocking 1

define 1W01 OWDevice 28.FFC3C8551603 10
attr 1W01 IODev OWS
attr 1W01 event-on-change-reading temperature,alarm
attr 1W01 model DS18B20
attr 1W01 resolution 12
attr 1W01 uncached 0
attr 1W01 userReadings cali { ReadingsVal("1W01", "temperature", "0") + 0.1250 }, temp { int ( 100 * ReadingsVal("1W01","cali",0) + 0.05 ) / 100 }

define 1W02 OWDevice ... e.t.c.
...
define 1W10 OWDevice ... e.t.c.
Wie zu erkennen habe ich die Kalibrierung erst mal auf anderem Weg geregelt. Dennoch wäre es mir lieber wenn ich wüsste, wie das im OWserver selbst zu machen ist, so das FHEM bereits die kalibrierten Werte geliefert bekommt.
Und mit OWdevice meinst du sicherlich die Definition in FHEM, oder?

zu 2.:
Die Antwort verstehe ich nicht. Natürlich möchte ich den im Sensor generierten Alarm durch die Software zurücksetzen. Nur das "wie" konnte ich bis dato nicht ergründen ... Und der zweite Teil dieser Antwort... Im Sensor wir hier zumindest nix zurück gesetzt...

[Prof. Dr. Peter Henning]

Zu 1. "Der OWServer" ist schon mal nicht richtig. "Server", also Software zur Ansteuerung des 1-Wire Bus, ist hier das OWFS, und "OWServer" ist das FHEM Backendmodul zur Kommunikation mit dem OWFS. "OWDevice" ist das Frontendmodul - das man aber auch durch "OWTHERM" ersetzen kann.

Zu 2. Doch ! Der Sensor hat kein Gedächtnis. Wenn die Temperatur wieder im nicht als Alarm gekennzeichneten Bereich ist, wird er bei einer Alarmsuche nicht gefunden, ist also nicht im Alarmzustand.

LG

pah

[M_I_B]

zu 1:
Ok, das habe ich jetzt verstanden... glaub ich. Also wird der unter dem OS laufende Daemon als OWFS bezeichnet, der OWserver als Backend (definiert durch "define [name] OWServer") und OWdevice resp. OWtemp als Frontend (definiert durch z.B. "define [name] OWdevice...").

zu 2:
Wenn der Sensor keinen Speicher für den Alarm hat, dann läuft hier was falsch. Denn bei mir bleibt der Alarm immer und ausnahmslos auf "1" stehen, auch wenn das "gut"- Fenster nicht verlassen wird. Derzeit sind alle 10 Sensoren innerhalb der für den Alarm gesetzten Grenzen und dennoch ist bei allen Alarm = 1. Am Beispiel des ersten Sensors guggst du (da sind noch ein paar unnütze Readings drin vom Experimentieren; muss ich noch löschen):

Code Auswählen Erweitern

Internals:
   CFGFN      ./_HW/1wire.cfg
   CHANGED
   DEF        28.FFC3C8551603 10
   IODev      OWS
   LAST_READ_FAILED 0
   NAME       1W01
   NOTIFYDEV  global
   NR         30
   NTFY_ORDER 50b-1W01
   STATE      temperature: 20.3125  alarm: 1
   TYPE       OWDevice
   Readings:
     2016-09-27 08:00:47   alarm           1
     2016-09-27 08:00:47   cali            20.4375
     2016-09-17 00:00:43   calibrated      23.8755
     2016-09-27 08:00:47   state           temperature: 20.3125  alarm: 1
     2016-09-27 08:00:47   temp            20.43
     2016-09-27 08:00:47   temperature     20.3125
     2016-09-16 09:14:53   temphigh        80
     2016-09-16 09:15:01   templow         20
   Fhem:
     address    28.FFC3C8551603
     alerting   1
     bus        bus.0
     interfaces temperature
     interval   10
     getters:
       address
       crc8
       family
       fasttemp
       id
       locator
       r_address
       r_id
       r_locator
       temperature
       temperature10
       temperature11
       temperature12
       temperature9
       temphigh
       templow
       type
     polls:
       temperature
     setters:
       temphigh
       templow
     state:
       temperature
Attributes:
   IODev      OWS
   event-on-change-reading temperature,alarm
   model      DS18B20
   resolution 12
   room       OWDevice
   uncached   0
   userReadings cali { ReadingsVal("1W01", "temperature", "0") + 0.1250 }, temp { int ( 100 * ReadingsVal("1W01","cali",0) + 0.05 ) / 100 }

[Prof. Dr. Peter Henning]

Ok, das habe ich jetzt verstanden... glaub ich. Also wird der unter dem OS laufende Daemon als OWFS bezeichnet, der OWserver als Backend (definiert durch "define [name] OWServer") und OWdevice resp. OWtemp als Frontend (definiert durch z.B. "define [name] OWdevice...").

Fast. Nicht OWtemp (das ist ein Uralt-Modul, das gar nicht mehr verwendet werden sollte), sondern OWTHERM. OWTHERM arbeitet sowohl mit dem OWServer Backend zusammen, als auch mit dem OWX-Backend. Und das OWX-Backend benötigt a.) kein OWFS und kann b.) auch mit eher wenige gebräuchlichen Interfaces wie CUNO und COC zusammenarbeiten.

Zur Alarm-Frage: Ich kann das nur in Bezug auf den Sensor sagen (siehe Datenblatt). Ob OWFS den Alarmzustand speichert, oder OWServer, oder OWDevice, kann ich nicht sagen.

LG

pah

[M_I_B]

Fast. Nicht OWtemp (das ist ein Uralt-Modul, das gar nicht mehr verwendet werden sollte), sondern OWTHERM.

... meinte ich auch; wenn man "Temperatur" im Kopf hat, machen sich die tippenden Finger schon mal selbstständig

Zur Alarm-Frage: Ich kann das nur in Bezug auf den Sensor sagen (siehe Datenblatt). Ob OWFS den Alarmzustand speichert, oder OWServer, oder OWDevice, kann ich nicht sagen.

Ok, jetzt habe ich noch mal geschaut über die GUI des OWFS...
Also... Ich kann zwar im Device die Alarmgrenzen setzen, aber die werden offensichtlich nicht an OWFS weiter gegeben. denn wenn man sich mal die einzelnen Sensoren über die GUI anschaut, dann stehen die TempHigh/TempLow- Werte immer noch wie geliefert auf 70/75. Somit ist klar, das der Alarm immer auf 1 steht...

Dann bleibt natürlich die Frage, ob das so gedacht ist, das man zwar im Device die Grenzen setzen kann, aber diese nicht an die Sensoren gegeben werden; der Sinn erschließt sich mir nicht...
... tic toc ...
Ich habe jetzt mal etwas rumprobiert... Wenn im Sensor die Werte auf 70/75 stehen (über die GUI des OWFS gelesen) und ich setze dann im Device TempHigh erneut auf 75, dann steht im Sensor plötzlich 5 bei TempHigh ?!? Wenn ich TempLow über das Device setze, passiert nix, egal welchen Wert ich setze... Is das'n BUG?
Wenn ich anders herum in der GUI des OWFS die Schwellwerte setze, dann ist alles ok. Die werden korrekt im Reading dargestellt und auch der Alarm ist aus; nur umgekehrt geht es nicht...

[Prof. Dr. Peter Henning]

Muss man wohl mal die OWDevice-Maintainer fragen, nicht meine Baustelle. In OWTHERM ist es jedenfalls korrekt...

LG

pah

[M_I_B]

Muss man wohl mal die OWDevice-Maintainer fragen ...

... wer ist denn das? Kann ja nicht schaden, da mal anzuklopfen ...

[Punkt]

Hallo,

kam gerade über die Suche zu diesem Thread - und ich habe genau das gleiche Problem...

Laut Modul sind die Maintainer Dr. Boris Neubert & Martin Fischer.
Kann man die einfach anschreiben?

Oder sollte man sie per PN auf diesen Thread aufmerksam machen?


Viele Grüße

Michael