Funkverkehr bei Statusabfrage ja oder nein??

[Matsch]

Bei anderen HmIP-Geräten kann man die internen DVs sehr wohl löschen, ganz normal in der DV-Übersicht (z.B. BROLL). Ist schon manchem zum Verhängnis geworden.
Und was den State betrifft, kann das schon einen Unterschied machen. Frage ich mit Value() ab, muss das nicht unbedingt der aktuelle Status sein, der evtl. von der DV geändert wurde.

Ich fürchte nur, jetzt ist der TO komplett verwirrt...

[Tyfys]

Lösche die lieber nicht, ist umständlich die wieder hinzubekommen.

Hatte ICH eh nicht vor.

Dann DV bearbeiten und im oberen Bereich auf löschen drücken.

So weit war ich noch gar nicht gegangen

[Baxxy]

Die DV zur Systemtaste (PS/PSM) ist nicht zum Löschen vorgesehen. Der Tasterkanal kann auch nur eine einzige DV speichern, man könnte also mit der Taste einen Rollladen per DV "bedienen", aber dann nicht mehr die PS/PSM selbst.

[Baxxy]

M.W. ist bei HmIP .State() identisch zu .Value().

Man kann mit .State() nicht den IP-Aktor anfunken um den Status zu bekommen.

Bin mir aber aktuell nicht sicher ob es gar nicht geht (irgendein Error) oder ob einfach nur der Wert aus dem Cache geholt wird. Gefunkt wird jedenfalls nicht.

[Matsch]

M.W. ist bei HmIP .State() identisch zu .Value().

Dann wäre die Abfrage des Kanalstatus aber in den Fällen falsch, wenn der Kanal durch eine DV verändert wurde. Das war ja das, was ich anfangs zum Ausdruck bringen wollte.
Dann wäre es doch möglich, dass der Cache-Wert noch auf einem identischen Wert steht, die Abfrage dazu führt, dass kein Kommando gesendet wird, aber der Kanal in Wirklichkeit durch eine DV verändert doch anders steht. Dann würde man ein notwendiges Schalten leider verhindern, oder?
Klar sendet der Aktor eine Message zum neuen Status des Kanals, aber es gibt wohl eine Zeitlücke, in der der Sendebefehl verloren gehen kann, wenn man den Status abfragt vor dem Senden.
War mir bisher auch nicht so ganz bewußt - auch wenn die Lücke nicht sehr groß ist, sie scheint zu existieren.

[Baxxy]

auch wenn die Lücke nicht sehr groß ist, sie scheint zu existieren

Man könnte die Lücke auch "wegmachen".
Die "Lückengröße" hängt an den Einstellungen für Eventverzögerung/Zufallsanteil des Statuskanals.

Hab jetzt nochmal auf den Analyzer gelunscht...
Ein .State() auf einen STATE-Datenpunkt (HmIP) zeigt keinerlei Kommunikation, genau wie ein .Value()

Je nachdem wie oft da was geschalten werden soll würde ich wohl den Schaltbefehl ungeprüft raushauen.
Nutzt man nur einen virt.Kanal (A), lässt (B) und (C) auf "AUS" sowie die Verknüpfungslogik auf default "OR" dann korreliert (A) mit dem Statuskanal und man kann das so nutzen wie im Scriptbeispiel auf Seite 1.

[Matsch]

Wegmachen kannst du sie nicht, auch ohne Verzögerung dauert die Übertragung durchaus 500ms. Und wenn gerade der CS hoch ist oder Sendewiederholungen nötig sind, noch länger.

[hel400]

zunächst D A N K E für alle Antworten.

Und um die Bedenken wegen Kanälen und Script auszuräumen, hier noch ein paar Hintergrunddetails:

1) Das Ganze wird deshalb mit Script (anstatt WebUI) gemacht, weil ich damit mehrere Infrarot-Heizpanele schalte und zwar abhängig von der gerade zur Verfügung stehenden Photovoltaik-Energie, ist also für WebUI viel zu umfangreich.

2) Baby-Modus ist NICHT mehr aktiviert aber diese (insgesamt 6) Steckdosen haben keine DVs und werden auch nur ausschließlich über dieses eine Script geschaltet - daher kann ich ohne Bedenken explizit auf Kanal 3 gehen und alles passt.

Wie gesagt, danke nochmals, mr ging es vor allem um die Frage ob bei der Statusabfrage gefunkt wird oder nicht.