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
Welche Version von OWTHERM ?
Wieso muss FHEM neu gestartet werden ?
LG
pah
Ich würde mal vermuten dass beim ersten einlesen das IOdev noch nicht erreichbar ist.
Wozu FHEM Neu starten? der kann 24/7 laufen...
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
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?
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