Das dewpoint Modul arbeitete historisch sozusagen in zwei Modi, abhängig davon ob man in der Definition den magischen Namen "T" für die Temperatur verwendet:
- aus readings des Zielgeräts für Temperatur und Feuchte den Taupunkt berechnen und dort als reading eintragen
- aus dem STATE des Zielgeräts Temperatur und Feuchte entnehmen, den Taupunkt berechnen, dort im STATE ergänzen, und ein event für das Zielgerät generieren
Während 1) problemlos und nachvollziehbar lief, gab es bei 2) Probleme:
- wenn im Zielgerät ein stateFormat definiert ist, wird dies von dewpoint nicht benutzt, da der STATE ja direkt manipuliert wird
- wenn im Zielgerät ein anderes Event einläuft, kann das stateFormat sehr wohl evaluiert werden
Dieses Verhalten ist ziemlich unlogisch und führte auch verschiedentlich zu Unverständnis, da das Verhalten relativ zufällig aussieht.
Ich hatte daher am 12.05.2018 eine Änderung eingebaut, dass Modus 2 nicht aktiviert wird,
wenn im Zielgerät stateFormat definiert ist (und nur dann !).
Offenbar gibt es aber verschiedene Installationen, bei denen Modus 2 stabil funktionierte.
Es gibt daher jetzt das neue Attribut
legacyStateHandling, das genau das alte Verhalten reproduziert.
Ob immer das gewünschte Resultat herauskommt, hängt aber von vielen Einflussfaktoren ausserhalb von dewpoint ab: Timing der Events, Eventquellen, allgemeine Änderungen im Framework...
Wenn es damit weiterhin geht, freut euch, aber keine Garantien für die Zukunft.
Das hört sich gut an. Sobald es als Update verteilt wird, werde ich es einspielen und probieren :)
Kleiner Hinweis noch:
ZitatIch hatte daher am 12.05.2018 eine Änderung eingebaut, dass Modus 2 nicht aktiviert wird, wenn im Zielgerät stateFormat definiert ist (und nur dann !).
Hier wäre ein kurzer Satz hilfreich, was 98_dewpoint macht, wenn Modus 2 nicht aktiviert wird. Passiert gar nichts, oder schaltet er trotz magischen Namen ,,T" in Modus 1?
Erster schneller Test zeigt offenbar wieder altbekanntes Verhalten :). Danke
Ich grabe den Thread noch mal aus, da ich gerade über das Verhalten von dewpoint "gestolpert" bin.
Kurz, auf den Punkt: spricht etwas dagegen, das Reading "dewpoint" auch im "legacy" / T H D Fall zu schreiben?
Hintergrund: meine bestehenden Log/Plot Definitionen basieren auf der T H D "Logik", in einer ReadingsGroup möchte ich allerdings das dewpoint reading verwenden (dewpoint als Einzelwert steht bei der Legacy-Implementierung leider nicht zur Verfügung).
Noch ein paar "Beobachtungen" zum/im Code/Doku:
- an einigen Stellen wird hunidity geschrieben (also n statt m); ist zwar eigentlich ein (internerner) Variablenname, taucht allerdings auch in "Trace" Ausgaben so auf und ist damit u.U. nicht gleich zu finden
- Einige Trace/Log Ausgaben sind inkonsistent (normalerweise z.B. "dewpoint-notify:" ... aber manchmal "fehlt" der Doppelpunkt)
- Dann noch in der "readme":
- Compute additional event dewpoint -> Compute additional reading dewpoint
- is lower that the current dewpoint -> is lower than the current dewpoint (genauso später bei "mold" noch mal)
- STATE is mandatory,
set attribute... -> "set" entfernen (kommt am Satzende noch mal - turn a
n fan on or off
Baue ich nächste Woche ein.
Gesendet von meinem Pixel 3 mit Tapatalk
Zitat von: ph1959de am 09 Februar 2019, 17:57:33
Ich grabe den Thread noch mal aus, da ich gerade über das Verhalten von dewpoint "gestolpert" bin.
Kurz, auf den Punkt: spricht etwas dagegen, das Reading "dewpoint" auch im "legacy" / T H D Fall zu schreiben?
Ich habe mir den code noch mal angesehen und fürchte, dass dann wieder bei anderen Anwendern etwas unerwünschtes passiert.
Ich glaube es ist am einfachsten, wenn Du dir noch ein weiteres dewpoint device anlegst, das dann das "dewpoint" reading erzeugt. Der Overhead sollte sich in Grenzen halten.
Danke für die Liste mit den Typos, die habe ich korrigiert.