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 ...
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
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 ...
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...
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
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):
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 }
ZitatOk, 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
Zitat von: Prof. Dr. Peter Henning am 27 September 2016, 08:36:56Fast. 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 ;)
Zitat von: Prof. Dr. Peter Henning am 27 September 2016, 08:36:56Zur 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...
Muss man wohl mal die OWDevice-Maintainer fragen, nicht meine Baustelle. In OWTHERM ist es jedenfalls korrekt...
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 September 2016, 12:21:06Muss man wohl mal die OWDevice-Maintainer fragen ...
... wer ist denn das? Kann ja nicht schaden, da mal anzuklopfen ...
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