Ich habe bei 2 HM-TC-IT-WM-W-EU die WindowRec Kanäle mit jeweils einem virtuellen Kanal der VCCU gepeert.
Sobald ich ein Fenster öffne reagieren beide HM-TC-IT-WM-W-EU.
wer kann helfen?
Wohnzimmer:
Internals:
DEF 3AE74703
NAME Wohnzimmer_Thermostat_WindowRec
NOTIFYDEV global
NR 393
NTFY_ORDER 50-Wohnzimmer_Thermostat_WindowRec
STATE last:WohnzimmerTuer:closed
TYPE CUL_HM
chanNo 03
device Wohnzimmer_Thermostat
peerList WohnzimmerTuer,
READINGS:
2019-01-07 10:48:23 R-sign off
2019-01-07 10:48:23 RegL_01. 00:00 08:00
2019-01-07 10:48:23 RegL_03.WohnzimmerTuer 00:00 04:32
2019-01-07 10:48:24 RegL_07.WohnzimmerTuer 00:00 05:18
2019-01-07 11:24:54 peerList WohnzimmerTuer,
2019-01-07 11:24:54 state unknown
2019-01-07 23:35:33 trigLast WohnzimmerTuer:closed
2019-01-07 23:35:33 trig_WohnzimmerTuer closed
helper:
regLst ,3p,1,7p
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-TC-IT-WM-W-EU
peerIDs 00000000,42312402,
stateFormat last:trigLast
Internals:
DEF 42312402
NAME WohnzimmerTuer
NOTIFYDEV global
NR 372
NTFY_ORDER 50-WohnzimmerTuer
STATE set_postEvent closed
TYPE CUL_HM
chanNo 02
device VCCU
peerList Wohnzimmer_Thermostat_WindowRec,
READINGS:
2019-01-07 11:36:55 peerList Wohnzimmer_Thermostat_WindowRec,
2019-01-07 23:35:33 state set_postEvent closed
helper:
count 16
regLst
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
shadowReg:
tmpl:
Attributes:
model CCU-FHEM
peerIDs 3AE74703,
webCmd postEvent open:postEvent closed
Badezimmer:
Save config ?
Floorplans
Tablet
1
Batterie
CUL_HM
CUL_WS
DWD
FHT
FS20
Fenster/Tueren
HUB
HUEDevice
Homekit
Keller
Klack
LGTV
Logi
PID
PIONEERAVRZONE
Plots
icoRollo Rollo
SB_PLAYER
Tanken
Telefon
Unsorted
Wettervorhersage
Wohnzimmer
harmony
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
DEF 32180403
NAME Bad_Thermostat_WindowRec
NOTIFYDEV global
NR 398
NTFY_ORDER 50-Bad_Thermostat_WindowRec
STATE last:BadFenster:closed
TYPE CUL_HM
chanNo 03
device Bad_Thermostat
peerList BadFenster,99999803,
READINGS:
2019-01-07 10:47:42 R-sign off
2019-01-07 10:47:42 RegL_01. 00:00 08:00
2019-01-07 10:47:43 RegL_03.99999803 00:00 04:32
2019-01-07 10:47:43 RegL_03.BadFenster 00:00 04:32
2019-01-07 10:47:44 RegL_07.99999803 00:00 05:18
2019-01-07 10:47:43 RegL_07.BadFenster 00:00 05:18
2019-01-07 11:24:53 peerList BadFenster,99999803,
2019-01-07 11:24:53 state unknown
2019-01-07 23:28:40 trigLast BadFenster:closed
2019-01-07 23:28:40 trig_BadFenster closed
helper:
regLst ,3p,1,7p
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-TC-IT-WM-W-EU
peerIDs 00000000,42312401,99999803,
stateFormat last:trigLast
Internals:
DEF 42312401
NAME BadFenster
NOTIFYDEV global
NR 401
NTFY_ORDER 50-BadFenster
STATE set_postEvent closed
TYPE CUL_HM
chanNo 01
device VCCU
peerList Bad_Thermostat_WindowRec,
READINGS:
2019-01-07 11:36:55 peerList Bad_Thermostat_WindowRec,
2019-01-07 23:28:40 state set_postEvent closed
helper:
count 6
regLst
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
shadowReg:
tmpl:
Attributes:
model CCU-FHEM
peerIDs 32180403,
verbose 5
webCmd postEvent open:postEvent closed
Eventmonitor:
2019-01-07 23:50:36 CUL_HM Wohnzimmer_Thermostat CMDs_pending
2019-01-07 23:50:36 CUL_HM Wohnzimmer_Thermostat_WindowRec trigLast: WohnzimmerTuer:open
2019-01-07 23:50:36 CUL_HM Wohnzimmer_Thermostat_WindowRec trig_WohnzimmerTuer: open
2019-01-07 23:50:36 CUL_HM WohnzimmerTuer set_postEvent open
2019-01-07 23:50:38 CUL_HM Wohnzimmer_Thermostat_Weather humidity: 39
2019-01-07 23:50:38 CUL_HM Wohnzimmer_Thermostat_Weather T: 22.0 H: 39
2019-01-07 23:50:38 CUL_HM Wohnzimmer_Thermostat_Weather temperature: 22.0
2019-01-07 23:50:38 CUL_HM Wohnzimmer_Thermostat_Weather absFeuchte: 7.6
2019-01-07 23:50:38 CUL_HM Wohnzimmer_Thermostat_Weather dewpoint: 7.4
2019-01-07 23:50:43 CUL_HM Wohnzimmer_Thermostat CMDs_done
2019-01-07 23:50:52 CUL_HM Bad_Thermostat_Climate desired-temp: 12.0
2019-01-07 23:50:52 CUL_HM Wohnzimmer_Thermostat battery: ok
2019-01-07 23:50:52 CUL_HM Wohnzimmer_Thermostat batteryLevel: 2.8
2019-01-07 23:50:52 CUL_HM Wohnzimmer_Thermostat desired-temp: 12.0
2019-01-07 23:50:52 CUL_HM Wohnzimmer_Thermostat measured-temp: 22.0
2019-01-07 23:50:53 CUL_HM Wohnzimmer_Thermostat_Climate desired-temp: 12.0
2019-01-07 23:51:02 CUL_HM Bad_Thermostat battery: ok
2019-01-07 23:51:02 CUL_HM Bad_Thermostat batteryLevel: 2.7
2019-01-07 23:51:02 CUL_HM Bad_Thermostat desired-temp: 12.0
2019-01-07 23:51:02 CUL_HM Bad_Thermostat measured-temp: 21.5
Ich nehme an, Du hast "bauartfremde Fensterkontakte", die Du daher als virtuelle Devices anbinden willst !?
Dann solltest Du dafür JEWEILS ein virtuelles HM-Device mit Kanal anlegen und damit peeren.
Zumindest bei Temperatursensoren habe ich die Erfahrung gemacht, dass es bei Verwendung mehrerer Kanäle an einem virtuellen Device gerne zu den von Dir beschriebenen Effekten kommt, und eine korrekte Funktion nicht gegeben ist.
Zitat von: Hollo am 08 Januar 2019, 09:16:33
Dann solltest Du dafür JEWEILS ein virtuelles HM-Device mit Kanal anlegen und damit peeren.
Zumindest bei Temperatursensoren habe ich die Erfahrung gemacht, dass es bei Verwendung mehrerer Kanäle an einem virtuellen Device gerne zu den von Dir beschriebenen Effekten kommt, und eine korrekte Funktion nicht gegeben ist.
Danke, das hat geklappt.
Dann ist aber eine VCCU mit Kanälen unbrauchbar.
Zitat von: Paul am 08 Januar 2019, 10:26:31
Danke, das hat geklappt.
Dann ist aber eine VCCU mit Kanälen unbrauchbar.
Hierfür: ja
Für "nur" Taster die eine Rückmeldung wollen bzw. wenn sie die nicht bekommen "mal rot blinken": schon brauchbar ("nur" ein Device bzw. sogar nur ein Kanal/Button davon für [beliebig] viele Taster)
Gruß, Joachim
Zitat von: MadMax-FHEM am 08 Januar 2019, 11:03:04
Für "nur" Taster die eine Rückmeldung wollen bzw. wenn sie die nicht bekommen "mal rot blinken": schon brauchbar ("nur" ein Device bzw. sogar nur ein Kanal/Button davon für [beliebig] viele Taster)
Gruß, Joachim
Das habe ich auch. Aber warum kann man dann in der VCCU bis zu 50 Kanäle anlegen??????????
Zitat von: Paul am 08 Januar 2019, 11:11:32
Das habe ich auch. Aber warum kann man dann in der VCCU bis zu 50 Kanäle anlegen??????????
mehr nicht?
auf wieviele chn möchtest du es denn begrenzt haben und warum?
Zitat von: frank am 08 Januar 2019, 11:29:40
mehr nicht?
auf wieviele chn möchtest du es denn begrenzt haben und warum?
Ich hatte wie oben beschrieben 2 Kanäle in der VCCU eingerichtet und diese auch unterschiedlich gepeert.
Da dadurch aber ein Fehlverhalten auftritt, und ich dieses nur durch weitere separate virt. Kanäle beheben kann reicht wohl ein
virtueller Kanal in der VCCU
die virtuellen chn in der vccu sind ja erst viel später entstanden und für andere zwecke gedacht.
virt temp/tc/fk/teamlead.... gab es ja auch schon vorher.
irgendwelche spezis haben dann die vccu chn dazu "missbraucht" und falsche gerüchte gestreut, dass es funktionieren würde. oder wie bist du auf die idee gekommen?
Zitat von: frank am 08 Januar 2019, 11:51:14
oder wie bist du auf die idee gekommen?
in dem ich Wiki gelesen habe. 8) Und wenn dort steht man kann bis zu 50 channels einrichten, dachte ich, man kann jeden channel peeren ohne das sie sich gegenseitig stören.
Zitat von: Paul am 08 Januar 2019, 12:29:56
in dem ich Wiki gelesen habe. 8) Und wenn dort steht man kann bis zu 50 channels einrichten, dachte ich, man kann jeden channel peeren ohne das sie sich gegenseitig stören.
Hi,
Ich habe zwei Taster Btn mit zwei Channels der VCCU gepeert und reagiere dann auf die virtuellen Knöpfe. funktioniert prima und beeinflusst sich nicht.
Gruß Otto
Zitat von: Otto123 am 08 Januar 2019, 12:58:10
Hi,
Ich habe zwei Taster Btn mit zwei Channels der VCCU gepeert und reagiere dann auf die virtuellen Knöpfe. funktioniert prima und beeinflusst sich nicht.
Gruß Otto
.
Ich hatte 2 Channels der VCCU als "Fensterkontakte" mit jeweils 2 Thermostat_WindowRec gepeert (also VCCU-Channels senden) und
beide Channels schalten unabhängig beide Thermostat_WindowRec.
Habe es jetzt wie @Hollo geschrieben hat gelöst. Einen Kanal aus der VCCU gelöscht und einen neuen virt. Kanal(separat) angelegt
Zitat von: Paul am 08 Januar 2019, 13:11:41
.
Ich hatte 2 Channels der VCCU als "Fensterkontakte" mit jeweils 2 Thermostat_WindowRec gepeert (also VCCU-Channels senden) und
beide Channels schalten unabhängig beide Thermostat_WindowRec.
Habe es jetzt wie @Hollo geschrieben hat gelöst. Einen Kanal aus der VCCU gelöscht und einen neuen virt. Kanal(separat) angelegt
Hab ich gelesen ;D
Ich wollte was zu deiner letzen Bemerkung sagen, weil Du so rüberkommst: Im Wiki steht quatsch und wozu braucht man 50 Channel wenn man sie nicht nutzen kann.
Die Welt ist bunt! ;D ;D ;D
Zitat von: frank am 08 Januar 2019, 11:51:14
die virtuellen chn in der vccu sind ja erst viel später entstanden und für andere zwecke gedacht.
virt temp/tc/fk/teamlead.... gab es ja auch schon vorher.
irgendwelche spezis haben dann die vccu chn dazu "missbraucht" und falsche gerüchte gestreut, dass es funktionieren würde. oder wie bist du auf die idee gekommen?
@Otto123
Hallo Otto,
kann sein das ich etwas barsch reagiert habe, aber ich wollte niemanden "missbrauchen" und bin nur auf die Idee gekommen, weil ich das Wiki gelesen habe und dachte virtuelle Kanäle (ob nun VCCU oder separat) sind das gleiche.
Leider weiß ich nicht für welche Zwecke die virtuellen Kanäle der VCCU sind.
ZitatLeider weiß ich nicht für welche Zwecke die virtuellen Kanäle der VCCU sind.
also doch missbraucht. :)
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?
Zitat von: Hollo am 08 Januar 2019, 22:14:52
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. ::)
Zitat von: Otto123 am 08 Januar 2019, 22:47:42
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.
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
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.).
Dann gehört das aber als Hinweis/Problem beim RT beschrieben und nicht bei der VCCU?!?
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
habe noch was aus 2014 gefunden
Zitat von: martinp876 am 02 November 2014, 20:05:33
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
Zitat von: frank am 09 Januar 2019, 08:47:36
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.
Zitat von: Otto123 am 09 Januar 2019, 08:38:47
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).
ausserdem:
bitte kein "freundliches, unauffälliges, harmloses, dezentes" grün. => feuriges rot. :)
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 :D
Zitat von: Otto123 am 09 Januar 2019, 10:05:59
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 :D
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..."
@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.
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?
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 (https://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806)
ZitatVorsichtshalber 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.
Danke für die Rückmeldung, habe das jetzt mal so im Wiki geändert:
ZitatFü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 ;D . 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 ::) ).
ZitatZusammenfassen 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.
Zitat von: frank am 09 Januar 2019, 16:34:23
nach dem motto: geiz ist geil? :)
::) ;D ;D ;D
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 ;) .
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).
@frank
Aus gegebenem Anlaß (https://forum.fhem.de/index.php/topic,98964.msg924245.html#msg924245) hole ich den Post hier nochmal hoch.
Im Wiki ist derzeit zu finden:
Zitat6. 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 (http://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806) 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?
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.
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...
Zitat von: Beta-User am 29 März 2019, 12:20:53
...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.