FHEM Forum

FHEM - Hausautomations-Systeme => MAX => Thema gestartet von: Wzut am 29 März 2020, 19:27:22

Titel: DbLog , on und off
Beitrag von: Wzut am 29 März 2020, 19:27:22
Mal ne Frage an die DbLog Nutzer :
Ich rege mich jedesmal auf wenn mein FHEM Log mal wieder mit readingsGroup/SVN Meldungen geflutet wird weil die Soll Tempeartur auf off/on ging statt einem Zahlenwert.
Ich habe es bei mir jetzt in 10_MAX so geändert das bei off 4.5 und bei on 30.5 geschrieben wird (das sind die Werte die in Wahrheit auch an das HT/WT gehen)
Eure Meinung ? in die Beta mit aufnehmen oder nicht ?
Titel: Antw:DbLog , on und off
Beitrag von: mac1001 am 29 März 2020, 19:36:16
Ich bitte darum!
Danke [emoji106][emoji6]
Titel: Antw:DbLog , on und off
Beitrag von: adn77 am 29 März 2020, 19:45:29
Da man das Log wohl vorrangig zum Plotten verwendet, wären Zahlenwerte auf jeden Fall wünschenswert!  :)

Ich ärgere mich ebenfalls oft über die type mismatch Fehler....
Titel: Antw:DbLog , on und off
Beitrag von: Maui am 29 März 2020, 22:38:10
Irgendwo zwischen sinnvoll und egal  :P
Also kann gern rein. Ich finde es nur schwierig, wenn HT und fhem on anzeigen, aber 30.5 geschrieben wird.
Auch wenn der HT eigentlich 30.5 mitbekommt  ::)
Titel: Antw:DbLog , on und off
Beitrag von: Wzut am 30 März 2020, 08:13:38
Typisch, zwei User , drei Meinungen :)
Ich denke der beste Weg wird sein das via Attribut zu schalten, dann sollte jeder glücklich werden.
Titel: Antw:DbLog , on und off
Beitrag von: Maui am 30 März 2020, 10:50:04
Das wäre wohl das beste. Aber auch da musst dich auf ein default festlegen  ;D
Titel: Antw:DbLog , on und off
Beitrag von: Wzut am 31 März 2020, 13:19:04
Sicher einen Tod muß man sterben, ich habe es jetzt in der aktuellen Beta.
Name des Attributs : DbLog_log_onoff , default ist 1 D.h. ohne User Eingriff alles wie bisher.
Wer die on und offs aus dem Log haben möchte muß das Attribut auf 0 setzen.
Titel: Antw:DbLog , on und off
Beitrag von: Beta-User am 31 März 2020, 13:29:57
@Wzut:
Vielleicht eine Anmerkung zu (sinnvollen) defaults. Ich hatte neulich/vor ein paar Wochen ein ähnliches Problem beim RandomTimer (weg von STATE hin zu state). Da schien es mir auch eigentlich sinnvoll, von STATE wegzugehen und state zu verwenden, was aber ein "breaking change" gewesen wäre. Ich hab's daher vom featurelevel abhängig gemacht: bis 6.1 wird STATE verwendet, es sei denn, der User setzt ein Attribut (das auch später noch paßt), ab 6.1 ist es state, es sei denn, der User ändert entweder den featurelevel, oder setzt das Attribut...
Dazu ein fetter Hinweis in UPGRADE.

Hier scheint auch eher die Tendenz zu sein, dass man den nummerischen Wert eigentlich besser fände, oder?

Wäre ein Anlaß, das featurelevel-Thema und "Tester" mal zu stressen (falls das als Vorgehensweise an sich Sinn macht, mir ist nur auf die Schnelle nichts besseres zum RT eingefallen...)