HM-TC-IT-WM-W-EU / Low-Bat.-Schwelle

Mich wundert bei eQ3 eh nix mehr. Gerade sehe ich in IPS, dass die Fernbedienung ne schwache Batterie meldet. Das ist der CCU2 noch nicht mal ne Servicemeldung wert, noch bekommst Du dort irgendwo den Hinweis dazu.

So kann man auch die Servicemeldungen künstlich kleinhalten. Tststst

Das lässt sich erklären. Ich denke es gibt keine Low-Bat-Hysterese. Bei mir verschwinden in der CCU Geräte die vorher mit Low-Bat gemeldet haben durchaus manchmal wieder aus der Serviceliste - die Bat-Meldung im Display z.b. eines WTs auch.

Wenn Du die Servicemeldungen in IPS nicht permanent aktualisierst kann es daher schon zu einem inhaltlichen Versatz der Meldungen kommen.

Was lange währt, wird endlich gut :slight_smile:

Nachdem ich SÄMTLICHE (IPS-)Skripte/Logik überprüft, eventuell vorhandene Fehl-Konfigurationen, externe Einflüsse, Firmware-Probleme, etc., etc., als Auslöser ausgeschlossen hatte, habe ich nun endlich den/die Übeltäter für den ultra-hohen Batterieverbrauch ausgemacht!
Ich hatte sogar noch einmal „nur mal eben zum Testen“ einen weiteren WT geordert um einen Hardware-Defekt der 13 vorhandenen „Problem-Geräte“ auszuschließen, da diese zwar von unterschiedlichen Quellen, aber im Zeitraum von 2 Wochen relativ kurz nach Erscheinen geordert wurden. Klar, dass ich fast direkt nach Absetzen der Bestellung auf die Lösung des Problems gestoßen bin :rolleyes:

Um’s kurz zu machen: es war ein schon seit langem funktionierend verbauter „HM-LC-Dim1T-FM“ bzw. „HM-LC-Dim1TPBU-FM“. Es läßt sich jetzt leider nicht mehr eindeutig feststellen ob der eine, der andere oder beide der eigentliche „root cause“ waren. Fakt ist: beide hatten ein schwer greifbares Problem.

  • beim „HM-LC-Dim1T-FM“ war das einzig Auffällige, dass, wenn selten einmal eine Kommunikationsstörung auftauchte, diese nicht sofort nach Bedienung des Aktors wieder verschwand bzw. der Aktor für teilweise 15-20 Minuten überhaupt nicht auf eine Aktion via IPS oder WebUI reagierte (deutete auf „duty-cycle“ hin, dazu noch ein Kommentar weiter unten). Da der Aktor für einen Teil der Deko-Beleuchtung im Garten zuständig ist, deswegen nicht per Hardware-Taste und überhaupt nur selten via IPS geschaltet wird, fiel das im Normalbetrieb nicht auf. Generell sind die mit 230V betriebenen (Funk-)Geräte nach meinen Erfahrungen ja sowieso sehr resistent gegen Kommunikationsprobleme.

  • bei dem erwähnten „HM-LC-Dim1TPBU-FM“ war es „etwas offensichtlicher“ -> hier fehlte ein Teil der Konfiguration im Kanal 3 und war somit in der WebUI auch nicht zu sehen (nein, es lag nicht etwa am Browser-Cache!). Auffallen kann einem das aber auch nur, wenn man viel Zeit mitbringt und jeden einzelnen Kanal in seinem HM-Geräte-Zoo nach Seltsamkeiten abklappert. Ich habe bei allen 3-kanaligen Aktoren die internen Geräte-Tasten auf Kanal 3 liegen (jeweils ODER-verknüpft mit Kanal 1 & 2 - diese sind sozusagen für die Bedienung durch IPS „reserviert“ - so behält man die Übersicht etwas besser) und diese haben seltsamerweise auch bei diesem Aktor immer einwandfrei funktioniert.

Nach Ablernen mit Factory-Reset, Wieder-Anlernen und Neukonfiguration der beiden Kameraden war dann endlich Ruhe!
Was mich bei der ganzen Aktion etwas anfräst ist …

  1. dass ich nicht mehr nachvollziehen kann wann genau/wodurch es passiert ist (FW-Update?, Absturz?, „Schuld eigene“, …??)
  2. die Aktoren/der Aktor scheinbar massig „blödsinnigen“ Funkverkehr verursacht haben und in den Logs nicht wirklich etwas davon feststellbar war („duty-cycle“ z.B. wird normalerweise geloggt, wenn BidCos-RF auf „Alles loggen“ konfiguriert ist)
  3. auch die WTs betroffen waren, bei denen „wake-on-radio“ deaktiviert ist, da kein FK verknüpft -> wenn der WT schläft, sollten ihn irgendwelche umherfliegenden Nachrichten nicht belasten - ergo: ich vermute eine nicht unwesentliche Beteilgung der CCU2 selbst, in welcher Form auch immer …
  4. warum hat es ausschließlich die WTs und nicht etwa die Stellmotoren oder andere Geräte Stromverbrauchs-technisch beeinflusst?

Last-but-not-least - die „Lessons learned“ aus der Fehler-Such-Orgie:

  • Ruhe bewahren - soll u.a. heißen: lieber 5 x mehr, ganz entspannt die Anlerntaste drücken und auf „grün“ warten bevor man sich für den WebUI-Knopf „Ignorieren“ entscheidet
  • „Drüberlernen“ hilft nur bedingt - 100% Erfolgsquote bisher z.B. bei nach Batteriewechsel spinnenden FKs
  • wo immer es geht/Sinn macht „wake-on-radio“ abschalten
  • bei Einsatz von CCU + LAN-Adapter ab und an die RSSI-Werte der Geräte betrachten (z.B. über „devconfig“ oder „HM-Companion“) -> gerade wenn man gerne das Interieur anpasst - sprich: Möbel umstellt - bzw. von der Regierung dazu gezwungen wird, :smiley: wird man erstaunliche Abweichungen und damit Optimierungspotential erkennen
  • Finger weg vom „Roaming“!
  • wenn Geräte-Firmware-Updates mehrfach in die Binsen gehen könnte es auf ein tieferliegendes Problem hindeuten
  • Löschen/Konfigurationsänderungen/Updates über „devconfig“ sind erheblich schneller erledigt als über die „normale“ WebUI -> ABER: was dort geklickt und ausgelöst wird findet ohne Gürtel und Hosenträger statt!
  • statt einem vernünftigen Buch einfach mal am Wochenende die Konfiguration der eigenen CCU „lesen“ :o

Eventuell hilft das eine oder andere ja dem einen oder anderen bei der nächsten Fehlersuche.

Cheers
/Jens

Also meine stetige Zeitverschwendung mit HM treibt mich eher in andere Arme. Heute ging mal wieder wenig aber nix war greifbar (eine Statusmeldung) Einmal Neustart und dann war es wieder ok. Es ist nicht oft aber jedes eine Mal ist zu viel.
Kann man eine Elektronik hassen lernen? Definitiv ja!

Ich hasse z.Z. meine FritzBox, die CCU und das RS485 GW.
Die Box macht plötzliche Restarts, da nach ist dann immer das GW offline und nach Reset der CCU (GW ist dann OK) ist dann der Ereignisserver vom IPS-HM-Socket tot.
Grrrr tolle Kombi.
Ach ja mein erster WT hat auch Lowbat gemeldet nach ca 8 Wochen …:eek:
Michael

/sign

Verlust des Default-GWs im internen Netz sorgt ja schon immer für Verwirrung bei der CCU. Mal den „Bist Du da, Internet“-Tweak probiert? Man könnte ja bei instabilem Def.-GW einfach mal die IP der CCU eintragen oder auch gleich 127.0.0.1 (… habe ich bisher noch nicht versucht).
Wenn das Def.-GW weg ist dauert das 1. Verbinden auf die WebUI etwas länger (… weil der Update-Server gesucht wird), aber evtl. trägt es zur Stabilisierung bei, zumindest solange Deine Fritze rumzickt.
Zu Zeiten als ich noch die Fritzchens als Router genutzt habe (ungefähr vor 800 Monden :D) hatte ich 2 Fälle von grober Instabilität: entweder hatte sich einer der Kondensatoren im SV-Teil der Fritz aufgebläht, oder das Billig-Steckernetzteil hat nicht mehr stabil geliefert. Nur so als Ansatz :wink:

Die Fritte ist noch nicht ausgereift. Halt Bananen-Software, reift auf dem Weg zum Kunden :wink: Sie telefoniert nach einem Absturz auch brav nach Hause…Fehlerbericht wird versendet. Naja ist halt eine 6490 :eek:
Ist ist aber das RS485 GW, nicht das RF was immer offline geht wenn der Link weg war.
Werde mal den Internet-Erkennen-Tweak einbauen. Mal sehen ob es hilft.
Und meine Dimmer mit 3 Kanälen kontrollieren, habe da eine böse Vermutung das ich das gleiche Problem habe wie du.
Michael

Ah! O.k.! Nee, mit DOCSIS-Möhren habe ich in Ermangelung eines Kabelanschlusses bisher noch keine Erfahrung sammeln dürfen :rolleyes:

Das mit dem RS485 GW hatte ich so verstanden … und es riecht verdammt nach einem Zusammenhang mit „hasInternet“ :wink:

Kontrolle kann nicht schaden. Wenn allerdings nur ein WT betroffen ist? Als erstes würde ich „wake-on-radio“ deaktivieren (sofern kein FK dranhängt). Der Gag an „w-o-r“ ist ja, dass JEDES Gerät mit aktivem „w-o-r“ aufwacht und zwar völlig unabhängig davon welches andere Gerät den „wake-up-call“ in den Äther trötet. Rein funktionell macht das ja so Sinn, ist aber mit Vorsicht zu genießen.

[OFFTOPIC] Ich habe auch eine 6490 (06.10) hier und da habe ich auch noch nicht 100% alle Probleme gelöst.

Natürliche hängen an allen Drehgriffkontakte… aber vielleicht waren auch nur die mitgelieferten Batterien mau. Mal beobachten.
Michael

Kurzer Ausflug zum eigentlichen Fred-Titel: auch wenn die Low-Bat-Schwelle von „default“ 2,2 V auf z.B. 2,0 V geändert wird, meldet die CCU2 bei einem Wert unter 2,2 V „Low-Bat“. Wieder einmal ein Parameter der rein gar nichts bewirkt :rolleyes:
Ich schätze mal, wenn man es in der XML-description des Aktors direkt ändert, würde es „ziehen“. Zu viel Aufwand für zu wenig Nutzen …