Dewpoint und absFeuchte seit Update im Dezember 2017 fehlerhaft

Begonnen von Gast45, 02 Januar 2018, 17:03:54

Vorheriges Thema - Nächstes Thema

Gast45

Hallo zusammen, ich hoffe ich bin hier richtig. Ist mein erster Post hier.

Ich habe schon länger eine FHEM-Installation, die für meine Temperatur- und Feuchtigkeitssensoren über dew_state den Taupunkt und absolute Feuchtigkeit berechnet. Die berechneten Werte erschienen auch monatelang im STATE. Seit dem letzten Update erscheinen die Werte aber nicht mehr im STATE. Berechnet werden sie aber, da sie im LOG geschrieben werden.

Hat das Problem noch jemand? Gibt es eine Lösung?

Ich habe bereits alles mal weg und wieder rein konfiguriert. Problem bleibt bestehen.
Meist liegt der Fehler vor der Tastatur

enno

Könnte das eine Lösung sein?

https://forum.fhem.de/index.php/topic,78359.msg731858.html#msg731858

Events gibt es jetzt nur noch, wenn das Reading dewpoint durch die Filter event-on-(update|change)-reading durchgeht.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

Gast45

#2
Danke. Gelesen hatte ich das schon, aber so recht verstehe ich das nicht. Außerdem erscheint das Reading dewpoint bei mir gar nicht im device. Somit kann ich auch nichts durch Event-on jagen. Die absFeuchte erscheint aber sehr wohl als Reading. Die hatte ich mal eingetragen, aber brachte auch keine Änderung.
Alles sehr sonderbar.
Ich habe inzwischen eine Installation auf dem neuen Raspian komplett neu aufgesetzt. Die verhält sich identisch.  :-\
Meist liegt der Fehler vor der Tastatur

Hallerschneider

Hallo,
fhem_update vor 4 Tagen und das gleiche mit dewpoint. Keine Ahnung was da schief ging. Ich warte mal das nächste größere Update ab.

Gast45

Schön zu wissen, dass man nicht alleine das Problem hat. Ich werde wohl auch das nächste Update abwarten müssen. Ich wollte aber zumindest auf das Problem hinweisen, in der Hoffnung, dass es jemand liest, der sich einen Reim darauf machen kann  :D
Meist liegt der Fehler vor der Tastatur

Gast45

#5
Heute mal neues Update eingespielt. Keine Veränderung.
Hat jemand eine Idee welches Modul hier nicht richtig arbeitet? 98_dewpoint wird es ja eher nicht sein, da die Werte berechnet werden.
Meist liegt der Fehler vor der Tastatur

Gast45

Hallo zusammen. Heute wurde eine Änderung in 98_dewpoint eingespielt und der Hinweis ,,use NOTIFYDEV" gegeben. Kann mit dem Hinweis jemand was anfangen? Der STATE wird jedenfalls immer noch nicht mit den aktuellen Taupunkt ergänzt.
Meist liegt der Fehler vor der Tastatur

KölnSolar

So ganz verstehe ich nicht, worum es geht: das reading dewpoint erscheint bei mir wie immer mit seinem Wert im korrekten device. In state hat es meines Erachtens sowieso nichts verloren, da damit der state des Original-devices verändert wird und das könnte ja Auswirkungen haben :-\

Aber egal, verschiebt mal den Thread ins richtige Unterforum(lt. maintainers in Automatisierung), dann liest es vielleicht auch der maintainer.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Gast45

#8
Mh, bei mir erscheint nur die absFeuchte im device, der dewpoint nicht. Aber wie gesagt landen alle Werte im LOG. Also werden sie scheinbar grundsätzlich berechnet. Die Logˋs habe ich so definiert, dass es je Zeitpunkt eine Zeile mit allen Werten gibt:
T: 8.8 H: 88 D: 6.9 A: 7.6
Das schöne am geänderten State war ja gerade, dass es in der Übersicht kompakt auftauchte. Und das geht gerade seit dem Update Anfang Dezember 2017 plötzlich nicht mehr.

Wie verschiebt man das Thema? Muss ich da was tun und wenn ja, was?

Sorry, ich übe hier noch  ;)

PS: wenn es Absicht ist, dass der State nicht mehr ergänzt wird, dann ist das zwar nicht schön, aber es wäre eine Erklärung und somit keine Fehlfunktion. Dann muss aber die Hilfe geändert werden, denn dort steht ja gerade, dass mit dew_state genau das passieren soll.
Meist liegt der Fehler vor der Tastatur

LuckyDay

Ich habe jetzt mal auch das aktuelle 98_devpoint.pm ausprobiert, das erzeugt jetzt 2 mal ein state event
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather humidity: 90
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather measured-temp: 19.6
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather T: 19.6 H: 90
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather absFeuchte: 15.2
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather dewpoint: 17.9
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather T: 19.6 H: 90 D: 17.9

hier nochmal extra gezeigt , die finden sich jetzt natürlich auch im LOGfile
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather T: 19.6 H: 90
2018-01-11 20:46:48.633 CUL_HM og_Wohnzimmer_Weather T: 19.6 H: 90 D: 17.9


LOG
jetzt-->falsch
2018-01-11_20:46:48 og_Wohnzimmer_Weather T: 19.6 H: 90 D: 17.9
2018-01-11_20:46:48 og_Wohnzimmer_Weather T: 19.6 H: 90


früher -->richtig
2018-01-11_20:10:44 og_Wohnzimmer_Weather T: 19.5 H: 55 D: 10.2
2018-01-11_20:08:38 og_Wohnzimmer_Weather T: 19.6 H: 55 D: 10.3
2018-01-11_20:03:44 og_Wohnzimmer_Weather T: 19.5 H: 55 D: 10.2
2018-01-11_19:57:52 og_Wohnzimmer_Weather T: 19.4 H: 55 D: 10.1
2018-01-11_19:55:38 og_Wohnzimmer_Weather T: 19.4 H: 56 D: 10.4

KölnSolar

ZitatDas schöne am geänderten State war ja gerade, dass es in der Übersicht kompakt auftauchte.
Verstehe, ist aber vielleicht mit stateformat machbar  :-\
ZitatWie verschiebt man das Thema?
edit des 1. Beitrags u. dann gibt's(glaub ich) unten links einen Button
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Gast45

#11
Die doppelten Einträge im log hatte ich auch. Ich habe es wegbekommen indem ich auf ,,D:" gefiltert habe:
AddRegexpPart <device>:.*D:.*

Meist liegt der Fehler vor der Tastatur

Gast45

Stateformat nutze ich, klappt aber nicht, weil der dewpoint in den Reading nicht erscheint.
Ich glaube ich finde mich mit der Situation ab.
Meist liegt der Fehler vor der Tastatur

the ratman

#13
ich stelle grade fest, das problem hab ich auch zu 50%.
getestet mit netatmo, das auf beiden installs fehlerfrei rennt.

am aktiven fhem rennt dewpoint wie immer. da hab ich einen extra dewpoint pro device anglegt.
am zukünftigen fhem rennt dewpoint seit 28.11.2017 nicht mehr. auf der installation hab ich dewpoint nur 1 mal mit .* am laufen.
→do↑p!dnʇs↓shit←

RieWi

ich habe das gleiche Problem wie fhem-hm-knecht und zwar doppelte Einträge im Log

2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen temperature: 5.3
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen humidity: 79.0
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9

Im DeviceOverview fehlt der Dewpoint!
Internals: STATE: T: 5.3 H: 79.0
Readings: STATE: T: 5.3 H: 79.0
Ein weiterverwenden des Dewpoint durch STATE-Abfrage ist somit nicht möglich.

Fhem Logfile mit dewpoint verbose = 5:
2018.01.17 18:01:25 4: dewpoint_notify: cmd_type=dewpoint devname=lt_Aussen dewname=dew_state, dev=lt_Aussen, dev_regex=lt_.* temp_name=T hum_name=H
2018.01.17 18:01:25 5: dewpoint_notify: s='T: 5.3 H: 79.0'
2018.01.17 18:01:25 5: dewpoint_notify: evName='T:' val=5.3'
2018.01.17 18:01:25 5: dewpoint_notify T: H:, temp=5.3 hum=79.0
2018.01.17 18:01:25 5: dewpoint_notify: s='temperature: 5.3'
2018.01.17 18:01:25 5: dewpoint_notify: evName='temperature:' val=5.3'
2018.01.17 18:01:25 5: dewpoint timeout=1
2018.01.17 18:01:25 5: dewpoint_notify: dewpoint=1.9
2018.01.17 18:01:25 5: dewpoint_notify: current=T: 5.3 H: 79.0 D: 1.9

Hier gibt es einen dewpoint Timeout=1 !!!

Zur Zeit ersetze ich nach jedem Update die 98_dewpoint.pm  durch die alte Version vom 12.10.2014 dann funktioniert wieder alles.

Gast45

Zitat von: RieWi am 17 Januar 2018, 18:16:15
ich habe das gleiche Problem wie fhem-hm-knecht und zwar doppelte Einträge im Log

2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen temperature: 5.3
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen humidity: 79.0
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9

In Beitrag 11 hatte ich schon was dazu geschrieben. Vielleicht hilft das.



Zitat von: RieWi am 17 Januar 2018, 18:16:15

Im DeviceOverview fehlt der Dewpoint!
Internals: STATE: T: 5.3 H: 79.0
Readings: STATE: T: 5.3 H: 79.0

Genau das ist das Problem :(


Zitat von: RieWi am 17 Januar 2018, 18:16:15
Zur Zeit ersetze ich nach jedem Update die 98_dewpoint.pm  durch die alte Version vom 12.10.2014 dann funktioniert wieder alles.

Soweit zurück? Ist die vorletzte Version so lange unbearbeitet geblieben? Wo findet man die?
Meist liegt der Fehler vor der Tastatur

hotbso

Hallo zusammen,
da die Diskussion nicht in "Automatisierung" los ging, ist sie leider durch meine Filter gefallen und bisher an mir vorbeigegangen.

Zum Hintergrund:
Die Innereien des Moduls sind sehr alt und dort wurde (und wird noch) in den globalen Variablen von FHEM herumgeschraubt. Ich bin jetzt dabei, das ganze schrittweise auf das jetzt inzwischen existierende API umzubauen.

Das Modul hat die Spezialität, dass wenn die angegebene Temperatur den magischen Namen "T" hat, der STATE des Devices manipuliert wird. Dann wird auch kein Reading "dewpoint" angelegt. (absFeuchte aber ggf. schon);
Das geht so ziemlich an der Logik vom FHEM zu Readings und Events vorbei, ich versuche aber das Verhalten im Rahmen von Rückwärtskompitibilität zu erhalten.

Der Fehler müsste jetzt in der anhängenden Version gefixt sein, bitte mal ausprobieren, bevor ich das einchecke.

Der bessere Ansatz ist:
- das dewpoint device mit den Namen der Readings für Temperatur und Feuchte anlegen
- dann mit Attribut "stateFormat" den Taupunkt im STATE ergänzen

Gruss
Holger

nils_

Zitat von: RieWi am 17 Januar 2018, 18:16:15
Zur Zeit ersetze ich nach jedem Update die 98_dewpoint.pm  durch die alte Version vom 12.10.2014 dann funktioniert wieder alles.

--> https://fhem.de/commandref_DE.html#exclude_from_update
viele Wege in FHEM es gibt!

RieWi

Hallo hotbso,

ich habe Deine 98_dewpoint verwendet.

Im DeviceOverview ist der Dewpoint wieder da.
Internals: STATE: T: 5.0 H: 69.0 D: -0.2
Readings: STATE: T: 5.0 H: 69.0

Das Fhem Logfile mit dewpoint verbose = 5:
2018.01.18 18:01:39 4: dewpoint_notify: cmd_type=dewpoint devname=lt_Aussen dewname=dew_state, dev=lt_Aussen, dev_regex=lt_.* temp_name=T hum_name=H
2018.01.18 18:01:39 5: dewpoint_notify: s='T: 5.0 H: 69.0'
2018.01.18 18:01:39 5: dewpoint_notify: evName='T:' val=5.0'
2018.01.18 18:01:39 5: dewpoint_notify T: H:, temp=5.0 hum=69.0
2018.01.18 18:01:39 5: dewpoint_notify: s='temperature: 5.0'
2018.01.18 18:01:39 5: dewpoint_notify: evName='temperature:' val=5.0'
2018.01.18 18:01:39 5: dewpoint max_timediff=1
2018.01.18 18:01:39 5: dewpoint_notify: dewpoint=-0.2
2018.01.18 18:01:39 5: dewpoint_notify: current=T: 5.0 H: 69.0 D: -0.2
2018.01.18 18:01:40 4: dewpoint_notify: cmd_type=dewpoint devname=lt_Aussen dewname=dew_state, dev=lt_Aussen, dev_regex=lt_.* temp_name=T hum_name=H
2018.01.18 18:01:40 5: dewpoint_notify: s='T: 5.0 H: 69.0'
2018.01.18 18:01:40 5: dewpoint_notify: evName='T:' val=5.0'
2018.01.18 18:01:40 5: dewpoint_notify T: H:, temp=5.0 hum=69.0
2018.01.18 18:01:40 5: dewpoint_notify: s='humidity: 69.0'
2018.01.18 18:01:40 5: dewpoint_notify: evName='humidity:' val=69.0'
2018.01.18 18:01:40 5: dewpoint max_timediff=1
2018.01.18 18:01:40 5: dewpoint_notify: dewpoint=-0.2
2018.01.18 18:01:40 5: dewpoint_notify: current=T: 5.0 H: 69.0 D: -0.2

Hier scheint es als ob alles 2mal abgearbeitet wird?

hotbso

Das kann ich in meiner Testumgebung so nicht nachvollziehen.

Tritt das bei Dir immer auf und immer mit 1 Sekunde Abstand im Log ?

Gast45

Hey cool, dass Bewegung rein kommt. Dafür schon mal danke.
Ich bekomme es jetzt nicht ganz 100%ig beschrieben. Aber mit dem berechnen des Taupunktes aus Temperatur und Feuchtigkeit und anschließend einfügen per stateFormat hatte ein Nachteil. Meine Sensoren liefern mal Temperatur, mal Feuchtigkeit, mal beides und auch mal länger nichts. Und die empfangenen Werte erscheinen auch nicht sofort im state, sondern erst mit der nächsten Übertragung. So kam es öfters vor, dass der berechnete und in STATE per stateFormat eingefügte Taupunkt nicht zu den im STATE (veralteten) angezeigten Werten für Temperatur und Feuchtigkeit passte.
Wenn aber der Taupunkt aus T und H berechnet wird, dann passen die Werte zwangsläufig zusammen.
Meist liegt der Fehler vor der Tastatur

hotbso


Mit dem Attribut max_timediff kannst du steuern, wieweit der Messzeitpunkt von Temperatur und Feuchtigkeit auseinander liegen darf. Der default liegt bei nur 1 Sekunde. Wenn dein Thermometer längere Aussetzer hat, setze das Mal höher.

Gesendet von meinem Nexus 5X mit Tapatalk


RieWi

Hallo Holger,

ich habe den Sensor: TFA Dostmann Aussensender 433 Mhz-Frequenz 303125 im Einsatz.
Es ist bei meinem Sensor genauso wie von Gast45 beschrieben, Temperatur und Feuchtigkeit werden getrennt geliefert.
Jedesmal wenn sich ein Wert aktualisiert wird erfolgt eine Taupunktberechnung, was auch so sein soll.
Also ist alles wieder in Ordnung.

Das Attribut max_timediff wer bis jetzt noch nicht gesetzt, ich habe max_timediff auf 600 Sekunden gesetzt, weil der Abfrageintervall im "define lt_Aussen CUL_TX 125 0 600" auf die gleiche Zeit konfiguriert ist.

Den bessere Ansatz vom 18.01.17 11:48 habe ich nicht verstanden? (ist auch nicht mehr nötig - oder?)
   - das dewpoint device mit den Namen der Readings für Temperatur und Feuchte anlegen
   - dann mit Attribut "stateFormat" den Taupunkt im STATE ergänzen
Auch im -> dex_state -> Device specific help <- habe ich nichts gefunden.

Vielen Dank für die schnelle und kompetente Bearbeitung.

Gruss
Willi

hotbso

Der bessere Ansatz:
Angenommen die readings bei deinem Thermometer heissen (wie bei fast allen anderen auch) "temperature" und "humidity".

Dann definierst Du zB
define my_dewpoint dewpoint dewpoint  Thermo_(In|Out)

Dann bekommst Du in Deinen Thermometern das Reading "dewpoint" angelegt.

Im Device des Thermometers kannst Du dann mit stateFormat die Anzeige des STATE zusammenbauen (siehe commandref).

Wie schon gesagt ist das besser, weil das Herumfummeln am STATE eines anderen Devices eigentlich an der Logik von FHEM vorbeigeht.

Gast45

#24
Hi hotbso,

Maxtimediff hatte ich auch schon hochgesetzt. Im übrigen habe ich auch die gerade beschriebenen tfa. Maxtimediff ändert aber nichts am Problem, dass die geänderten Temperatur- und Humidity-Werte nicht sofort im State landen. Damit stehen im State eventuell zwei alte Werte, und mit z.b. nur einem aktualisieren Temperaturwert wird der Taupunkt berechnet. Der passt dann natürlich nicht zu den noch alten Werten im State.
Kann mir einer folgen?  :D

Wenn ich das richtig verstanden habe, dann nutzt dewpoint die Werte aus dem state, wenn Mann dewpoint mit T und H definiert. Damit waren die Werte zwangsläufig immer zueinander passend.
Meist liegt der Fehler vor der Tastatur

Gast45

Ich denke ich werde alles mal umbauen.
- Taupunktberechnung nur noch nach state-Änderung (event-on-change-reading state). Ich hoffe das funktioniert so?
- Taupunktberechnung individuell pro Device.
- Änderung des STATE mit stateFormat

Ich denke das wird auch für konsistente Werte im STATE sorgen, weil ich mir ziemlich sicher bin, dass state und STATE stets identisch sind?!
Meist liegt der Fehler vor der Tastatur

hotbso

Zitat von: Gast45 am 20 Januar 2018, 11:06:58
Ich denke ich werde alles mal umbauen.
- Taupunktberechnung nur noch nach state-Änderung (event-on-change-reading state). Ich hoffe das funktioniert so?
- Taupunktberechnung individuell pro Device.
- Änderung des STATE mit stateFormat

Ich denke das wird auch für konsistente Werte im STATE sorgen, weil ich mir ziemlich sicher bin, dass state und STATE stets identisch sind?!
Das ganze ist aus Prosa schwer nachzuvollziehen.
Poste doch mal die Definitionen eines Thermometers, des dewpoints (alles  inklusive der Attribute) sowie einen Auszug aus dem Log mit verbose Level  (für dewpoint).

Gast45

Beschreibung meiner Idee:
Folgendes habe ich mir bei der u.g. Konfiguration gedacht:
Nur wenn sich das Reading "state" ändert, mindestens aber alle 3 Minuten soll ein Event erzeugt werden.
(eigenartigerweise liegen hier auch gerne mal fast 4 Minuten dazwischen, s.u.).
Durch das Event werden die T- und H-Werte aus dem reading "state" durch die Taupunkt-Berechnung dew_state geschickt.
Diese ergänzt dann wiederum das Internal "STATE" um den Taupunkt und die absolute Feuchtigkeit.
Ich hatte so gehofft, dass die Werte (T, H, D, A) im "STATE" jeweils zu 100% konsistent zueinander sind.
Ansonsten konnte es wie beschrieben passieren, dass Temperatur und/oder Humidity sich im zeitverlauf ändern,
aber wegen eines zu großen Zeitabstandes der Taupunkt und absolute Feuchtigkeit nicht berechnet wurden.
Dann passen aber die T- und H-Werte im Internal "STATE" nicht mehr zu den veralteten D- und A-Werten.
Damit wären diese Datensätze inkonsistent und das ist wiederum unschön, da sie ja in dieser Kombination im
Log erscheinen.



Definition des Außentemperaturfühlers:

define SensorAussen CUL_TX 127
attr SensorAussen event-min-interval state:180
attr SensorAussen event-on-change-reading state,humidity,temperature
attr SensorAussen stateFormat T: temperature H: humidity D: dewpoint A: absFeuchte




Definition des Log-Files, damit nur eine Zeile pro Messpunkt geschrieben wird:

define FileLog_SensorAussen FileLog ./log/SensorAussen-%Y.log SensorAussen:.*D:.*


Mit ".*D:.*" habe ich erreicht, dass es wie auch von anderen beschrieben keine doppelten
Einträge mehr im Log gab.



Definition Taupunktberechnung:

define dew_state dewpoint dewpoint .* T H D
attr dew_state absFeuchte 1




Auszug aus dem LOG:

2018-01-20_12:58:29 SensorAussen T: 4.2 H: 83.0 D: 1.6 A: 5.3
2018-01-20_13:02:23 SensorAussen T: 4.2 H: 83.0 D: 1.6 A: 5.3 (Zeitdifferenz größer 3 Minuten!)
2018-01-20_13:05:18 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (D- und A-Berechnung bei Änderung im state)
2018-01-20_13:09:12 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (Zeitdifferenz größer 3 Minuten!)
2018-01-20_13:13:06 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (Zeitdifferenz größer 3 Minuten!)


Im Log erscheinen die Werte wie gewünscht, nur das Internal wird seit Dezember 2017 nicht mehr geändert.
Die Klammern sind natürlich nicht im Log, sondern nur Anmerkungen von mir, damit man direkt sieht, worum
es mir in der jeweiligen Zeile geht.


Zunkunft:
Zukünftig werde ich wohl die Taupunktberechnung pro Sensor einzeln programmieren,
das Reading dewpoint erzeugen lassen und das Internal "STATE" ändern mit:


stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",
ReadingsVal("SensorAussen","temperature",0),
ReadingsVal("SensorAussen","humidity",0),
ReadingsVal("SensorAussen","dewpoint",0),
ReadingsVal("SensorAussen","absFeuchte",0))}


Außerdem plane ich so eine Art "Dummy" zwischen dem Sensor und der übrigen Definition (Log, Plot) einzuführen.
Das Problem ist, dass sich der Fühler beim Batteriewechsel mit einer neuen ID meldet. Einfach wieder
mit rename umbenennen zu SensorAussen war glaube ich nicht möglich. Vielmehr musste man alles zum
Sensor löschen (Device, Log, Plot). Dann muss man aber nach einm Batteriewechsel wieder alles neu konfigurieren.
Und wenn man nicht aufpasst und sie nicht manuell sichert, dann ist nach dem rename die alte Log-Datei mit allen
Werten weg. Mit den "Dummy" möchte ich erreichen, dass bei einem Batteriewechsel nur noch der "Dummy" gelöscht
und das Device mit einem rename wieder zu dem "Dummy" wird. Das Log und der Plot sollen vom "Dummy" erfolgen und
sind damit unabhängig. Gerade der Batteriewechsel ist aber auch ein Grund, warum ich die Konfiguration des Device
möglichst einfach halten möchte. Je mehr hier programmiert ist, umso aufwendiger ist so ein Batteriewechsel.

Ergänzend:
Ich weiß nicht so recht, was ich genau mit verbose-Log erfassen soll. Mal abgesehen, dass das im Zweifel ewig lang wird
und vor allem auch lange dauert. Die Zeit kann ich mir heute leider nicht mehr nehmen.
Meist liegt der Fehler vor der Tastatur

hotbso

Wenn du den dewpoint mit T H D definierst und stateFormat verwendest, arbeitet das beides gegeneinander.

Ich denke mit

define dew_state dewpoint dewpoint .* temperature humidity dewpoint
attr dew_state absFeuchte 1
max_timediff muss so groß sein, dass du auch immer ein passendes temperature und humidity Reading hat, man braucht nun Mal beides.

Es passiert folgendes:
- temperature und/oder humidity event wird generiert
- Reading dewpoint wird *immer* berechnet
- stateFormat setzt STATE
- alles ist konsistent

Die doppelten Events sollte es nicht mehr geben.
Ich weiß nicht genau, was du mit "einzeln berechnen" meinst. Wenn die Definition und Attribute des dewpoint für mehrere devices passen, bringt das keinen Vorteil.

Gesendet von meinem Nexus 5X mit Tapatalk


Gast45

#29
ZitatWenn du den dewpoint mit T H D definierst und stateFormat verwendest, arbeitet das beides gegeneinander.
Das habe ich deshalb gemacht, weil bei der Konfiguration, wenn es zu keiner Taupunkt-Berechnung kommt, D und A komplett aus dem Internal STATE verschwinden bis wieder eine Berechnung stattfindet. Durch die Definition war es möglich immer die absolute Feuchtigkeit im STATE zu haben und für dewpoint wurde "n.V." angezeigt. Das habe ich erreicht, indem ich das reading für dewpoint manuell mit "n.V." belegt habe. Das funktionierte auch bis Dezember wunderbar. Dass das möglicherweise jetzt stört hatte ich auch vermutet und deshalb rauskonfiguriert. Geändert hat es aber nichts.

Zitatdefine dew_state dewpoint dewpoint .* temperature humidity dewpoint
attr dew_state absFeuchte 1
max_timediff muss so groß sein, dass du auch immer ein passendes temperature und humidity Reading hat, man braucht nun Mal beides.

Es passiert folgendes:
- temperature und/oder humidity event wird generiert
- Reading dewpoint wird *immer* berechnet
- stateFormat setzt STATE
- alles ist konsistent
Ja, das verstehe ich soweit, glaube ich. Aber das Problem bei den Sensoren ist leider, dass sie tatsächlich auch mal viele Minuten (zwar selten, aber auch gerne mal über eine halbe Stunde) keine Werte oder nur einen Werte liefern. Damit ist max_timediff problematisch sinnvoll zu setzen.

Das Problem:
Mein Eindruck ist, dass die Werte im Reading "state" die Werte von Temperatur und Humidity bekommen, bevor die aktuellen Werte in in die Readings "temperature" und "humidity" eingespielt werden. Damit stehen im "state" quasi die Vorgängerwerte. Wenn nun viel Zeit zwischen den Aktualisierungen vergeht, passen die mit "temperature" und "humidity" berechneten Taupunkte nicht mit den im "state" bzw. "STATE" veralteten Werte überein. Auch deshalb bin ich auf das reading "state" ausgewichen. So waren zwar die Werte alt und möglicherweise auch einer der T- oder H-Werte alt, aber in sich alle vier konsistent. Einen Tod muss man bei den Sensoren leider sterben :)


@hotsbo:
Die ganzen Erkenntnisse sind übrigens etwa ein Jahr alt. Damals habe ich mit Fhem begonnen und wollte die Arbeitsweise verstehen. Das Ganze war natürlich extrem zeitaufwändig und so ganz klar ist mir Vieles immer noch nicht.
Ich werde mal schauen, wie ich mit der jetzt gegebenen Situation letztlich umgehen werde. Wenn das automatische Ändern des Internals "STATE" der Arbeitsweise von Fhem widerspricht, hat es keinen Sinn sich darauf abzustützen. Über kurz oder lang würde es eh entfallen. Es ist auch absolut sinnvoll ein einheitliches Verhalten des gesamten Systems zu verfolgen. Sonderfälle erschweren das Verständnis immer.
Aber dennoch natürlich besten Dank für die hilfreichen Antworten.

Zusatzinfo, 20.1.18, 19:00 Uhr:
Ich habe doch noch etwas den Verlauf der Werteübermittlung verfolgt. Auch ein einzelner, verändert übermittelter Temperaturwert erscheint unmittelbar im Reading state. Demnach scheint meine Aussage nicht (mehr) korrekt zu sein, dass bei einem übermittelten Wert zuerst der Temperaturwert in den state verschoben wird und dann das Temperatur-Reading erneuert wird, womit im state stets der Vorgängerwert stünde. Ob das Verhalten vor einem Jahr noch anders war, oder ob es doch noch Situationen gibt, wo das Schreiben des Reading state vielleicht auch einfach ausbleibt, kann ich nicht sagen. 

Zusatzinfo, 20.1.18, 19:45 Uhr:
Update durchgeführt. STATE-Ergänzung funktioniert wieder wie früher. Danke an die zuständigen Programmierer.
Wenn hier in den nächsten Tagen kein Diskussionsbedarf mehr besteht, dann werde ich das Thema schließen. Ich glaube das ist meine Aufgabe, oder?
Meist liegt der Fehler vor der Tastatur