Der Status eines DS18B20 Sensor (von 10) zeigt immer den letzten Temperaturwert als state bzw. userreading an, obwohl der Zähler unter failures auf Probleme hinweist.
define Puffer_Vorlauf GPIO4 28-00...
attr Puffer_Vorlauf event-on-change-reading Temp1
attr Puffer_Vorlauf model DS18B20
attr Puffer_Vorlauf stateFormat {sprintf ("%.1f", ReadingsVal("$name","temperature",0))."°C"}
attr Puffer_Vorlauf userReadings Temp1 { sprintf("%.1f", ReadingsVal("$name","temperature",0)) }
Readings:
Temp1 22.4 2014-12-10 23:53:19
failures 1468 2014-12-10 23:53:19
state T: 22.437 2014-12-07 22:28:55
temperature 22.437 2014-12-07 22:28:55
Mit dem userReading sollte doch eigentlich 0 als Wert von Temp1 ausgegeben werden ,wenn kein Wert gefunden wird - also doch auch bei einem Fehler??
Gruß
Karlheinz
das müssen nicht unbedingt echte Fehler sein , lies mal unter http://forum.fhem.de/index.php/topic,24176.0.html meinen Beitrag vom 26. Juli
Hallo Wzut,
in dem erwähnten Beitrag sprichst du von sporadischen Fehlern. In meinem Fall wird der Sensor leider auch nicht mehr vom Betriebssystem (ls /sys/bus/w1/devices) erkannt. Trotzdem wird die Temperatur seit dem letzten Neustart v. 7.12.14 22:28 angezeigt.
Wie kann auch im Status, bzw. in Temp1 der Fehler angezeigt werden?
ah , ok - dann teste doch mal die angehängte Version , so nutze ich z.Z. das GPIO4 Modul.
Beim Starten wird nun Temperatur u. Zeit angezeigt:
s. Anhang
Nach einigen Minuten verschwindet die Uhrzeit neben der Temperatur.
es kommt die Meldung:
Use of uninitialized value in numeric gt (>) at ./FHEM/58_GPIO4.pm line 148, <DATA> line 2.
Use of uninitialized value in numeric lt (<) at ./FHEM/58_GPIO4.pm line 149, <DATA> line 2.
Bei nicht angeschlossenen Sensoren sieht das nun gut aus:
Temp1 0.0
state Error
Bei nicht funktionierenden Sensoren sieht das immer noch so aus:
Temp1 18.9 2014-12-12 17:59:28
failures 3930 2014-12-12 17:27:10
state Error 2014-12-12 17:59:28
temperature 18.875 2014-12-12 17:22:06
Bei funktionierende Sensoren hat sich auch etwas geändert:
state T: 35.7 °C ▴ | 17:41
Die Temperaturen werden nun mit nur einer Nachkommastelle angezeigt (find ich gut), aber mit Zeichensalat daneben.
Zitat von: optimizer am 12 Dezember 2014, 18:18:27
Bei nicht funktionierenden Sensoren sieht das immer noch so aus:
state Error 2014-12-12 17:59:28
## snipp ###
aber mit Zeichensalat daneben.
a. na da hast doch deinen Fehler im state das wolltest du doch
b. das ist kein Zeichensalat sondern ein kleines Dreieck mit der Spitze nach oben oder unten - damit hatte ich mir eine Trendanzeige gebastelt ->
Spitze nach oben : Temp ist gestiegen seit der letzter Messung
Spitze nach unten : Temp ist gefallen
ganz ohne : Temperatur ist gleich geblieben
Aber wenn dich das stört : stateFormat ist dein Freund :) bzw. da du ja auch Developer Status hast müsste es für dich ja ein leichtes sein selbst Hand anzulegen an den paar Zeilen Perl ....
Newbie als Developer ? Und dann gleich von "Zeichensalat" schreiben ?
Nu ja. Wird sich wohl jemand etwas dabei gedacht haben.
Mein Tipp: http://books.google.de/books/about/Taschenbuch_Multimedia.html?hl=de&id=9PLa46wiYV8C, darin findet man eine ganze Menge über Unicode.
pah
Ja, heutzutage bekommt wirklich jeder einen Developer Titel.
@Wzut
Deine Änderungen sind genau das was ich wollte und sogar noch mehr mit der Zeichensalat-Idee. ;) - Danke!
Allerdings hatte ich nicht verstanden, wieso bei einem Sensor das "failures"-Readings nicht mehr vorhanden ist und ein UserReading noch einen Wert von 18.9 anzeigt.
Ich hoffe Feedback ist weiterhin erwünscht.
Zitat von: optimizer am 13 Dezember 2014, 00:50:44
wieso bei einem Sensor das "failures"-Readings nicht mehr vorhanden ist und ein UserReading noch einen Wert von 18.9 anzeigt.
OK, das Reading "failures" habe ich sterben lassen und durch ein Internals ERRORCOUNT ersetzt. Deine angezeigten "failures" sind somit Leichen, d.h. du sollst mal für jeden Sensor ein "deletereading <name> failures" in der Kommzeile eingeben um die endgültig los zu werden. Zu ERRORCOUNT :
Jedesmal wenn eine Temperatur nicht gelesen werden konnte wird er um eins erhöht, sind 6 Fehler erreicht wird der Abfrageintervall auf 9999 hochgesetzt.
Sind diese 9999 Sekunden abgelaufen wird wieder versucht zu lesen, klappt es -> 0 im ERRORCOUNT und altes Intervall , wenn nicht werden wieder 9999 Sekunden bis zum nächsten Versuch gewartet. Der State wechselt zwar auf Error aber in den Readings steht natürlich noch die letzte erfolgreich ermittelte Temperatur inklusive dem Zeitstempel, so kann man schön beurteilen seit wann denn der Fehler besteht.
Allgemein noch etwas zu dieser (meiner) Modulversion : Ich hatte in einem Projekt einen Raspi verbaut und kam nachträglich auf die Idee noch schnell zwei Temperaturwerte zu wollen. Da die beiden daür notwendigen Meßsteilen nur 50 bzw 100cm vom Raspi entfernt lagen fand ich es etwas übertrieben dafür einen echten USB 1W Busmaster zu verbauen. Die zwei DS1820 plus der 4,7k Widerstand waren relativ schnell verbaut. Als erstes sind mir dann die oben genannten Fehler aufgefallen, später kamen noch pro Tag zwei bis drei unerklärliche 85° Werte dazu. Da das Modul wohl eh nicht mehr weiterentwickelt wird dachte ich schreibst es eben für dich selbst so um wie es mir am besten gefällt. U.a. halt ein Grund für das heutige etwas ungewöhnliche state Format. Das mit den 85° Messungen stellte sich aber nachher nicht als Fehler des Moduls oder des Kerneltreibers herraus sondern als ein defekter DS1820, denn irgendwann zeigte er nur noch 85° ( den entsprechenden Abschnitt im Modul dazu hatte ich aber nie entfernt. Bei einer offiziellen svn Version hätte ich natürlich auch mehr mit attr gearbeitet um dem User mehr Freihet bei der Anzeige zu lassen ohne ihm mit Gewalt meinen Willen aufzudrücken.
Hallo Wzut,
Danke für die ausführliche Erklärung.
Die 85° (Fehler-)Werte konnte ich durch ein besseres Kabel in der Hauptleitung (Cat5 anstatt Telefonleitung) reduzieren. Warum der 11. Sensor nicht mit allen anderen funktioniert ist mir noch ein Rätsel.
Wieso betreust du das Modul nicht einfach weiter? Meine Stimme hast du.
Zitat von: optimizer am 13 Dezember 2014, 21:37:36
Wieso betreust du das Modul nicht einfach weiter? Meine Stimme hast du.
benötigt denn ein Modul das lediglich
einen Wert aus
einer Datei ausliest wirklich so viel Intensivpflege ?
außerdem gibt es bestimmt nicht allzuviele User die es aktiv nutzen u.A. wäre dein Problem mit dem einen Sensor durch einem echten Busmaster und 5V auf dem Bus (statt der 3,3 vom Raspi) vieleicht auch gelöst ? und IMHO werden hier keine Wahlen abgehalten .... :)
Es ist reichlich sinnfrei, einen 1-Wire Bus im Grenzbereich zu betreiben und sich dann über angebliche Fehler zu mokieren. Die Kosten für einen 1-Wire-Busmaster sind deutlich geringer, als der Differenzpreis zwischen ein paar Metern Netzwerkkabel der Kategorie 5 und einer Telefonleitung. Damit wären die Lesefehler auf dem Bus nicht nur "reduziert", sondern weg.
pah
Hmm, meine DS1820 Sensoren hängen an einem DS2482 I²C Busmaster (http://wiki.volkszaehler.org/hardware/controllers/raspberry_pi_erweiterung_mit_schaltausgaengen) mit 5V incl. 4,8k Widerstand. Für den Anschluss verwende ich 6xISDN-Verteiler von Pollin (ohne Abschlusswiderstand). An die Sensoren habe ich ein ISDN Telefonkabel angelötet - so bin ich sehr flexibel. Trotzdem gibt es noch Übertragungsprobleme.
... und Netzwerkkabel habe ich auch noch übrig.
Na, was denn nun ?
GPIO oder DS2482 ?
Das hier beachtet http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie ?
Das hier beachtet http://www.hobbytronics.co.uk/raspberry-pi-i2c-clock-stretching , https://github.com/raspberrypi/linux/issues/254 ?
LG
pah
ZitatNa, was denn nun ? GPIO oder DS2482 ?
Das ist bestimmt eine Fangfrage, nach meinem letzten Post :-[
Meine Baumverkabelung entspricht sicher nicht der Norm. Der Vorschlag mit dem Rückkanal pro Sensor wäre wohl noch die Rettung. Dazu müsste ich alle Sensoren und den Verteiler etwas modifizieren. Als ich mit der Verkabelung begann, hab ich das Wiki (http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie) leider nicht gefunden.
Gruß
Karlheinz
Nö, keine Fangfrage.
Aber "Nichtfinden des Wiki" ist schon peinlich ;D
pah
Zitat von: Prof. Dr. Peter Henning am 16 Dezember 2014, 19:36:20
Nö, keine Fangfrage.
denke ich auch , sorry aber die ganze Fragerei plus des Screenshots sind eindeutig GPIO4 und dann postet du einen Link zu einem DS2482 - I2C Busmaster, das passt irgendwie nicht zusammen.
EDIT : oder Moment ... benutzt du vllt. das Programm https://github.com/w3llschmidt/1wirevz/blob/master/1wirevz.c ?
denn da habe ich gerade gefunden :
for (i=1; i<=count_i2cdevices(); i++) {
sprintf ( fn, "/sys/bus/w1/devices/w1_bus_master%d/w1_master_slaves", i );d.h. das Stück Software liest die Werte via I²C und schreibt sie in die gleichen Dateien wie das Kernelmodul für 1W ?
@ PAH
ZitatAber "Nichtfinden des Wiki" ist schon peinlich ;D
Man findet nur einen Wiki-Artikel in FHEM wenn man auch danach sucht ;D
@Wzut
Ganz genau, das Add-on Board wird nach dieser Anleitung (https://github.com/w3llschmidt/1wirevz)installiert und die Sensoren erscheinen alle im Filesystem. Deshalb verwende ich ja auch "dein" Modul. Wie das sonst aussehen soll, weiss ich nicht - deshalb dachte ich an "Fangfrage". Gibt es noch eine bessere Möglichkeit zum Auslesen der Sensoren?
Meine Temperatursensoren habe ich jetzt etwas umgebaut: Der Rückkanal der ersten Sensors ist nun der Hinkanal für den zweiten usw. . Aber es läuft noch nicht rund.
Jetzt habe ich folgende Situation:
- Im Filesystem werden sechs Sensoren angezeigt - in FHEM bekomme ich nur drei, die anderen laufen auf "error".
- Zu dem Problem mit max. 10 Sensoren habe ich noch folgendes gefunden: In der Datei "w1_master_max_slave_count" steht 10. Den Wert kann ich aber nicht ändern.
Habt ihr noch einen Tipp?
Gruß
Karlheinz