tempList.cfg temperatur Profile

[martinp876]

Das Attribut ist der default filename. Wenn im template ein filename angegeben ist hatmdermvorrang.
Wenn du nun ein restore ausführen wird der unterschied zwischen template und fhem gelesenen Registern geschrieben.
Danach, wenn die message load es zulässt kommt ein getconfig.
Fhem schreibt wenn der RT erwacht. Solltest du mit burst arbeiten ist dies sicher tötlich.
Wieviele RTS hast du?

[DecaTec]

Wieviele RTS hast du?

4x TC und 5x RT.

Das mit burst kam mir auch schon in den Sinn. Aber habe schon an verschiedenen Stellen gelesen, dass Burst standardmäßig nicht aktiviert ist.

Der Wert "R-burstRx" steht in allen Devices auf "on": Das sagt doch aber nur aus, dass das Device durch Burst weckbar ist, oder? Dieser Wert lässt sich übrigens nicht mit set <Device> regSet burstRx off abschalten. Das Register wird auf "set_off" gesetzt, ist anschließend  (nach getConfig) wieder "on".
Attribut "burstAccess" ist in keinem Device gesetzt.

Mehr Einstellungen zu Burst, oder wie ich es aktivieren/deaktivieren kann, habe ich nicht gefunden. Kann ich den burst mode gezielt unterbinden?

set HMinfo param -d protCondBurst R-burstRx liefert:

Code Auswählen Erweitern


param done:
param list
    entity              : protCondBurst        |R-burstRx            |
    Buero.Heizung        :  -              |on
    Buero.Thermostat    :  -              |on
    Kueche.Heizung      :  -              |on
    Kueche.Thermostat    : on              |on
    Schlafzimmer.Heizung :  -              |on
    Schlafzimmer.Thermostat :  -              |on
    Wohnzimmer.HeizungFenster :  -              |on
    Wohnzimmer.HeizungTv :  -              |on
    Wohnzimmer.Thermostat :  -              |on


Wenn ich das richtig interpretiere, läuft Kueche.Thermostat im conditional Burst, die anderen Devices nicht. Ich wüsste allerdings nicht, was ich bei diesem Device anders gemacht hätte.

Edit: protCondBurst steht bei allen Devices auf "forced_off" (set HMinfo param -d protCondBurst R-burstRx). Ich habe nun mal burstAccess auf "0_off" gestellt und FHEM neu gestartet. Hat diese einstellung protCondBurst = forced_off  bewirkt?
Ist das die Einstellung, ob Burst verwendet werden soll oder nicht?
Was war da vorher los (siehe oben), so bei protCondBurst bei (fast) allen Devices "-" stand?

[Christian72D]

Code Auswählen Erweitern

define hm HMinfo

Normal ist das bestimmt nicht daß dann folgende Meldung erscheint:

Code Auswählen Erweitern

sumERROR: battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed

Oder?

[DecaTec]

So, noch ein kleines Status-Update, habe gerade wieder etwas herumprobiert.

Nachdem ich burstAccess bei allen Devices auf 0_off gestellt habe und so den Burst-Mode "mit Gewalt" ausgeschaltet habe (zumindest interpretiere ich die Wiki- und Foren-Einträge bzgl. burstAccess so), scheint das nun auch ohne Overload zu funktionieren.
Auch ein Löschen des Attributs in allen Devices lässt den HMlan nicht mehr überhitzen.

Keine Ahnung, was da vorher schief gelaufen ist. Ich dachte eigentlich, das HMinfo selbst auf die Last am HMlan achtet und ggf. das Senden weiterer Befehle verzögert, wenn bereits Last am HMlan vorhanden ist. Das scheint in meinem Fall allerdings nicht wirklich funktioniert zu haben.

Aber eine Frage bleibt noch (trotz langer Suche um Forum und im Wiki):
Was ist der "offizielle" Weg, um den Burst-Modus auszuschalten bzw. einzuschalten?

[Motivierte linke Hände]

Ohne Deine Frage beantworten zu können: Ist ohne burst die Reaktionszeit merklich länger?

[DecaTec]

Ohne Deine Frage beantworten zu können: Ist ohne burst die Reaktionszeit merklich länger?

Jein.
Also ich gehe mal davon aus, dass in meiner ursprünglichen Konfiguration "geburstet" wurde. Hier hatte ich innerhalb von Sekunden einen Overload. Dann heißt es entweder warten, bis sich der HMlan erholt hat oder den HMlan kurz vom Strom trennen (was unpraktisch ist, wenn man nicht zu Hause ist).
Ohne Burst dauert das Umschalten der Heizprofile nun ca. 20 Min., es gibt aber keinen Overload.

Also ja, es dauert länger, was aber immer noch besser ist, also mit einem Overload festzustecken.

[martinp876]

ein Device meldet sich so alle 2,5min. Wenn es sich Meldet werden die Daten übertragen.
Ändert man die desiredtemp wird beim darauffolgenden melden (also nach 5 min) die korrektur gemeldet - der RT hatte das schon 2,5 min eher.

Es kann nun zu Kollosionen kommen, wenn viele RTs sich gleichzeitig melden. Dann werden evtl. nicht alle Daten übertragen, es wird beim nächsten Auswachen wiederholt.
Burstet man viele Devices gleichzeitig kommt es auch zu kollisionen - und zwar sicher. Das warten entzerrt also auch die Situation.

=> wer so etwas burstet ist selbst schuld. So schnell muss man keine templist ändern.

Bei einem Einzelnen Device oder beim testen ist das hilfreich.

Habe gerade eine Korrektur zum Attribut eingecheckt. Das mit HMInfo hat nicht komplett funktioniert.

[DecaTec]

Aber eine Frage bleibt noch (trotz langer Suche um Forum und im Wiki):
Was ist der "offizielle" Weg, um den Burst-Modus auszuschalten bzw. einzuschalten?

Diese Frage habe ich nach wie vor. Gibt es hier einen offiziellen Weg?

Habe gerade eine Korrektur zum Attribut eingecheckt. Das mit HMInfo hat nicht komplett funktioniert.

Was genau wurde hier geändert?

[martinp876]

Was meinst du mit offiziellem weg?
Es liegt bei dir, es zu verwenden wie es dir passt. Burst ist hinreichend in der doku erklärt. Eben nochmal: man kann sofort senden ohne auf das aufwachen zu warten. Device2device Kommunikation braucht burst da ein Sender nie wartet. Die zentrale kann warten.
Du kannst einschalten, dass immer sofort, automatisch mit burst gesendet wird. Ist definitiv nicht empfohlen. Du kannst mit Kommando gezielt burst senden. Nutze ich beim testen, weil es schneller geht. Baue ich nie in Automatismen wie notifies ein. Die müssen warten.
Du kannst warten. Das sollte der normale weg sein, meine ich.
Burst brauchen ein vielfaches der sendekapazitaet der message. Sie verbrauchen Batterie in ALLEN burst sensitiven devices¡, auch wenn sie nicht adressiert werden.

Was genau geändert wurde... Es wurden bugs beseitigt. Die Vorversion war Schrott in Hinsicht auf das einstellen von templistfile. Jetzt hoffe ich, dass es passt. Details im code

[dancatt]

Ich habe das selbe Problem wie im Post
http://forum.fhem.de/index.php/topic,28211.msg354441.html#msg354441

Mit

Code Auswählen Erweitern

set RT regSet burstRx off
lässt sich das nicht setzen. Nach "set_off" geht das Register immer wieder auf den Wert "on".

Ich hoffe mal dass das Attribut "burstAccess" mit dem Wert "0_off" den gewünschten Effekt liefert.

[martinp876]

das Verhalten kann ich bestätigen.
Fakt: Das Ändern des Register wird komplett abgearbeitet und bestätigt. Es hat jedoch einen Erfolg, sprich das Bit bleibt stehen. Ferner bleicht auch der Mode bestehen.
=> Das Register zeigt den Aktuellen Stand an, ist aber nicht (mehr) änderbar.
In den frühen FW- Versionen war es änderbar. Es kann a) an der FW-Version liegen oder b) am peeren/pairen. Das habe ich nicht probiert, kann es also nicht ausschliessen.

Meine Bewertung (auch wenn ich es sowieso nicht ändern kann): schlimm ist dies nicht, man sollte einfach mit der Nutzng von Burst (sowieso) vorsichtig sein.