Peering-Probleme: HM-TC-IT-WM-W-EU mit virtuellen Device

[frank]

Zusammenfassen kann man aber immer je einen Fenster- und Temperatursensor pro virtuellem Gerät;

nach dem motto: geiz ist geil? 

werde ich zumindestens niemandem empfehlen, auch wenn es bei dir scheinbar läuft.

[Beta-User]

nach dem motto: geiz ist geil? 

Yep, (u.a. FHEM-) Geräte sparen ist eines meiner Hobbys....
Aber du hast recht, man sollte nicht auf die Ausnahmen hinweisen (va., wenn man nicht genau weiß, wie lange das ggf. funktioniert), sondern es eher "in die richtige Richtung" vereinfachen.
Habe daher die Ausnahmen jetzt generell weggelassen, wer noch Fragen hat, sollte es halt selbst ausprobieren .

[Beta-User]

So, nachdem ich jetzt alle direkten Peerings bei den Türen vorhin aufgelöst habe, noch eine Rückmeldung zur Frage, was jetzt bei virtuellen Fensterkontakten geht und was nicht. Meine Geräte haben alle die aktuellste firmware, also die RT's  V1.5, der WT V1.4.

- Die RT's können _nicht_ unterscheiden zwischen den verschiedenen Kanälen eines virtuellen Geräts; also ist es nicht möglich, Gruppen zu bilden und dann je einen virtuellen Kanal _desselben_ Geräts mit einer HMId zu nutzen, dazu benötigt man daher mehrere.

- Der WT kann das aber, jedenfalls grundsätzlich: getestet habe ich zwei virtuelle Buttons. Der WT hat nur auf Btn_2 reagiert (mit dem er single gepeert war), nicht auf Btn_1; zwei RT's dagegen haben auf beide Btn reagiert, obwohl die nur single gepeert waren mit Btn_1.

- Ergo: Mehrere Empfänger/Gruppen scheint auch zu gehen, es, haben alle noch die open/closed-Infos erhalten (wenn auch vom "falschen" Kanal); mehr Empfänger als 3 habe ich nicht getestet, würde aber annehmen, dass auch das ginge.
Mir reichen 2-3 (vermutlich peere ich die 2 anderen RT's nicht mehr mit dem Türkontakt, die logisch noch am WT hängen; die bekommen dann ja eh' die Info von dort (muß ich noch verifizieren).

[Beta-User]

@frank
Aus gegebenem Anlaß hole ich den Post hier nochmal hoch.

Im Wiki ist derzeit zu finden:

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:

define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0));; fhem "set wz_vT_Sensor1 virtTemp $T" } 

Fertig.
Sollte es Probleme geben, dass der RT des Öfteren wieder auf seine eigenen Messwerte wechselt, so sollte das Attr cyclicMsgOffset im Virtuellen Kanal beachtet werden. Näheres dazu ist ca. ab hier im Forum zu finden.

Irgendwie will mir das nicht recht einleuchten.
Zum einen ist mir nicht verständlich, warum man das mit einem at macht - gibt es keine Aktualisierung, dann würde immer der alte Wert da reingeschrieben, die Info ist also nie aktueller, wie wenn man ein notify nutzt. Hat das ggf. was mit der internen Funktionsweise des virtuellen CUL_HM Kanals zu tun?
Zum anderen: hat der DS18B20 irgendwann mal was gemessen, kommt der default nie zur Anwendung, weil dann das Reading einen Wert hat. Man müßte also zusätzlich einen watchdog oä. haben, der den Wert löscht, wenn der Sensor länger "weg" ist. So ist - wenn nichts im statefile steht - nur die Zeit überbrückt, bis die erste Messung erfolgt. Oder verstehe ich da was falsch?

[frank]

ein at halte ich an dieser stelle ebenfalls für "suboptimal".
der virtuelle tempfühler muss ja "nur" mit neuen/veränderten werten gefüttert werden.
am sinnvollsten ist sicherlich eine kombi aus notify und event-on-change. allerdings nutze ich selber auch keine virtuellen tempfühler. erfahrungen habe ich nur mit virtuellen tc zum setzen der ventilstellung der hm-cc-vd. die arbeitsweise sollte aber ähnlich sein: zyklisches senden eines wertes zu exakt definierten zeitpunkten.

das genaue verhalten könnte man ja mit einmaligem manuellem setzen beobachten.

meinst du den defaultwert beim readingsval?
der sollte ja nur in "ausnahmefällen" zum tragen kommen. ein sinnvoller defaultwert ist immer gut, mindestens zum vermeiden von warnungen im log.

zur erkennung eines "defekten" sensors gibt es ja "bessere" methoden: zb 98_monitoring.

[Beta-User]

Danke für deine Einschätzung. Dann werde ich bei Gelegenheit "auf Verdacht" mal das Wiki von at auf notify umstellen, wenn sich nicht zwischenzeitlich jemand wehrt.
Das mit event-on.. dürfte sinnvoll sein, je nachdem, wie oft Daten reinkommen.

Wäre natürlich schön, wenn das mal jemand mit Eigeninteresse und einem gewissen Durchblick mal testen könnte, ich habe da selbst ja - wie Otto - auch keine wirklichen Aktion drin.

Ja, der default 20.0 bei ReadingsVal war gemeint gewesen. Der kommt aber ja nur dann wirklich zum Tragen, wenn gar kein Readinginhalt da ist. Zum Hintergrund: in einem der jüngeren Threads hatte mal jemand gemeint, der default würde genommen, wenn es keine Aktualisierung gäbe. Wo diese "Weisheit" herkam, kann ich nicht sagen, aber irgendwo in den Untiefen des Web findet man ja so allerlei Dinge...

[Hollo]

...Wäre natürlich schön, wenn das mal jemand mit Eigeninteresse und einem gewissen Durchblick mal testen könnte, ich habe da selbst ja - wie Otto - auch keine wirklichen Aktion drin...

Bin momentan zeitlich knapp, versuche das aber die Tage mal abends bei mir umzustellen.
Habe zumindest 2 Thermostate, die ich immer per externem/virtuellem Temp.-Sensor mit Werten versorge.