DbLog , on und off

Begonnen von Wzut, 29 März 2020, 19:27:22

Vorheriges Thema - Nächstes Thema

Wzut

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 ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

mac1001

Ich bitte darum!
Danke [emoji106][emoji6]
FHEM ZBoxNano Debian9, nanoCUL 868MHz, MAX!, Sonoff S20&Pow, Shelly1&2.5, WemosD1Mini&SDM230-Modbus, Raspi3&ConBeeII&Phoscon, Hue Lights, Xiaomi Sensors, espRGBWW

adn77

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

Maui

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  ::)

Wzut

Typisch, zwei User , drei Meinungen :)
Ich denke der beste Weg wird sein das via Attribut zu schalten, dann sollte jeder glücklich werden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui

Das wäre wohl das beste. Aber auch da musst dich auf ein default festlegen  ;D

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

@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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files