Error dewpoint: humidity invalid: 0

Begonnen von jnewton957, 24 Oktober 2015, 16:17:57

Vorheriges Thema - Nächstes Thema

jnewton957

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
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

LuckyDay

Zitathumidity invalid: 0

es darf kein Reading humidity mit 0 als Inhalt geben 

joshi04

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
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Joachim

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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

joshi04

Hallo Joachim,
vielen Dank für den Schubs!
Da brache ich ja überhaupt nicht mehr groß suchen.  :D

Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Joachim

Dafür nicht,
Hast Du daran gedacht, Zeile 444 auch zu ändern, und in global exclude_from_update zu setzen?

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

joshi04

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
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

McCavity

#7
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...