Hm. Ich verstehe das hier nicht so ganz. Wäre schön, wenn sich jemand, wie bei den systemen auch, für gebiete verantwortlich fühlt oder gemacht wird. Dem könnte ich dann vorschläge machen.
Kurz: ich werde nicht mit Konsequenzen drohen,
Warum auch. Wenn es pflicht ist, baue ich es ein und erwarte, dass es überlegt ist.
Wenn critical Sinn macht, nimm es mit rein und aktualisiere das Wiki.
Dann solltest du aber auch beschreiben, was wann passiert.
Wenn immer erst low und dann critical kommt, wäre das zum Beispiel überhaupt kein Problem.
Natürlich nicht. Ich habe weder die hm fw geschrieben noch die hw designed, spezifiziert oder reviewed. Bei manchen der hm devices gibt es ein critical welches unspezifiziert ist. Es sollte nach low kommen. Auch möglich, dass low nicht kommt. Manche devices haben kein critical. Dann gibt es nur low.
Was dann passiert? Hm. Der akku explodier? Sorry, musste sein. Ernsthaft: wahrscheinlich ist er bald leer. Im unterschied zu low ist das möglicherweise früher der fall. Was für vorteile der user hat es auszuwerten? Er muss schneller laufen.
Wieder ernsthaft: ich reagiere auf low... manchmal. Ein taster hat seit jahren low und die knopfzelle hält. Aber manche haben andere devices, kennen diese und wissen, wie schnell sie reagieren wollen. Ihre notifies und push nachrichten haben sie ihren bedürfnissen angepasst (fhem vorteil!)
Würde ich es in die hand nehmen, etwas zu standardisieren würde es ganz anders aussehen. Schon zu beginn hat mir das battery low nicht gereicht. Daher habe ich den actiondetector eingebaut. Auch hier gab es (mir unverständlichen) widerstand. User waren der meinung, ein batlow reicht. Einige hat es dann kalt erwischt. Der trigger ging verloren, das device ist die meldung nicht mehr los geworden. Ein lowbat ohne ein dead ist für mich sinnlos.
Ich würde so etwas wie (teile aus) hminfo einbauen. Hminfo bietet
A) ein alarm interface. Man wird alarmiert, wenn ein device lowbat anzeigt oder gar tot ist. Weiter werden motorprobleme angezeigt usw. Kann der user erweitern. Man hat EIN interface für system warnings und errors.
B) protokol überwachung: zusammenfassung von übertragungsproblemen zu devices.
C) config check: hat der anwender einstellungen vorgenommen welche fragwürdig sind? Oder fehlen welche? Dblog bietet hier eine coole abfrage.
Wenn jemand ein (EIN) solches modul baut würde ich mich gerne anbinden. Quasi das hm-maintenance-modul. Kritische ereignisse werden von hm-interface modulen gemeldet und gesammelt. Kompakt, einfach und ohne schnickschnack. Der user kann sich anbinden wie er will. Fehler kann man ablöschen, wenn nicht mehr relevant ( im hm und hminfo sind das die clear kommandos)
Ich habe mir die Namen meiner Readings bisher etweder aus den Fingern gesogen oder bei anderen Modulen abgekupfert.
Schade. Das mit den anderen modulen wäre m.E. sinnvoll gewesen
Wäre nur Schade für die Plattform
Eine platform ist es erst, wenn sich jemand die mühe macht, über alle module zu schauen und einen entsprechenden ansatz präsentiert. Nach mehr frage ich ja auch garnicht. Alles andere sind punktuelle ideen, nicht zu ende gedacht.
