Hallo,
ich bekomme im logfile nun ständig (alle paar Minuten) den Eintrag:
Error dewpoint: humidity invalid: 0
Definiert habe ich dewpoint mit:
define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint
attr dewpointToAllDeviceReadings max_timediff 60
define dewpointToAllDeviceStates dewpoint dewpoint .* T H D
define FileLog_Dewpoints FileLog /opt/fhem/log/DewPoints-%Y-%m.log .*.:.*dewpoint.*
Was läuft da schief (invalid) bzw. verursacht den logeintrag ?
Grüße
Jörg
Zitathumidity invalid: 0
es darf kein Reading humidity mit 0 als Inhalt geben
Hallo,
hier muss ich noch einmal einhaken. Seit einigen Tagen habe ich einen Sensor übrig und den nun im TK plaziert. Regelmäßig während der Kühlzyklen sinkt der Wert für humidity auf 0.
Ist zwar eigentlich nur Kosmetik, wäre aber trotzdem schön, wenn ich den "error" im Log unterdrücken könnte, ist ja keiner.
Ich hatte schon drüber nachgedacht, den LogLevel vom Modul etwas raufzusetzten. Leider kommt der Fehler als Loglevel 1. Ich werde mir am WE mal das Modul anschauen und versuchen am Level zu drehen oder ob ich den Auslöser unterdrückt bekomme (nicht wirklich mein Metier).
Habt Ihr noch andere Ideen?
Schöne Grüße,
John
Moin joshi04,
Die Formel zur Berechnung des Taupunktes und der absoluten Feuchte setzt vorraus dass die relative Feuchtigkeit nicht 0 % und kleiner sein darf, und eigentlich auch nicht grösser wie 100 %, dann Nebel.
In Zeile 265 wird deshalb eine Warnung ausgegeben, und die Berechnung nicht durchgeführt, da in diesen Fällen etwas mit den Feuchtesensor nicht stimmt. Natürlich kannst Du da gerne für Dich den Loglevel ändern.
Gruß Joachim
Hallo Joachim,
vielen Dank für den Schubs!
Da brache ich ja überhaupt nicht mehr groß suchen. :D
Schöne Grüße,
John
Dafür nicht,
Hast Du daran gedacht, Zeile 444 auch zu ändern, und in global exclude_from_update zu setzen?
Gruß Joachim
Hallo Joachim,
danke für den Hinweis. Ich hatte drüber nachgedacht, das Modul vom Update auszuschließen. Wenn es aber eins gibt, nehme ich das lieber mit und bekomme es über das Log mit, dass ich den Eintrag neu setzten muss. Ich weiß ja jetzt, wo es steht :).
Außerdem ist das Modul ja mittlerweile äußerst Stabil und erhält nicht alle 2 Tage ein Update, oder? ??? Und sonst weiß ich ja nun selbst dafür die richtige Zeile jetzt schon. ;D
Vielen Dank, dass Du noch an mich gedacht hast.
Dir noch ein schönes Wochenende,
John
Hi,
ich hänge mich hier mal dran, obwohl mein "Problem" vermutlich nur am Rande oder sogar gar nicht mit dem vorherigen zusammenhängt... auf Wunsch lagere ich das gerne auch nochmal in einen eigenen Thread aus.
Seit heute Nachmittag habe ich diesen Fehler auch im Log. Vorher habe ich einen CUL neu eingerichtet und vier Elro (=Intertechno) Schalter. Nach einem Neustart fingen dann diese Fehler an, im Log aufzutauchen. Nehme ich die Definitionen wieder aus der fhem.cfg heraus, gibt es augenscheinlich keine Fehlermeldungen mehr.
Folgende Definitionen sind heute neu in die fhem.cfg aufgenommen worden:
define CUL1 CUL /dev/ttyACM0 0000
attr CUL1 room Server
define CUL_TX_103 CUL_TX 103
attr CUL_TX_103 room Server
define Wohnzimmer.Verstaerker IT 0FF00F0FFF FF F0
attr Wohnzimmer.Verstaerker IODev CUL1
attr Wohnzimmer.Verstaerker model itswitch
attr Wohnzimmer.Verstaerker room Wohnzimmer
attr Wohnzimmer.Verstaerker ITrepetition 12
define Wohnzimmer.Weihnachtsbeleuchtung IT 0FF00FFF0F FF F0
attr Wohnzimmer.Weihnachtsbeleuchtung IODev CUL1
attr Wohnzimmer.Weihnachtsbeleuchtung model itswitch
attr Wohnzimmer.Weihnachtsbeleuchtung room Wohnzimmer
attr Wohnzimmer.Weihnachtsbeleuchtung ITrepetition 12
define Aussen.Beleuchtung IT 0FF00FF0FF FF F0
attr Aussen.Beleuchtung IODev CUL1
attr Aussen.Beleuchtung model itswitch
attr Aussen.Beleuchtung room Aussen
attr Aussen.Beleuchtung ITrepetition 12
define Aussen.Beleuchtung_an at *{sunset("REAL",0,"15:30","22:30")} set Aussen.Beleuchtung on
attr Aussen.Beleuchtung_an room Aussen
define Aussen.Beleuchtung_aus at *23:59:59 set Aussen.Beleuchtung off
attr Aussen.Beleuchtung_aus room Aussen
# zur Zeit noch "unbelegte" Taste auf der Elro-Funkfernbedienung
define ELRO01_A IT 0FF000FFFF FF F0
attr ELRO01_A IODev CUL1
attr ELRO01_A model itswitch
attr ELRO01_A room Technik
attr ELRO01_A ITrepetition 12
# nicht mit der Fernbedienung schaltbarer Kanal "E" der Elro Funksteckdosen
define ELRO01_E IT 0FF00FFFF0 FF F0
attr ELRO01_E IODev CUL1
attr ELRO01_E model itswitch
attr ELRO01_E room Technik
attr ELRO01_E ITrepetition 12
Der "CUL_TX_103" ist wohl per autocreate aufgetaucht (Off Topic: kann mir jemand sagen, wofür der gut ist)? Die Fehlermeldung bezüglich humidity = 0 tauchte im übrigen auch auf, bevor ich die "at"s und die "ITrepetition" Attribute hinzugefügt habe; an denen dürfte es also wahrscheinlich nicht liegen. Die benutzten Kanäle "B", "C" und "D" der Elro-Steckdosen schalten übrigens vernünftig, wenn die Definitionen aktiv sind. Meine Vermutung ist, daß (wenigstens) eine der Definitionen mit der Taupunktberechnung kollidiert, warum auch immer. Ich könnte mal hergehen und die Definitionen stück für Stück durchtesten, vielleicht gibt das noch mehr Aufschluß.
Hat sonst jemand eventuell einen Tipp?
Danke schonmal & viele Grüße
McCavity
Ergänzung:
Ich habe jetzt nochmal ein bißchen Fehlersuche im Ausschlußverfahren betrieben: alle neuen Einträge auskommentiert und dann einzeln wieder eingeschaltet. Fazit: sobald das CUL aktiv ist, gibt es den Fehler. Ist die CUL-Definition draußen, gibt es auch keine Fehler. Interessant: nehme ich die CUL Definition rein, setze aber das Device auf "none" (wurde im Wiki als Möglichkeit zum Testen ohne Hardware empfohlen), dann gibt es auch keine Fehlermeldungen. Auch dann nicht, wenn die Schalter in der fhem.cfg aktiv sind. Also
define CUL1 CUL /dev/ttyACM0 0000
=> Fehler
define CUL1 CUL none 0000
=> kein Fehler.
Woran könnte das liegen? Was kann ich noch zur Aufklärung beitragen? Was mich an der ganzen Geschichte am meisten wundert: ich habe kein Device entdecken können, bei dem das humidity Reading 0 geworden wäre oder der Taupunkt falsch berechnet... leider gibt die Fehlermeldung auch keinen Aufschluß darüber, *welcher* humidity Wert 0 sein soll... hier zum Abschluß noch einmal das 'list CUL1':
Internals:
CMDS BbCFiAZEGMKUYRTVWXefmltux
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/ttyACM0 0000
DeviceName /dev/ttyACM0
FD 16
FHTID 0000
NAME CUL1
NR 97
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.61 CUL433
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
Readings:
2015-12-12 22:36:30 cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015-12-12 22:36:30 state Initialized
Attributes:
room Server
Noch eine Ergänzung - mein Problem ist gelöst: ich hatte ja geschrieben, daß mit dem CUL zusammen ein CLU_TX Device angelegt wurde - offensichtlich ein Temperatursensor. Dieser hat auch ein Humidity-Reading, das bei mir immer "0" war. Nur: wie ich ebenfalls schon schrieb, habe ich gar keinen CUL-Temperatursensor, also hat da wohl "irgendwas" aus der Nachbarschaft empfangen. Da ich den Sensor also nicht brauche, habe ich das "ignore" Attribut gesetzt - dann ist hoffentlich Ruhe...