CC2652RB probleme
-
Zu früh gefreut, CC2652RB "schaltet" sich nicht mehr ab wenn ein Switch State betätigt wird aber im Objekt bleibt der State vom Adapter unbestätigt
Aus dem Log
@thomas4170 sagte in CC2652RB probleme:
Zu früh gefreut, CC2652RB "schaltet" sich nicht mehr ab wenn ein Switch State betätigt wird aber im Objekt bleibt der State vom Adapter unbestätigt
- Logs als Screenshots posten führt nicht dazu das sich das angesehen wird. Bitte logs in der Zukunft als Text in Code Tags (</>) posten. Dabei bitte NICHT einfach den Text aus dem Admin kopieren sondern über den Button "log herunterladen" die Textdatei herunter laden und die relevanten Zeilen posten.
- Logs bitte immer mit den relevanten Informationen versehen. Dabei ist ein Filtern auf Einträge nur vom Zigbee Adapter nur bedingt förderlich, da einige der Fehlermeldungen vom Host Prozess und nicht vom Zigbee Adapter stammen.
- "Genaue" Fehlerbeschreibungen posten. Wenn beim Bedienen eines bestimmten Gerätes der Adapter abstürzt dann ist interessant:
-- welches Gerät das ist
-- was genau Du zu tun versucht hast
-- was in dem Zeitraum im Log aufgetaucht ist (Aktion +- 1 Minute)
Jetzt du dem was aus Deinen geposteteten Log-Schnipseln erkennbar ist:
- Du hast Probleme mit dem 2.4 GHz Netzwerk. Es scheint so zu sein das eine Störquelle den Funkchip auf dem CC2652 aus dem Tritt bringt (Fehlermeldung 225: MAC Access Channel Failure). Mögliche Ursachen sind:
- Nutzung einer USB3 Festplatte/SSD mit einem schlechten Adapter. Dieser Punkt ist seit längerem (2017 !!!) bekannt. Schlecht geschirmte USB3 Verbindungen können sogar den WLAN Empfang auf 2.4 GHz stören. (https://www.heise.de/newsticker/meldung/c-t-Tipp-der-Woche-USB-3-0-stoert-WLAN-und-Drahtlos-Maus-3726700.html)
- Überschneidung des Zigbee-Kanals mit einem extrem vollen WLAN Kanal
- Störung durch:
-- Funk Kopfhörer
-- DECT Telefon auf 2.4 GHz
-- andere 2.4 GHz Geräte.
- Du hast offensichtlich ein Problem beim Start des Adapters. Leider hast du in deinen Logs die interessanten Informationen ausgeblendet, so das Dir keiner sagen kann woran das wirklich liegt.
- Thema Gerät unterstützen: Damit der Zigbee-Adapter das Gerät unterstützen kann muss es in der vom Adapter genutzten Bibliothek unterstützt sein (zigbee2mqtt.io).
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@thomas4170 sagte in CC2652RB probleme:
Zu früh gefreut, CC2652RB "schaltet" sich nicht mehr ab wenn ein Switch State betätigt wird aber im Objekt bleibt der State vom Adapter unbestätigt
- Logs als Screenshots posten führt nicht dazu das sich das angesehen wird. Bitte logs in der Zukunft als Text in Code Tags (</>) posten. Dabei bitte NICHT einfach den Text aus dem Admin kopieren sondern über den Button "log herunterladen" die Textdatei herunter laden und die relevanten Zeilen posten.
- Logs bitte immer mit den relevanten Informationen versehen. Dabei ist ein Filtern auf Einträge nur vom Zigbee Adapter nur bedingt förderlich, da einige der Fehlermeldungen vom Host Prozess und nicht vom Zigbee Adapter stammen.
- "Genaue" Fehlerbeschreibungen posten. Wenn beim Bedienen eines bestimmten Gerätes der Adapter abstürzt dann ist interessant:
-- welches Gerät das ist
-- was genau Du zu tun versucht hast
-- was in dem Zeitraum im Log aufgetaucht ist (Aktion +- 1 Minute)
Jetzt du dem was aus Deinen geposteteten Log-Schnipseln erkennbar ist:
- Du hast Probleme mit dem 2.4 GHz Netzwerk. Es scheint so zu sein das eine Störquelle den Funkchip auf dem CC2652 aus dem Tritt bringt (Fehlermeldung 225: MAC Access Channel Failure). Mögliche Ursachen sind:
- Nutzung einer USB3 Festplatte/SSD mit einem schlechten Adapter. Dieser Punkt ist seit längerem (2017 !!!) bekannt. Schlecht geschirmte USB3 Verbindungen können sogar den WLAN Empfang auf 2.4 GHz stören. (https://www.heise.de/newsticker/meldung/c-t-Tipp-der-Woche-USB-3-0-stoert-WLAN-und-Drahtlos-Maus-3726700.html)
- Überschneidung des Zigbee-Kanals mit einem extrem vollen WLAN Kanal
- Störung durch:
-- Funk Kopfhörer
-- DECT Telefon auf 2.4 GHz
-- andere 2.4 GHz Geräte.
- Du hast offensichtlich ein Problem beim Start des Adapters. Leider hast du in deinen Logs die interessanten Informationen ausgeblendet, so das Dir keiner sagen kann woran das wirklich liegt.
- Thema Gerät unterstützen: Damit der Zigbee-Adapter das Gerät unterstützen kann muss es in der vom Adapter genutzten Bibliothek unterstützt sein (zigbee2mqtt.io).
A.
@asgothian Danke für die Info, jetzt kann ich auch Fragen beantworten und beim nächsten mal bessere Informationen liefern.
Eigentlich ist das Problem erst seit ich einen Shelly 2.5 gegen einen Zigbee Rolladen-Aktor austauschen wollte. Vorher gab es auch mit der Version 1.6.6 keinerlei Probleme. Meine FritzBox funkt auf Kanal 4-8 und der Koordinator war und ist auf Kanal 11 eingestellt. Vor gut 2 Monaten habe ich Pi4 auf SSD umgestellt und standard USB-Kabel genutzt. Das macht natürlich Sinn was Du schreibst mit "Normalen" USB-Kabel, deshalb gerade ein längeres geschirmtes bestellt. Somit kann ich weiter enfernt den CC2652 vom Serverschrank positionieren. Ich hatte noch drei kürzere USV-Verlängerungen und habe erstmal eine Kette gebildet und das Gerät (Danfoss Ally) reagiert schon mal wieder.
Das neue Gerät (Rolladen-Aktor) ist in der Bibliothek von zigbee2mqtt mit aufgeführt, in dieser Bibliothek nicht und deshalb dachte ich das er noch nicht dabei ist.
So wie Du schreibst vermute ich stark das es ein PRoblem der USB-Kabel SSD und WLAN war/ist. Ich würde jetzt warten bis ich das neuel USB-Verlängerungskabel habe und dann testen. Der CC2652 funktioniert zur Zeit problemlos, heute Abend werden weitere Geräte eingelernt und schaue ich weiter.Viel Dank für die Hilfe und ich werden hier berichten mit den Notwendigen Informationen und korrekter Darstellung von Logs usw.
VG Thomas
-
@thomas4170 sagte in CC2652RB probleme:
Zu früh gefreut, CC2652RB "schaltet" sich nicht mehr ab wenn ein Switch State betätigt wird aber im Objekt bleibt der State vom Adapter unbestätigt
- Logs als Screenshots posten führt nicht dazu das sich das angesehen wird. Bitte logs in der Zukunft als Text in Code Tags (</>) posten. Dabei bitte NICHT einfach den Text aus dem Admin kopieren sondern über den Button "log herunterladen" die Textdatei herunter laden und die relevanten Zeilen posten.
- Logs bitte immer mit den relevanten Informationen versehen. Dabei ist ein Filtern auf Einträge nur vom Zigbee Adapter nur bedingt förderlich, da einige der Fehlermeldungen vom Host Prozess und nicht vom Zigbee Adapter stammen.
- "Genaue" Fehlerbeschreibungen posten. Wenn beim Bedienen eines bestimmten Gerätes der Adapter abstürzt dann ist interessant:
-- welches Gerät das ist
-- was genau Du zu tun versucht hast
-- was in dem Zeitraum im Log aufgetaucht ist (Aktion +- 1 Minute)
Jetzt du dem was aus Deinen geposteteten Log-Schnipseln erkennbar ist:
- Du hast Probleme mit dem 2.4 GHz Netzwerk. Es scheint so zu sein das eine Störquelle den Funkchip auf dem CC2652 aus dem Tritt bringt (Fehlermeldung 225: MAC Access Channel Failure). Mögliche Ursachen sind:
- Nutzung einer USB3 Festplatte/SSD mit einem schlechten Adapter. Dieser Punkt ist seit längerem (2017 !!!) bekannt. Schlecht geschirmte USB3 Verbindungen können sogar den WLAN Empfang auf 2.4 GHz stören. (https://www.heise.de/newsticker/meldung/c-t-Tipp-der-Woche-USB-3-0-stoert-WLAN-und-Drahtlos-Maus-3726700.html)
- Überschneidung des Zigbee-Kanals mit einem extrem vollen WLAN Kanal
- Störung durch:
-- Funk Kopfhörer
-- DECT Telefon auf 2.4 GHz
-- andere 2.4 GHz Geräte.
- Du hast offensichtlich ein Problem beim Start des Adapters. Leider hast du in deinen Logs die interessanten Informationen ausgeblendet, so das Dir keiner sagen kann woran das wirklich liegt.
- Thema Gerät unterstützen: Damit der Zigbee-Adapter das Gerät unterstützen kann muss es in der vom Adapter genutzten Bibliothek unterstützt sein (zigbee2mqtt.io).
A.
@asgothian Moin moin, ich habe gestern fast alle Sensoren und Aktoren wieder angelernt. Vielen Dank für die konstruktiven Hinweise und Anweisungen. Es hat tatsächlich am USB-Kabel gelegen, hätte ich nicht gedacht da nichts verändert wurde außer das Austauschen eines Shelly's gegen Zigbee-Aktor. Ich habe die Umstellung wieder auf TCP-Modul mit einem längeren Netzwerkkabel gewagt und das klappt meiner Meinung nach noch besser. Was allerdings auffällt ist, das die Batteriewerte der Xaiomi-Sensoren/Kontakte nicht mehr passen. Die Volt anzeige stimmt (Batterie mit Multimeter gemessen) aber die Prozentanzeige stimmt nicht.
Vor dem Update auf Version 1.6.15 stimmten die Werte.
Ist das hier richtig reingestellt oder gehört das auf Github?und nochmal, viel Dank für die Hilfe
VG Thomas
-
@asgothian Moin moin, ich habe gestern fast alle Sensoren und Aktoren wieder angelernt. Vielen Dank für die konstruktiven Hinweise und Anweisungen. Es hat tatsächlich am USB-Kabel gelegen, hätte ich nicht gedacht da nichts verändert wurde außer das Austauschen eines Shelly's gegen Zigbee-Aktor. Ich habe die Umstellung wieder auf TCP-Modul mit einem längeren Netzwerkkabel gewagt und das klappt meiner Meinung nach noch besser. Was allerdings auffällt ist, das die Batteriewerte der Xaiomi-Sensoren/Kontakte nicht mehr passen. Die Volt anzeige stimmt (Batterie mit Multimeter gemessen) aber die Prozentanzeige stimmt nicht.
Vor dem Update auf Version 1.6.15 stimmten die Werte.
Ist das hier richtig reingestellt oder gehört das auf Github?und nochmal, viel Dank für die Hilfe
VG Thomas
- Woraus schließt du das die % werte nicht passen ?
- Woraus schliesst du das die % Werte bei 1.6.6 gepasst haben ?
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
- Woraus schließt du das die % werte nicht passen ?
- Woraus schliesst du das die % Werte bei 1.6.6 gepasst haben ?
A.
@asgothian Die eingesetzte Batterien haben eine mit Multimeter gemessene Spannung von 3,05 Volt und ist mit 3,0 Volt angegeben. Ich gehe davon aus das die Batterien zu 100% voll sind. In der Version 1.6.6 die ich bis vor kurzem noch laufen hatte, waren die %-Werte übereinstimment mit den gemessen Spannungswerten.
-
@asgothian Die eingesetzte Batterien haben eine mit Multimeter gemessene Spannung von 3,05 Volt und ist mit 3,0 Volt angegeben. Ich gehe davon aus das die Batterien zu 100% voll sind. In der Version 1.6.6 die ich bis vor kurzem noch laufen hatte, waren die %-Werte übereinstimment mit den gemessen Spannungswerten.
Das kann ich so nicht bestätigen. Ich habe Knopfzellen bei denen ich ohne Last deutlich über 3 V messen kann. 3V sind also nicht zwingend 100%. Des weiteren gab es viele Meldungen das bei den Xiaomi Geräten die % Zahl bei 100% blieb bis die Geräte plötzlich tot waren.
Aus diesem Grund wurde die Berechnung angepasst. Siehe auch
https://github.com/Koenkk/zigbee2mqtt/issues/8499A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
Das kann ich so nicht bestätigen. Ich habe Knopfzellen bei denen ich ohne Last deutlich über 3 V messen kann. 3V sind also nicht zwingend 100%. Des weiteren gab es viele Meldungen das bei den Xiaomi Geräten die % Zahl bei 100% blieb bis die Geräte plötzlich tot waren.
Aus diesem Grund wurde die Berechnung angepasst. Siehe auch
https://github.com/Koenkk/zigbee2mqtt/issues/8499A.
@asgothian Aah ok, ich bin davon ausgegangen das die Spannung auch unter Last gemessen wird wenn der Sensor aktiv ist.
Vielen Dank für die Info
-
@thomas4170 @Asgothian Auch mir sind diese mehr als zweifelhaften Batteriebewertungen aufgefallen. Ich weiss nicht, was man sich bei einer derartigen Bewertung des Zustandes der Batterien gedacht hat. Die Nennspannung einer Lithiumknopfzelle ist 3,00V. Dies entspricht nach meinem Verständnis 100% Ladezustand. Alles was an Spannung darüber gemessen wird, ist nice to have, aber auch nur 100% Ladezustand. Ein Vergleich mit der Anzeige z.B. im Mihome-Adapter zeigt einen deutlichen Unterschied. Dessen Bewertung des Ladezustandes scheint mir deutlich logischer. Ich werde mich nicht auf Grund dieser Bewertung des Ladezustandes zum Hochleistungsbatteriewechsler entwickeln.
-
@thomas4170 @Asgothian Auch mir sind diese mehr als zweifelhaften Batteriebewertungen aufgefallen. Ich weiss nicht, was man sich bei einer derartigen Bewertung des Zustandes der Batterien gedacht hat. Die Nennspannung einer Lithiumknopfzelle ist 3,00V. Dies entspricht nach meinem Verständnis 100% Ladezustand. Alles was an Spannung darüber gemessen wird, ist nice to have, aber auch nur 100% Ladezustand. Ein Vergleich mit der Anzeige z.B. im Mihome-Adapter zeigt einen deutlichen Unterschied. Dessen Bewertung des Ladezustandes scheint mir deutlich logischer. Ich werde mich nicht auf Grund dieser Bewertung des Ladezustandes zum Hochleistungsbatteriewechsler entwickeln.
- Eine neu CR Lithium Batterie hat immer über 3,2V
- Die 3Volt was auf der Verpackung stehen gelten unter eine bestimmte Last. Der Aqara Sensor wird niemals so ein last produzieren.
- Wenn Aqara sagt, die Batterie hat 3,0 Volt, dass heißt das die Batterie halb leer ist. Unter 2,8 werden die Sensoren nicht funktionieren.
- Endlich, werden die Batterie % ab sofort besser berechnet. 👍
-
@dimaiv Entschuldige, aber das was du da schreibst ist eine interessante, aber ziemlich schräge Theorie.
Wenn ich nach der hier über den Farbumschlag angezeigten Symbolik die Batterien wechsle, bleibt bald kein Lithium für die hochgelobte Elektromobilität mehr übrig ;) .Nochmal, es ist meine Meinung zu dem, was da beim letzten Update passiert ist. Da diese Instanz bei mir noch im Teststadium ist, werde ich die Batterielebensdauer ersteinmal noch ein wenig beobachten, bin mir aber ziemlich sicher, dass der als rot dargestellte Sensor sicherlich noch 6-9 Monate mit dieser Batterie vor sich hat. -
@dimaiv Entschuldige, aber das was du da schreibst ist eine interessante, aber ziemlich schräge Theorie.
Wenn ich nach der hier über den Farbumschlag angezeigten Symbolik die Batterien wechsle, bleibt bald kein Lithium für die hochgelobte Elektromobilität mehr übrig ;) .Nochmal, es ist meine Meinung zu dem, was da beim letzten Update passiert ist. Da diese Instanz bei mir noch im Teststadium ist, werde ich die Batterielebensdauer ersteinmal noch ein wenig beobachten, bin mir aber ziemlich sicher, dass der als rot dargestellte Sensor sicherlich noch 6-9 Monate mit dieser Batterie vor sich hat.@radi Ich bin eh am umstellen, nach und nach fliegen die Fensterkontakte bei mir raus und werden ersetzt durch batterielose Fenstergriffe mit EnOcean Protokoll. Einzigst die Rauchmelder zeigen ja ähnliche Werte an aber da mal abwarten wann die anfangen zu Hupen.
Gerade eine Batterie im Rauchmelder ausgetauscht. Gemessene Spannung mit Multimeter 3.22 Volt und das zeigt jetzt der Adapter
-
@dimaiv Entschuldige, aber das was du da schreibst ist eine interessante, aber ziemlich schräge Theorie.
Wenn ich nach der hier über den Farbumschlag angezeigten Symbolik die Batterien wechsle, bleibt bald kein Lithium für die hochgelobte Elektromobilität mehr übrig ;) .Nochmal, es ist meine Meinung zu dem, was da beim letzten Update passiert ist. Da diese Instanz bei mir noch im Teststadium ist, werde ich die Batterielebensdauer ersteinmal noch ein wenig beobachten, bin mir aber ziemlich sicher, dass der als rot dargestellte Sensor sicherlich noch 6-9 Monate mit dieser Batterie vor sich hat. -
@radi
Wo steht es, dass du jetzt unbedingt die Batterie wechseln muss?
Wie lange beobachtest du schon deine Sensoren? 3 - 6 Monaten?
Ich habe die schon seit mehr als 4 Jahre und ich weiß mittlerweile wie die sich verhalten.@dimaiv Ein rotes Batterisymbol wird jedem unbedarften Nutzer suggerieren, hier besteht Handlungsbedarf. Auch ich nutze die Xiaomi-Geräte bereits seit etwa 3-4 Jahren. Die Lebendauer einer Batterie ist für mich mit den knapp zwei Jahren, die die meisten Geräte geschafft haben, in Ordnung. Hier ist übrigens die Entladekennlinie einer CR2032 dargestellt und mit meinen altersgeschwächten Augen liegt die Spannung einer solchen Batterie bei 50% Ladezustand bei ca. 2,9xxV. Hier wird also ziemlich zeitig Alarm geschlagen.
-
@dimaiv Ein rotes Batterisymbol wird jedem unbedarften Nutzer suggerieren, hier besteht Handlungsbedarf. Auch ich nutze die Xiaomi-Geräte bereits seit etwa 3-4 Jahren. Die Lebendauer einer Batterie ist für mich mit den knapp zwei Jahren, die die meisten Geräte geschafft haben, in Ordnung. Hier ist übrigens die Entladekennlinie einer CR2032 dargestellt und mit meinen altersgeschwächten Augen liegt die Spannung einer solchen Batterie bei 50% Ladezustand bei ca. 2,9xxV. Hier wird also ziemlich zeitig Alarm geschlagen.
- Über die Frage ab welcher Batterie % das Icon rot werden darf kann gerne diskutiert werden.
- Das die neue Darstellung der Batterie % besser ist als vorher ist in meinen Augen gesetzt - ich werde da keine Zeit hinein stecken die Änderung rückgängig machen zu lassen
- Das es funktioniert zeigt auch das was der Ersteller dieses GitHub Issues beobachtet hat:
https://github.com/ioBroker/ioBroker.zigbee/issues/1370
A.
-
- Über die Frage ab welcher Batterie % das Icon rot werden darf kann gerne diskutiert werden.
- Das die neue Darstellung der Batterie % besser ist als vorher ist in meinen Augen gesetzt - ich werde da keine Zeit hinein stecken die Änderung rückgängig machen zu lassen
- Das es funktioniert zeigt auch das was der Ersteller dieses GitHub Issues beobachtet hat:
https://github.com/ioBroker/ioBroker.zigbee/issues/1370
A.
@asgothian Hallo. Es ist nicht meine Absicht, dir als Entwickler irgendetwas zu unterstellen. Ich nutze den Zigbee-Adapter erst seit etwa 3 Wochen, erst einmal nur zum experimentieren. Die batteriebetriebenen Geräte haben bei mir mit diesem Adapter noch keine Funktion. Ich war allerdings schon etwas über die vielen roten bzw. orangen Batteriesymbole nach dem letzen Update überrascht. Was zu der neuen Berechnung des Batteriestandes geführt hat, habe ich nicht beobachtet.
Trotzdem oder gerade deshalb meinen Respekt an dich als Entwickler. -
@radi Ich bin eh am umstellen, nach und nach fliegen die Fensterkontakte bei mir raus und werden ersetzt durch batterielose Fenstergriffe mit EnOcean Protokoll. Einzigst die Rauchmelder zeigen ja ähnliche Werte an aber da mal abwarten wann die anfangen zu Hupen.
Gerade eine Batterie im Rauchmelder ausgetauscht. Gemessene Spannung mit Multimeter 3.22 Volt und das zeigt jetzt der Adapter
@thomas4170 Deinen Artikel habe ich bei den vielen anderen Posts doch glatt übersehen. Wie gesagt, ich werde das Ganze erst einmal beobachten. Für die Alarmierung der Batterien habe ich ersteinmal ein Script, dass ich hier im Forum gefunden habe, bei mir eingerichtet. Dort kann ich die Schwelle, bei der ich alarmiert werde, selbst einstellen. Muss jetzt nur beobachten, bei wieviel Prozent Batteriestand wirklich Schluss ist. Mit den Fensterkontakten hatte ich bis jetzt relativ wenig Ärger. Die bedienen bei mir allerdings auch nur die Symbolik in der Visualisierung.
-
- Über die Frage ab welcher Batterie % das Icon rot werden darf kann gerne diskutiert werden.
- Das die neue Darstellung der Batterie % besser ist als vorher ist in meinen Augen gesetzt - ich werde da keine Zeit hinein stecken die Änderung rückgängig machen zu lassen
- Das es funktioniert zeigt auch das was der Ersteller dieses GitHub Issues beobachtet hat:
https://github.com/ioBroker/ioBroker.zigbee/issues/1370
A.
@asgothian
Bin auch der Meinung, dass die Stufen für die farbliche Gestaltung angepasst werden müssen.
Mein Vorschlag wäre:
100 - 50 Grün
49- 20 Gelb
19 - 0 Rot
Natürlich es kann in ein paar Monaten geändert werden, wenn wir mehr Daten dazu gesammelt haben. -
@asgothian Hallo. Es ist nicht meine Absicht, dir als Entwickler irgendetwas zu unterstellen. Ich nutze den Zigbee-Adapter erst seit etwa 3 Wochen, erst einmal nur zum experimentieren. Die batteriebetriebenen Geräte haben bei mir mit diesem Adapter noch keine Funktion. Ich war allerdings schon etwas über die vielen roten bzw. orangen Batteriesymbole nach dem letzen Update überrascht. Was zu der neuen Berechnung des Batteriestandes geführt hat, habe ich nicht beobachtet.
Trotzdem oder gerade deshalb meinen Respekt an dich als Entwickler.@radi Ich habe den Kommentar nicht als Unterstellung gesehen. Ich wollte nur klarstellen was die Ursache der Anpassung ist.
Zum Thema wann müssen die Batterien gewechselt werden - es gibt (wie auch der Post auf Github zeigt) durchaus Geräte die bei 0% Batterie noch gehen. Nur wie lange noch ist da fraglich.
A.
-
@asgothian
Bin auch der Meinung, dass die Stufen für die farbliche Gestaltung angepasst werden müssen.
Mein Vorschlag wäre:
100 - 50 Grün
49- 20 Gelb
19 - 0 Rot
Natürlich es kann in ein paar Monaten geändert werden, wenn wir mehr Daten dazu gesammelt haben.@dimaiv Auch wenn ich nicht angesprochen war, halte ich deinen Vorschlag für sehr konservativ. Mein Vorschlag aus der Kalten:
100-31% Grün
30-16% Gelb
15-0% Rot
Und selbst hier befürchte ich, besteht noch Luft nach unten, da die Spannung bei der bei mir im Moment 39% angezeigt wird, dem 50%-Stand laut Kennlinie der CR2032 entspricht.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden486
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge