[wiregate] Messwert 85°C pauschal als Fehler interpretiert?

[Hauke]

Da in den letzten Tagen die Sonne ganz anständig schien, kommt mein Speicher so langsam auf Temperatur
Allerdings weisen die Kurven der angebrachten Sensoren heute seltsame Lücken auf, interessanterweise exakt dort, wo man vermuten könnte, das 85°C erreicht wurden. Bis 84,5 sieht alles gut aus. Oberhalb von 85° ist vermutlich nicht erreicht worden.

Daher die Frage:
Werden die 85°C (die ja PowerOn-Wert der Sensoren sind) generell als Fehlmessung "aussortiert" und nicht ans rrd weitergegeben? Kann man prinzipiell gemessene 85°C vom PowerOn-Wert unterscheiden?

[StefanW]

Werden die 85°C (die ja PowerOn-Wert der Sensoren sind) generell als Fehlmessung "aussortiert" und nicht ans rrd weitergegeben?

Gute Frage. Das müssten wir mal im Code nachprüfen.

Kann man prinzipiell gemessene 85°C vom PowerOn-Wert unterscheiden?

Theoretisch Nein, praktisch wohl ja.

Überlegung: Bei maximaler Auflösung mit 12 Bit müsste diese gemessene Temperatur exakt 85,0000 °C (auf vier Stellen hinter dem Koma mit Null) entsprechen um dem POR-Wert zu entsprechen. Nur ein Bit mehr oder weniger (bei 12 Bit) macht schon einen Unterschied von 0,0625 K (1/16 K) aus. Und im POR-Fall kommt der Sensor mit 12 Bit hoch.

Ansich sollte es unwahrscheinlich sein, dass Dein Speicher diese Temperatur von 85,0000 °C auf 3/100 K (genau 1/32 K, die Hälfte der höchsten Auflösung) genau über mehrere Minuten und mehrere Messzyklen hält, so dass die Filterung als "Fehler" greifen sollte.

Zudem könnte man noch durch mitführen eines gleitenden Mittelwertes prüfen, ob es nicht eine allmähliche Annäherung an die 85,0000 °C gegeben hat, so dass diese Messung plausibel wäre.

Wie oben schon erwähnt, dass müssen wir im Code genau nachsehen.


lg

Stefan

[Hauke]

Überlegung: Bei maximaler Auflösung mit 12 Bit müsste diese gemessene Temperatur exakt 85,0000 °C (auf vier Stellen hinter dem Koma mit Null)

Hmm. Ich habe (glaube aufgrund Empfehlung von euch irgendwo) bei den Sensoren wo ich keine so hohe Auflösung benötige die Auflösung entsprechend runtergedreht, in diesem Fall 9 (?) Bit. 0,5K reichen mir hier aus.

Und im POR-Fall kommt der Sensor mit 12 Bit hoch.

Vielleicht geht darüber auch was. Ich hab ja keine 12 Bit eingestellt, also kann es - wenn er mit weniger als 12 Bit kommt - definitiv kein POR sein.
Was ich eigentlich meinte: Ein separates Bit "Messung durchgeführt und validiert" oder so das man mit auslesen kann gibt es anscheinend nicht?

Zudem könnte man noch durch mitführen eines gleitenden Mittelwertes prüfen, ob es nicht eine allmähliche Annäherung an die 85,0000 °C gegeben hat, so dass diese Messung plausibel wäre.

Hört sich für mich erstmal relativ aufwändig an. Ich glaub' das muss einfacher gehen...

[StefanW]

Was ich eigentlich meinte: Ein separates Bit "Messung durchgeführt und validiert" oder so das man mit auslesen kann gibt es anscheinend nicht?

Ich fürchte das gibt es nicht, aber sollte es geben. Ich wünsche mir auch eine Fehlermeldung per eMail bzw. auf eine GA bei Ausfall Sensor / Busmaster usw.

lg

Stefan

[Hauke]

Hallo Stefan,

gibt's bei dem Thema schon was neues? Ich kann inzwischen bestätigen, dass oberhalb 85°C wieder Werte kommen. Sieht tatsächlich so aus, als würden die 85° pauschal weggefiltert.

[JuMi2006]

Die Messwerte von exakt 85°C werden lt. Code tatsächlich ausgeblendet bzw. als Fehler gemeldet. Auf die schnelle konnte ich kein "PowerOnReset" via owfs/owhttp finden ... auch google schwieg sich ein wenig aus.
Sollte der Status tatsächlich auslesen lassen wäre das eine Codezeile im Script. Dazu muss aber das WireGate-Team was sagen.

Erster Workaround wäre wirklich, wie StefanW schon schrieb, einfach die Auflösung der entsprechenden Sensoren zu erhöhen und damit die Wahrscheinlichkeit von genau 85.000°C zu minimieren.

Grüße

[Hauke]

Ja, das ginge natürlich. Aber die Auflösung ist ja nicht ganz ohne Grund so wie sie ist. Wenn PowerOnValue immer 12 Bit ist, könnte man dann nicht evtl. die 85°C nur dann ausblenden, wenn sie mit 12 Bit kommen?

Einstellung der Auflösung des Sensors, je mehr Bit desto genauer jedoch auch langsamer (Standardwert: 10 Bit / vgl. Zeiten und Tabelle).(Nur DS18B20, bei DS18S20 ist die Auflösung fix 12 Bit)

12 Bit (0.0625°C, 750ms)
11 Bit (0.125°C, 375ms)
10 Bit (0.25°C, 187.5ms)
9 Bit (0.5°C, 93.75ms)

[JuMi2006]

AW: Messwert 85°C pauschal als Fehler interpretiert?

Ich weiß nicht wie sich der Sensor im Fehlerfall meldet, glaube aber dass er sich dann als powered meldet. Kannst Du dazu was sagen Stefan?
Im Falle von 85℃ könnte man so zusätzlich diesen Status abfragen und auswerten.
Oder eben bei 12Bit die "Fehlermeldung" ignorieren -> noch einfacher.

Baustelle 2.0

[wuestenfuchs]

Werden die "85 °C" eigentlich nur im Wiregate-Webinterface ausgegeben oder auch an Plugins, auf den Bus, ... weitergegeben?

Ich hatte ursprünglich ein Plugin angedacht, das gewissermaßen als "Temperatur-Brandmeldeanlage" fungiert, d.h. alle Werte über 65 °C lösen gewisse Alarmhandlungen aus. Nachdem in jedem Raum ohnehin mindestens ein 1-Wire Temperatursensor vorhanden ist, wäre das doch nur konsequent weitergedacht. Allerdings würden die Sache mit den 85 °C - je nach Busstabilität - durchaus mal Falschalarme generieren.

Könnte man nicht in allen Fällen einfach den Wert von 85 °C ausblenden? Oder zumindest im Webinterface mit einer Fehlermeldung ersetzen? Denn ein falscher Wert ist manchmal schlimmer als gar kein Wert - siehe obiges Beispiel.

[StefanW]

Werden die "85 °C" eigentlich nur im Wiregate-Webinterface ausgegeben oder auch an Plugins, auf den Bus, ... weitergegeben?

Muss ich klären. Meiner Errinerung nach, wird es in den RRDs usw. ausgeblendet. Hinsichtlich der Plugins usw. muss ich mich erkundigen, gehört meiner Meinung nach ebenfalls ausgeblendet.

Auch in der Sensoren Anzeige gehört eine Fehlermeldung und kein 85 °C Wert, ist viel zu erklärungsbedürftig.


lg

Stefan

[Hauke]

Ich hatte ursprünglich ein Plugin angedacht, das gewissermaßen als "Temperatur-Brandmeldeanlage" fungiert, d.h. alle Werte über 65 °C lösen gewisse Alarmhandlungen aus.

Dann mach' doch einfach ">85°C", die erreichst du definitiv auch wenn es brennt... Ich behaupte mal die Zeit zwischen >65 und >85 dürfte im Falle eines Feuers nicht wirklich lang sein...

Könnte man nicht in allen Fällen einfach den Wert von 85 °C ausblenden?

Wenn ein Sensor in einer Umgebung von 85°C verbaut ist, würde ich nach wie vor die Temperatur auch gerne messen können.

[wuestenfuchs]

Wenn ein Sensor in einer Umgebung von 85°C verbaut ist, würde ich nach wie vor die Temperatur auch gerne messen können.

In der Praxis dürfte das keine wesentliche Rolle spielen, denn es geht - je nach Auflösung, um exakt 85 °C (also 85,0 bis IIRC 85,0000 °C). 85,005 und 79,995 Grad werden beispielsweise wieder korrekt angezeigt.

Selbst wenn du wirklich eine Umgebung mit exakt 85 Grad hättest, würde der Sensor aufgrund von Messungenauigkeiten ständig um diesen Bereich herum pendeln - im Fall des DS1820 im Bereich zwischen 79,5 und 80,5 Grad (+- 0,5 Grad Messtoleranz). Tatsächlich gemessene 85,000 Grad wirst du also nicht haben, bei entsprechender Auflösung zumindest nicht über eine relevante Dauer hinweg.

[StefanW]

Sehr richtig.

Die Auflösung wird bei Power-On-Reset auf 12 Bit geschaltet, die 85 °C entsprechen damit den 85,0000 °C und das darf man getrost ausblenden.

Wenn man ganz vorsichtig sein will, könnte man dann auch noch eine zweite Messung vornehmen. Zudem könnte man mit der Historie vergleichen, ob es eine allmähliche Annäherung an die 85 °C gab oder einen Sprung.

lg

Stefan

[Hauke]

Nun ja, das Problem ist, dass die Sensoren ja nicht zwingend auf 12 Bit Auflösung geschaltet sind.
Wie von mir weiter oben bereits zitiert, sind in der Hilfe die Zeiten, die zur Abfrage benötigt werden, angegeben. Grundsätzlich reichen mir 0,5°C Auflösung aus, und wenn 12 Bit fast um Faktor 10 langsamer sind (bei einer Handvoll Sensoren sprechen wir hier immerhin über 5-10 Sekunden allein für die Abfrage der Temperaturen, während der - wenn ich das richtig verstehe - auch keine Plugins ausgeführt werden können) fahre ich lieber nur mit der minimal benötigten Auflösung. Und da kommen exakt 85°C nun mal leider durchaus vor.
Ich würde daher eine Lösung favorisieren - sofern technisch umsetzbar - die exakt 85°C mit 9, 10 oder 11 Bit nicht wegfiltert. Auf die 85,000 mit 12 Bit Auflösung kann ich verzichten. Die Sensoren sind halt recht exakt und "pendeln" nicht unbedingt stark rauf und runter. Mit 9 Bit bekomme ich teilweise über Stunden hinweg exakt 85°C.

BTW: Verhält sich der neue Professional Busmaster in diesem Punkt genauso?

[StefanW]

Hmm, das scheint ein schwieriges Thema zu sein. Weil es von jedem neu und falsch aufgefasst wird, hab ich das so falsch erklärt?

Ok, hier der ultimative Erklärungsversuch zu dem Thema "Power-On-Reset" und "Parasitär" der DS18B20 Sensoren:

1. Zwei Betriebsmodi: Die Sensoren DS18B20 (und teils auch deren Derivate, bitte jeweiliges Datenblatt lesen) verfügen über zwei Betriebsmodi: "Powered" und "Parasitär".
2. Modi "Powered": Hier erfolgt die Spannungsversorgung über den separaten 5 V Anschluss.
3. Modi "Parasitär": Die Spannungsversorgung soll aus dem Datensignal erfolgen. Das macht mehrere weitere Schritte notwendig. Zunächst muss der Sensor in diesen Modus geschaltet werden. Das erfolgt dadurch, dass der Anschluss VDD (also der 5 V Anschluss) mit dem Anschluss GND verbunden wird (also eine Kurzschlussbrücke zwischen dem Anschluss VDD und dem Anschluss GND des Senbsors.).
   Hinweis: Diese Brücke soll nur sensorseitig angewendet werden und nicht die Anschlüsse des Busmasters miteinbeziehen (ihr werdet es nicht glauben, aber ein Viertel der Kunden hat schon den Busmaster zwischen 5 V und GND kurzgeschlossen).
4. Auslesen des Modi durch Software: Der Sensor teilt in einem seiner Register mit, ob er "Powered" ist, oder nicht (was dann "Parasitär") bedeutet.
5. Ansteuerung durch die Software: Insofern sich ein Sensor als "parasitär" (genau genommen, als "nicht-powered") meldet, muss die Software dies berücksichtigen und den Sensor nach dem Befehl "Convert-T" (das bedeutet: "Miss die Temperatur und wandle diese in ein digitales Format") dadurch mit Spannung versorgen, indem der Busmaster von der Software so gesteuert wird, dass das Datensignal während der Dauer der Konvertierung auf dauerhaft 5 V gehalten wird, d.h. es findet während dieser Zeit keine Datenübertragung statt. Hinweis: Es gibt Software, die diesen Modus "Parasitär" nicht unterstützt, z.B. IPS.
6. Fortsetzung der Datenübertragung: Erst nach erfolgter Wandelung, die je nach gewünschter Auflösung (9 bis 12 Bit) zwischen 63 ms und 750 ms dauert, kann wieder eine Datenübertragung - egal wohin erfolgen. Jede andere Kommunikation muss in dieser Zeit warten.
7. "Power-On-Reset" bei fehlerhafter Konfiguration des Sensors: Wird nun die unter 3. erklärte Brücke zur Konfiguration des Sensors nicht gesetzt (also z.B. offen gelassen) bzw. VDD nicht angeschlossen (was das gleiche bedeutet), dann wähnt sich der Sensor im Modus "Powered". Da die Software den Sensor dann auch "powered" ansteuert, unterbleibt das hochhalten des Datensignals (es gibt noch andere Tricks wie Strong Pullup, dies ist hier zur Vereinfachung nicht beschrieben). Das Ergebnis ist, dass dem Sensor schlicht die Betriebsspannung ausgeht, weil zum einen dessen lokaler Kondensator nur einige Dutzend Millisekunden überbrücken kann und zum anderen die AD-Wandlung deutlich stromintensiver ist. Deshalb "rebootet" der Sensor mangels Strom.
8. Kennzeichen des "Power-On-Reset": Nach dem Power-On-Reset ("POR") stehen die Register in einer Grundstellung. Zum einen ist der Sensor auf maximale Auflösung mit 12 Bit konfiguriert, zum anderen steht im Temeratur-Conversion-Register dann ein Bitmuster, dass dem Wert 85,0000 °C entspricht. Der Sensor hat somit nichts gemessen, weil ihm die Spannungsversorgung ausgegangen ist und nur Default-Werte in den Registern stehen. Es ist Aufgabe der Software, damit richtig umzugehen.

Welche Produkte betrifft dies?: Alle diejenigen, bei welchen der Sensor ohne weitere begleitende Elektronik eingebaut ist, also Hülsen-Fühler, Anlegefühler und der alte Multisensor V 1.3.

Welche Produkte betrifft das nicht?: Alle etwas komplexeren Produkte wie Multisensoren, Temperatursensor auf Platine, Umgebungslicht-Multisensoren usw. bei der B- und Z-Serie sowie bei allen künftigen Serien. Bei diesen neuen Produkten wird - auch bei parasitärem Anschluss der Platine - der Sensor powered betrieben (durch eine entsprechende Schaltung). Es braucht auch keine Brücke. Wir nennen das "Parasitär Typ 2". Damit entfällt diese Fehlerart und eine spezielle Ansteuerung durch die Software ist nicht mehr nötig, so dass auch Kunden mit IPS diese neuen Sensoren mit parasitärem Anschluss nutzen können.


Zusammenfassung:

• Die Anzeige 85.0000 °C in Verbindung mit einer Auflösung von 12 Bit ist mit an Sicherheit grenzender Wahrscheinlichkeit der Default-Wert nach einem Neustart - entstehend durch den Power-On-Reset. Ganz insbesondere dann, wenn der Kunde keine 12 Bit eingestellt hat (weil 9 Bit oder maximal 10 Bit i.d.R. für die meisten Zwecke ausreichend sind). Wenn diese drei Bedingungen geprüft werden, kann der Fall "POR" sicher detektiert werden.
• Ein POR ensteht zum einen bei der Inbetriebnahme bzw. jeweiligen Spannungsanschaltung des Busses oder eben als Folge eines "Absturzes" durch mangelnde Stromversorgung - fast immer bedingt durch Verkabelungsfehler. Entweder die VDD ist nicht angeschlossen oder die sensorseitige Kurzschlussbrücke zu GND fehlt.
• Dieses Verhalten ist das des Sensors und hängt nicht vom Busmaster ab bzw. kann nicht vom Busmaster gebessert werden. Allerdings muss die Software den Busmaster bei einem parasitären Sensor korrekt ansteuern, dass während der Konversionszeit das Data-Signal auf High-Pegel bleibt.
• Bei Auftreten dieses Fehlers ist immer die Verkabelung des jeweiligen Sensors zu prüfen.
• Dieser Fehler betrifft nur die Hülsenfühler nebst Derivaten, den Deckentemperaturfühler sowie die Einschraub- und Kanaltemperaturfühler in der Version 1, sowie den Multisensor 1.3. Alle neueren Produkte haben eine lokale Automatikschaltung welches dieses Problem vermeidet und auch keine Brücken mehr erforderlich macht.

==> Wir können diesen Fall also gut erkennen und werden das in künftiger Software entsprechend berücksichtigen.

Alles klar?

lg

Stefan