ZitatGib es nicht sinnvollere Aufgaben als eine solche Änderung für den Entwickler und die Anwender?Vollkommen richtig und du kannst sicher sein, dass ich mir soetwas mehrmals durch den Kopf gehen lassen werde. Zur Zeit habe ich ganz andere Prämissen. Und wie du vllt. auch gelesen hast gibt es schwerwiegende Gründe dies nicht zu tun. Denn ich sehe genau wie du die Probleme die damit zusammenhängen würden, nämlich die Auswertung und das Eventmanagement.
Zitat von: DS_Starter am 15 Oktober 2025, 12:16:58Perspektivisch werde ich dann wahrscheinlich, wie von Parallix vorgeschlagen, die True/False-Readings Battery_ChargeAbort_XX, Battery_ChargeRequest_XX, Battery_ChargeUnrestricted_XX und dem noch hinzukommenden Battery_TargetAchievable_XX ein zusammengefasstes Reading Battery_Status_XX erstellen.Ich halte eine (bitcodierte) Zusammenführung der Readings in ein kombiniertes für kontraproduktiv. Der geneigte Anwender darf dieses dann wieder durch Bitoperationen nach Studium einer Anleitung filetieren, welch ein Fortschritt! In einer Datenbank würde man auch nicht ohne Not Vor- und Nachname zusammenführen und später rätseln, was denn nun der Vor- oder Nachname von Thomas Anton ist.
Aber das muß ich erst in Ruhe entwickeln wenn ich mal viel Zeit und Lust zu einer solchen Änderung habe. Es muß ja auch gut erkennbar und auswertbar sein -> Zukunftsmusik.
Anwendungsseitig problematisch bei zusammengetzten Readings ist vor allem, dass es keinen Bezug mehr gibt wenn man NUR für einen bestimmten Sachverhalt, z.B. Battery_ChargeAbort_XX, einen Event haben möchte.
ZitatIch weiß noch nicht, ob ich mich jetzt weiter mit dem Ding abmühen möchte. So wirklich glücklich war ich damit eh nie.Zumindest könntest Du mal die beiden nanoCULs tauschen. Sollten ja beide 868er sein und sollte daher kein Problem sein.
ZitatUnd mit welchem get raw ist dieses reading zustande gekommen?Na halt mit "get raw"