HM-CC-RT-DN: BurstXmit - Stromverbrauch?

[Beta-User]

Bin nicht so recht sicher, aber ich glaube, an der Stelle jagst du Phantome. Die Burst-Anweisung kommt doch - so wie ich es verstanden habe - immer vom "Sensor" (also Fensterkontakt WT uä.) bzw. wird eben von der Zentrale aus ausgelöst. Damit braucht man am Thermostat eigentlich nichts zu ändern, es sei denn, er müßte einen anderen RT aufwecken. Da macht Zwangsburst aber vermutlich Sinn...

[M_I_B]

... dann haben wir aneinander vorbei geredet ...

Ich bin davon ausgegangen, das die Thermostate so lange auf einen ext. Burst (von einem FK oder Zentrale) hören, so lange das Register auf ON steht. Weiterhin bin ich davon ausgegangen, das bei einer Änderung des Registers im Thermostat auf OFF die Thermostaten eben nicht mehr jedesmal aufwachen, wenn von ext. eine ge'Burstete Nachricht die Runde macht. ALso habe ich mich daran begeben, die HalloWach- Pille in den Thermostaten auf OFF zu stellen um dann feststellen zu können, ob die Batterien dann länger durchhalten.

Aber so wie es ausschaut lässt sich dieses Register, obwohl vorhanden, nicht verändern (aus welchen Gründen auch immer).

BTW:
Der problematische Aktor funktioniert wieder wie er soll. Das Teil steckt ja in einem Hutschinengehäuse nebst 16A Relais und Netzteil (24V ~/= Versorgung). Ich hatte das dann ausgebaut und hier auf dem Tisch mit dem Labornetzteil versorgt. Nach einigen Reset- Versuchen nebst Abklemmen der Versorgung hat der sich wieder gefangen; keine Ahnung was das war.
In dem Zusammenhang fiel mir auch ein komisches Verhalten des daneben befindlichen 4CH Hutschinenaktors auf. Also wollte ich den ebenfalls zur Sicherheit reseten. Meine Überraschung war groß, als auch der sich nicht reseten ließ! Taste von CH1 festhalten bis blinkt, aber der blinkte nur einmal kurz auf und das war's; Reset nicht möglich. Erst nach Ab- und Anklemmen der Versorgung nebst einigen Versuchen war auch der wieder zur Mitarbeit zu bewegen.

Da beide im Zählerschrank stecken und beide zeimlich durch den Wind waren, vermute ich mal eine heftige Spannungsspitze, welche bei beide Aktoren den Speicher zermatscht haben. Anders kann ich es mir im Moment nicht erklären.

Netter Nebeneffekt: Im Eventlog ist deutlich mehr Ruhe eingekehrt. Vielleicht haben die einfach in ihrem Wirrkopp wild drauf los geplappert und somit quasi das Funknetz annäherend zum Erliegen gebracht, was auch die anderen Probleme mit Timeouts u.s.w. erklären würde. Im Moment herrscht zumindest Ruhe und alles scheint wieder zu funktionieren. Hatte sogar Zeit, dem SONOFF Basic einen Transistor und einen R zu spendieren; nu geht auch die rote LED (https://forum.fhem.de/index.php?topic=82634)

[frank]

Also meine Thermostaten habe ich im Februar vor zwei Jahren gekauft. Habe sie an Tag 1 auf Burst gesetzt und meine Batterien sind immer noch die ersten.

das hört sich aber an, als wären sie vorher auf burst=off.

ich habe nur die alten hm-cc-tc, bei denen man burst=on/off setzen kann.

[frank]

in diesem thread hat jemand 5 rt auf burst=off gesetzt.
https://forum.fhem.de/index.php/topic,21089.msg146490.html#msg146490

[M_I_B]

... kann ich mir nicht vorstellen ... Bei keinem der hier im Betrieb befindlichen Thermostate (FW 1.4), auch nicht bei dem mehrfach Reseteten und auch nicht bei dem heute frisch aus der Schachtel genommenen lässt es sich abschalten ...

[frank]

entweder ein bug in fhem, oder
dein scc schafft es mit der fw nicht.

vielleicht hast du auch jetzt nach der reparatur mehr erfolg.
tue dir trotzdem den gefallen und flashe die ts_culfw.

[M_I_B]

... wenn Du mir sagst, was ts_culfw ist, wo es das gibt und wo die Vorteile gegenüber a_culfw liegen, versuche ich das auch gerne noch mal. Ich glaube aber nicht an Probleme mit dem SCC oder dem UFO; mit beiden geht es nicht, alle anderen Register lassen sich aber sehr wohl "verbiegen".

Ich habe gerade ein Bildschirm- Video gemacht; liefer ich nach, sobald ich die Teile, in denen nichts passiert, herausgenommen habe ...

EDIT: Anbei der Vorgang als Ablauf, in dem die Zwischenzeiten, in denen nichhts passiert ist, herausgeschnitten wurden. DIe ganze Nummer hat insg. etwa 4 Minuten gedauert

[frank]

https://forum.fhem.de/index.php/topic,81718.msg737816.html#msg737816

[M_I_B]

... na super  Da sagt ein Tester schon, das er selbst schon Probleme hat, da durchzusteigen; wie soll ich das dann?!?

Es ist für mich nicht zu erkennen, welches die aktuelle FW ist und welche für die SCC notwendig ist. Zudem las ich was über irgend ein Zwischenbau, damit die SCC überhaupt laufen... Das ist ein bisschen viel Unsicherheit, um das an einem Lifesystem zu testen ...

[martinp876]

Es ist schon cool, wenn immer wieder von den Anwendern und Einsteigern erklärt wird, wo die Probleme liegen und wo nicht.
Wie schon gefühlt 1000 mal erklärt: Ein IO welches keinen Timestamp unterstützt wird nie 100% arbeiten. Es wird je nach System 85-98% der normalen und 80-90% der Konfiguratinsabeiten unterstützen. Wem das reicht, ok. Untersuchungen gibt es keine mehr.
Schönes Video - aber es zeigt nicht was passiert ist.
Ich meine, dass es nicht möglich ist, als admin das System im Griff zu haben, wenn man nicht ein paar Protokollgrundsätze verstanden hat (schon vor Jahren im Einsteigerdoc erklärt). Um es nutzen zu können stellt FHEM einiges zu Verfügung. Auch das ist dokumentiert und sollte von jedem bedient werden können.
Also mache dir einmal die Arbeit und verstehe, dass das Device die Protokoll Instanz der HM Devices ist. Dass daher auch dort die Protokollereignisse erfasst werden. Dass man mit einem clear msgevents das "nullen" kann, dann konfiguriert (oder sonst was) und nun in den Internals proto.... sehen kann, ob etwas los was. Dass HMInfo eine Zusammenfassung über das HM-System liefert und man auch dort alles "Nullen" kann.

So, wenn du nun also nachweisen kannst, dass es keine Protokoll-Probleme gibt (dein unscharfes Video zeigt eine Internal - ein Eventlog ist deutlich kleiner und besser!!!) dann (erst) können wir weiter sehen.
Aus deinem Video kann man zumindest erkennen, dass das Device seine Seriennummer neu sendet. Entweder hast du die Config-Taste gedrückt oder dein Device hat einen Reset gemacht. Leider im Video nicht zu sehen. Sollen wir raten, was du machst oder kannst du auch sinnvolle  komplette Infos liefern?

[M_I_B]

... sorry Martin, aber auf so arrogantes Gesülze erwartest Du doch sicherlich keine Antwort... oder doch?

[martinp876]

Nein, sinnvolle Auswertungen und Infos!

[M_I_B]

... ich wollte eigentlich darauf nicht mehr reagieren, aber meine Frau meinte vorhin, ich solle mich nicht ebenso verhalten; recht hat sie (wie so oft)...

Jeder hier, wie auch ich, weiß Deine Kompetenz in Sachen FHEM zu schätzen; Du hast nicht nur mir schon oft aus einer Sackgasse geholfen und dafür sind wir Dir sicherlich allesamt dankbar. Das heißt aber nicht, das jeder hier, ich zumindest, Deine Art und Weise zu schätzen vermag, wie Du hier auf recht arrogante Art mit den Fragenden resp. jenen unter Deinem Kenntnisniveau i.d.R. umgehst.
Ich habe nicht zum ersten mal den Eindruck, das es der harten Kern hier am liebsten hätte, wenn dieses Forum ein geschlossenes System wäre, um unter sich zu bleiben und die ach so nervigen Anfänger mit ihren ach so weit unter Eurem Niveau angesiedelten Problemchen, die sich zudem und vollkommen natürlich oft wiederholen, möglichst weit weg bleiben...
Ein Forum wie Dieses hat nun mal als grundlegende Eigenschaft inne, das sich Anfänger mit Null Vorkenntnissen hier Hilfe erhoffen. Wenn man das nicht möchte, dann sollte man solch ein Forum nicht online stellen oder sich einfach einen geschlossenen Bereich schaffen, in dem die Nerfer keinen Zutritt haben und sich hier einfach raus halten.

Zum Thema:
Wie ich mehrfach schrieb, besteht das Problem mit dem nicht löschbaren Registerwert nicht nur mit einem SCC, sondern auch mit einem original HM-LAN-Gateway. Zudem sind davon alle 10 im Betrieb befindlichen Thermostate betroffen, ebenso wie Werksneue, bei denen dieser Registerwert per Werkseinstellung bereits auf ON steht; ich habe noch 5 verpackte, fabrikneue Thermostate hier liegen, die ich gerne auch noch darauf hin untersuchen kann, wenn's denn was bringen würde...
Wie ich ebenfalls mehrfach schrieb, lassen sich alle anderen Register- Werte problemlos ändern, auch im Bulk und auch via SCC.
Also liegt es Deiner Meinung nach daran, das weder das HM-LAN-Gateway noch der SCC in der Lage ist, diesen, und nur diesen speziellen Register- Wert nicht ändern zu können? Sorry, aber diese Behauptung halte ich schlichtweg für dummes Zeug ...

Abschließend:

So, wenn du nun also nachweisen kannst, dass es keine Protokoll-Probleme gibt (dein unscharfes Video zeigt eine Internal - ein Eventlog ist deutlich kleiner und besser!!!) dann (erst) können wir weiter sehen.

Ich will und muss nichts nachweisen. Meine Kompetenzen reichen nicht aus, um hier explizit Protokollprobleme nachweisen zu können, wenn sie denn existent sind. Wenn ich das könnte, bräuchte ich hier nicht um die Hilfe von Dritten ,,betteln".
Und das dieses kleine Video Deinen Ansprüchen nicht genügt, ist ebenfalls klar und war auch nicht dafür gedacht, diesem Anspruch gerecht zu werden; für Dich würde ich natürlich ein Video in UHD generieren ^^ Der einzige Anspruch dieses Videos war und ist, den zeitlichen Verlauf der Events darzustellen und ggf. ein ,,aneinander vorbei Reden" zu verhindern... Nicht mehr und nicht weniger.

Entweder hast du die Config-Taste gedrückt oder dein Device hat einen Reset gemacht.

Wenn das Drücken der Config- Taste am Ergebnis irgend einen Unterschied generiert, hätte ich es mit Sicherheit erwähnt. Da ich es aber nicht erwähnt habe, macht es im Ergebnis auch keinen Unterschied. Wenn man alles erwähnen soll, was keine Auswirkungen auf das Ergebnis hat, würde das eigentliche Problem wohl jedesmal gnadenlos untergehen...

[frank]

weitere rt auspacken, macht keinen sinn.
am besten ist das sniffen der raw messages beim setzen des registers, wie im wiki homematic sniffen beschrieben.

[frank]

am besten natürlich mit dem hmlan, da ein falsches timing dann nicht die ursache sein kann.