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

[Otto123]

Schön, dass mein Hinweis geholfen hat.

@Otto123
Könntest Du vielleicht im VCCU-Wiki unter "Virtuelle Kanäle der VCCU" einen Hinweis bzgl. der Sensor-Problematik einfügen!?
Vielleicht mit Querverweis auf den Abschnitt "externe Temperatursensoren" im HM-CC-RT-DN Wiki?

Hab ich versucht, richtig glücklich bin ich noch nicht damit. 

[Paul]

Hab ich versucht, richtig glücklich bin ich noch nicht damit. 

Hallo Otto,

Ich Probier es mal wie ich das Wiki als Anwender verstehe.

Ich hatte vorher einzelne virt. Kanäle für die Fensterkontakte. Erst nach Einrichtung der VCCU und lesen des Wiki kam ich auf die Idee, oh toll dann kannst du alle einzelne virt. Kanäle löschen und sie unter der VCCU vereinen. Vielleicht sollte man im Wiki ausführen für welche ,,andere Zwecke" die Kanäle in der VCCU gedacht sind (ich weiß es immer noch nicht), weil ich würde es nach lesen des Wiki weiterhin falsch machen.

Das ist kein meckern, sondern sollte nur die Sicht eines einfachen Anwenders darstellen.

[Otto123]

Moin,

Ich weiß es auch nicht. Ich bin sicher das weiß niemand. Wo in der Welt gibt es eine Beschreibung für was das Feature eines Gerätes alles gemacht ist?!
Es gibt diese Kanäle in der VCCU und man kann offenbar sagen (ich schreibe dort etwas was ich nicht mal kenne - das löst bei mir Unbehagen aus) das es für Peeren mit Heizungsthermostaten zwecks Einbindung systemfremder Temperatursensoren derzeit nicht geeignet ist.

Gruß Otto

[Beta-User]

Hmmm,
ich hatte das eher als Problem der RT's/WT's begriffen: Alles, was an Taster- (Fenster) bzw. Temperatur-Info von einem anderen Gerät kommt, wird verarbeitet, ganz egal, über welchen Kanal... Will man also einen Fake-Temp. oder Fake-Fensterkontakt bilden, benötigt man dazu je ein virtuelles FHEM-Device pro RT-(Gruppe), beide Kanäle an einem virtuellen Device gehen aber (kombinierter virtueller Fenster- und Temperaturfühler). Die firmware scheint eben darauf optimiert zu sein, mit einer Vielzahl von Gerätetypen zu funktionieren, die sich ihrerseits nicht darum kümmern müssen, den richtigen Kanal zu treffen...

Ohne das jetzt im Detail nachgestellt zu haben, kann aber eine VCCU mit anderen "Abnehmern" nach meinem Verständnis schon sowas wie eine Fernbedienung abbilden, also eine (fast) beliebige Anzahl von Lichtern schalten oder Rolläden. Dazu ist es m.E. schon sinnvoll, zumal der Anwendungfall VCCU eben "nur" einer von mehreren für ein virtuelles HM-Gerät ist (s.o.).

[Otto123]

Dann gehört das aber als Hinweis/Problem beim RT beschrieben und nicht bei der VCCU?!?

[frank]

hallo otto,
das wäre mein vorschlag (kurz und markant):

Die virtuellen Kanäle der VCCU funktionieren nicht als:
1. virtueller Fensterkontakt
2. virtueller Temperaturfühler
3. virtueller HM-CC-TC
4. virtueller TeamLead für Rauchmelder

[Paul]

habe noch was aus 2014 gefunden

zu kurz gesprungen.

noch einmal:

die vccu hat aktuell 3 (in worten DREI) funktionen.

1) das beliebte schalten von IOs, ersatzschalten bei ausfall,.... . Sinnvoll so man mehrere IOs nutzt - insbesondere mit der gleichen HMId.
1a) umschalten eines device von einem IO zu einem anderen. Notwendig bei HMLAN/USB aus protokollsicht

2) terminieren von messages an die Zentrale. Ohne vccu kein endpunkt für messages an dieselbe. Die messages führen zu den beliebten "helpme" meldungen in log. Könnte sein, dass in Zukunft auch auswertungen gefahren werden.
Eigentlich war das der Primäre grund für die VCCU

3) peeren / (virtuelle) kanäle der Zentrale. das peerIODev ist eine fehlgeburt - passt so garnicht. Ist im System nicht darstellbar. nur wenn man eine vccu hat kann man auch Kanäle der vccu einrichten/verwenden/auswerten.
Diese Kanäle unterschieden sich von den "nicht-vccu-virtuellen-kanälen" im protokoll von HMLAN/USB. Sie sind effektiefer, können aber nicht alles (sd-teamlead, virtual-temp,...).

auch das steht im Wiki - (wohl zu weit hinten).

=> ohne vccu läuft das system unsauber/unvollständig definiert. Egal ob man mehrere IOs hat oder nicht.
=> IOs sollten deutlich mehr von einer VCCU kontrolliert werden - aktuell passiert nur das notwendigste (rudi blockiert es noch bei der cul...)


@Phil__
1)IODev ist wurscht
2)IOgrp auf die vccu ausrichten, ggf das prefered device eintragen
==> wiki lesen

[Beta-User]

hallo otto,
das wäre mein vorschlag (kurz und markant):

Die virtuellen Kanäle der VCCU funktionieren nicht als:
1. virtueller Fensterkontakt
2. virtueller Temperaturfühler
3. virtueller HM-CC-TC
4. virtueller TeamLead für Rauchmelder

Das ist zwar etwas verkürzt (weil man zumindest einen FK und Temp-Kanal nutzen könnte), aber diese knackige Darstellung bei der VCCU finde ich gut. Man könnte Abschwächung der generellen Aussage evtl. in eine Fußnote packen.

Dann gehört das aber als Hinweis/Problem beim RT beschrieben und nicht bei der VCCU?!?

Da die Einschränkung m.E. nicht VCCU-spezifisch ist, gehört der Hinweis, dass man nicht mehr als eine Gruppe von RT/WT-Geräten mit einem virtuellen Gerät (aber für FK+Temp) peeren kann, in jedem Fall auch bei diesen Artikel rein (bzw. dem zentralen Abschnitt, sollte es nur eine Verweisung geben).

[frank]

ausserdem:
bitte kein "freundliches, unauffälliges, harmloses, dezentes" grün. =>  feuriges rot. 

[Otto123]

ok hab den Vorschlag von Frank umgesetzt. Den Eintrag für RT/WT-Geräten sollte jemand machen der wenigsten ein solches Gerät besitzt. Ich verstehe nur in etwa was das Problem überhaupt ist... 
Und ich bin ungern Ghostwriter 

[Beta-User]

ok hab den Vorschlag von Frank umgesetzt. Den Eintrag für RT/WT-Geräten sollte jemand machen der wenigsten ein solches Gerät besitzt. Ich verstehe nur in etwa was das Problem überhaupt ist... 
Und ich bin ungern Ghostwriter 

Thx, habe die Box noch etwas verschoben und dann (als RT-DN-User ) hier was eingefügt:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren

Bei den WT's gibt dazu gar keinen Hinweis, die Frage wäre noch, ob etwas in der Art dann noch hierher gehört: https://wiki.fhem.de/wiki/HomeMatic#Besondere_Entities
Da steht nur was nebulös: "Die spezifischen Anwendungen sind im entsprechenden Kapitel..."

[frank]

@beta-user
bist du sicher, dass ein virtueller tempfühler zwei oder mehr rt bedienen kann? hier kommt es doch auf timing an, oder?

als virtueller tc user weiss ich, dass pro virtuellem tc nur ein unabhängiges timing möglich ist. da jeder zu bedienende reale hm-cc-vd unabhängiges timing benötigt, muss dem entsprechend jeder hm-cc-vd seinen eigenen virtuellen tc bekommen.

ich habe zwar keine rt, aber vom verständnis her würde ich auch keine sensibel reagierende timing funktion (virt temp) mit zusätzlichen virtuellen fk verknüpfen.

zumindestens ich lese diese möglichkeiten aus dem wiki.

[Beta-User]

Hmmm,

komplizierte Frage, es kommt vermutlich auch drauf an, welches IO man nutzt (und ob die timing-optimierten Module eingesetzt werden).
Ich hatte diese Dinge vor langer Zeit mal ausgetestet, damal noch mit einem orginal-CUL mit "normaler" firmware + Standard-CUL_HM, aber keine besonders detaillierte Erinnerung mehr daran.
Vor einiger Zeit habe ich einen Teil der direkten Peerings entfernt (für Türen), weil es da zwar sinnvoll ist, sofort eine Message zu haben (=>Licht), das aber erst zeitlich entkoppelt später an den RT zu senden. Dabei ist mir aufgefallen, dass das HM-MOD-PI (bzw. HMUARTLGW) diese Message sofort mit burst rausschickt, man aber eben mehrere CUL_HM-Geräte benötigt, wenn man die Teile entkoppeln will. In dem Zusammenhang habe ich dann wieder ein paar kleinere Tests mit der Temperatur gemacht.

Im Detail kann ich das nicht abschließend beurteilen, gehe aber fast davon aus, dass auch die Temp-Infos sowieso auch mit burst gesendet werden und die timing-Themen keine große Rolle spielen... Da das aber Batterie kostet, habe ich die ganze Konstruktion - abgesehen vom "verzögerten" FK - als für mich untauglich verworfen (ich bin aber auch mit dem Regelverhalten soweit zufrieden und habe im einzigen kritischen Raum einen WT hängen).

Nach dem, was du schreibst, wäre das aber eventuell für andere IO's ein Thema.

Vorsichtshalber beschränke ich das im Wiki gerne auf "ein RT, ein virtueller Temp+FK". Das sollte passen, oder?

[frank]

temperatur wird nicht mit burst gesendet.
voraussetzung für das von fhem berechnete timing ist natürlich auch ein entsprechendes io. umgekehrt ist ein passendes io aber nicht hinreichend für ein korrektes timing.

hier kannst du dein wissen ziehmlich umfassend erweitern. der ausgewählte post dient nur zum einstieg, also ein paar mehr lesen: https://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806

Vorsichtshalber beschränke ich das im Wiki gerne auf "ein RT, ein virtueller Temp+FK". Das sollte passen, oder?

ich würde meinen (wie gesagt, ich habe nur virtuelle erfahrungen, besonders beim virtuellen fk):

virtueller temperaturfühler:
pro rt ein unabhängiger virtueller temperaturfühler, bestehend aus einem virtuellen device plus einem untergeordneten channel. also nur ein peering des virtuellen fk. es können natürlich mehrere virtuelle temperaturfühler mit der selben realen temperatur gefüttert werden.

virtueller fk:
pro realem fk ein unabhängiger virtueller fensterkontakt, bestehend aus einem virtuellen device plus einem untergeordneten channel. dieser eine virtuelle channel kann mit mehreren (50?) unterschiedlichen realen deviceChannels gepeert werden.

[Beta-User]

Danke für die Rückmeldung, habe das jetzt mal so im Wiki geändert:

Für jeden separat zu steuernden HM-CC-RT-DN kann nur je ein Kanal eines virtuellen Devices als Temperatur- bzw. Fensterkontakt genutzt werden. Insbesondere die virtuellen Kanäle der VCCU eignen sich nicht dazu, mehrere HM-CC-RT-DN unabhängig voneinander anzusteuern! Zusammenfassen kann man aber immer je einen Fenster- und Temperatursensor pro virtuellem Gerät; es ist weiterhin möglich, mehrere HM-CC-RT-DN mit einem (reinen) virtuellen Fensterkontakt zu peeren.

Ich habe wenig Erfahrung mit virtuellen Temp-Sensoren, wie gesagt, das paßt bei mir auch mit den internen soweit , dafür halt etwas mehr mit den Türkontakten . Den link habe ich mir mal abgelegt, für den Fall, dass ich mein timing-Wissen doch noch wesentlich erweitern muß...
Ansonsten müßte ich das mit den FK's bei Gelegenheit mal weiter austesten, da gibt es noch ein paar, die man noch optimieren kann (wg. Rolladen-Öffnen hab ich da die Verzögerung auch verkürzt, das Peering von den RT's zu trennen steht noch aus ).