DS18B20 zeigt nach Fhem Neustart negative Temperatur

Begonnen von dbox2user, 24 März 2017, 09:11:49

Vorheriges Thema - Nächstes Thema

dbox2user

Hallo!

Bisher konnte ich im Forum darüber noch nichts lesen, deshalb öffne ich mal einen neuen Thread.  ::)

Bisher habe ich einige DS18B20 Temperatursensoren über ein Pollin-AVR-Board angeschlossen und lese sie darüber aus.
Nachdem das AVR-Board langsam das Zeitliche segnet, will ich die Sensoren über einen Arduino-Uno mit Ethernetshield und configurable Firmata auslesen.
Der Uno läuft schon seit längerem sauber als Test an (inkl. Relais und digitalen Eingängen).
Bisher ist testweise nur ein DS18B20 angeschlossen. 
Dafür benutze ich die in den offiziellen Fhem-Updates bereitgestellten Module "OWX" und "OWTHERM".

Der Sensor läuft tadellos, bis auf folgendes:



Wenn ich den Fhem Server neu starte , bringt der Sensor beim ersten einlesen einen negativen Wert ( z.B. -0.06 °C).
Beim nächsten einlesen zeigt er dann den richtigen Wert (z.B. 20.3 °C) an und läuft ab da richtig.




Wenn ich meine vorhanden Sensoren so umziehe, versauen mir bei Neustarts die Ausreißer ins Negative natürlich meine Plots.

Ist das Problem bei Fhem Neustarts in dieser Konstelation bekannt, bzw gibt es schon eine Lösung?

Anbei noch ein "list" des Sensors nach dem Fhem Neustart:

Internals:
   ALARM      1
   ASYNC      1
   DEF        DS18B20 035C01000080
   ERRCOUNT   0
   INTERVAL   300
   IODev      Ardu_Heizung_1wire
   NAME       OWX_28_035C01000080
   NOTIFYDEV  global
   NR         893
   NTFY_ORDER 50-OWX_28_035C01000080
   NUMTASKS   0
   OW_FAMILY  28
   OW_ID      035C01000080
   PRESENT    1
   ROM_ID     28.035C01000080.F0
   STATE      -0.1°C
   TYPE       OWTHERM
   owg_temp   -0.0625
   owg_th     -127
   owg_tl     -127
   Readings:
     2017-03-24 08:21:39   alarm           1
     2017-03-24 08:24:16   present         1
     2017-03-24 08:24:19   state           T: -0.06 °C ↑
     2017-03-24 08:24:19   temperature     -0.0625
   Tempf:
     factor     1
     offset     0
Attributes:
   IODev      Ardu_Heizung_1wire
   model      DS18B20
   room       OWX
   stateFormat {sprintf("%.1f",ReadingsVal("$name","temperature",0))."°C"}
   tempHigh   -127
   tempLow    -127


Danke schonmal!

Gruß,
Christian
Fhem 5.8 auf Raspberry Pi2; 1 Wire OWSERVER mit DS9490R und OWX DS2480;AVR-NET-IO mit 1Wire;  LOGO8; Kostalpiko; Selbstbau CUL; Arduino mit cFirmata; Denon AVR; Samsung TV; Fritzbox;

Prof. Dr. Peter Henning

Welche Version von OWTHERM ?

Wieso muss FHEM neu gestartet werden ?

LG

pah

Frank_Huber

Ich würde mal vermuten dass beim ersten einlesen das IOdev noch nicht erreichbar ist.

Wozu FHEM Neu starten? der kann 24/7 laufen...

dbox2user

Hallo!

Die verwendeten 1-Wire Module sind die aktuellsten, die in den Fhem-Updates angeboten werden.
Die OWTHERM Version ist folgende:        "Id: 21_OWTHERM.pm 13642 2017-03-08 16:41:55Z phenning"

24/7 Betrieb:
Nachdem ich mein Fhem-System auf einem aktuellen Stand halten möchte, um neue Funktionen/verbesserungen und neue Module verwenden zu können, führe ich ca alle 14 Tage ein Update durch.  Nach einem Update MUSS nunmal ein Fhem-Neustart durchggeführt werden.

Falls das IOdev wirklich noch nicht erreichbar sein sollte, würde es dann Sinn manchen hier eine "Warteschleife" einzubauen? Wenn ja, wie ?
Bzw lässt sich in der Config NUR der Aufruf des 1 Wire IOdev verzögern?

Gruß,
Christian

Fhem 5.8 auf Raspberry Pi2; 1 Wire OWSERVER mit DS9490R und OWX DS2480;AVR-NET-IO mit 1Wire;  LOGO8; Kostalpiko; Selbstbau CUL; Arduino mit cFirmata; Denon AVR; Samsung TV; Fritzbox;

Frank_Huber

was für ein IO device hast Du denn?
Dieses sollte auf jeden Fall VOR dem Temperatursensor geladen werden.
wenn Du das IOdev nochb verzögerst machst das nur noch schlimmer.

prüfe doch mal welche ID dein Sensor und welche das IO device hat. (--> Internals "NR")
eventuell wird ja der sensor vor dem IOdev geladen?

dbox2user

Als 1 Wire IO-dev verwende ich die Pins eines Arduino Uno, der per configurable Firmata an Ethernet angeschlossen ist.

Zuerst wird die Firmata selbst geladen ("FRM"-Modul -- ID-Nr 823) ,
dann der 1 Wire Master ("OWX_ASYNC"-Modul -- ID-Nr 839)
und als letztes der Sensor ("OWTHERM"-Modul -- ID-Nr 893)

Die Reihenfolge sollte also stimmen.

Wegen der Verzögerung ... da hatte ich mich etwas unklar ausgedrückt.
Ich meinte eine Verzögerung zwischen dem "FRM" und dem "OWX_ASYNC". Danach dann noch eine Verzögerung zwischen "OWX_ASYNC" und "OWTHERM".... damit das jeweils benötigte Device auch sicher erreichbar ist.

Würde das Sinn machen? Wenn ja, wie?

Gruß,
Christian
Fhem 5.8 auf Raspberry Pi2; 1 Wire OWSERVER mit DS9490R und OWX DS2480;AVR-NET-IO mit 1Wire;  LOGO8; Kostalpiko; Selbstbau CUL; Arduino mit cFirmata; Denon AVR; Samsung TV; Fritzbox;