[gelöst]Virtueller Fensterkontakt beeinflusst auch nicht gepeerte Heizungen

[locodriver]

Ich habe virtuelle Fensterkontakte angelegt, die ein "komisches" Verhalten an den Tag legen:

Wenn ich das Badfenster öffne, so wird nicht nur die Badheizung beeinflusst sondern auch das Wohnzimmer wird auf Frostschutz gestellt.

Die Config sieht so aus:

Badfenster:

Code Auswählen Erweitern

define BD_Fenster CUL_HM 149xxx

attr BD_Fenster .devInfo 910101
attr BD_Fenster .stc 80
attr BD_Fenster IODev HMLAN1
attr BD_Fenster actCycle 028:00
attr BD_Fenster actStatus alive
attr BD_Fenster autoReadReg 4_reqStatus
attr BD_Fenster eventMap /tilted:gekippt/open:offen/closed:geschlossen/
attr BD_Fenster expert 2_full
attr BD_Fenster firmware 2.0
attr BD_Fenster fp_ETW 26,596,0,
attr BD_Fenster model HM-SEC-RHS
attr BD_Fenster peerIDs 00000000,
attr BD_Fenster room 004Bad
attr BD_Fenster serialNr IEQxxx
attr BD_Fenster subType threeStateSensor


BD_Kontakt, zum Auslesen des Status' und zum Verknüpfen mit dem Heizungsmodus "Sommer"; damit wird im Sommerbetrieb die Weitergabe von Informationen des Fensters an die Regler unterbunden und ein Öffnen wird erst nach 3 Minuten "gemeldet", damit bei kurzem Öffnen die Heizung nicht sofort zu- und wieder aufmacht:

Code Auswählen Erweitern

define BD_Kontakt DOIF ([BD_Fenster] ne "geschlossen" and [Betriebsart_ab_jetzt] ne "Sommer") (set virtual_BD_Fenster postEvent open)\
DOELSEIF ([BD_Fenster] eq "geschlossen" and [Betriebsart_ab_jetzt] ne "Sommer")(set virtual_BD_Fenster postEvent closed)\
DOELSEIF ([Betriebsart_ab_jetzt] eq "Sommer")(set virtual_BD_Fenster postEvent closed)
attr BD_Kontakt cmdState offen|geschlossen|Sommer
attr BD_Kontakt disable 0
attr BD_Kontakt do always
attr BD_Kontakt room 004Bad
attr BD_Kontakt wait 120:0:0


virt. Kontakte:

Code Auswählen Erweitern

define virSEC CUL_HM 22xxxx
attr virSEC IODev HMLAN1
attr virSEC expert 2_full
attr virSEC model virtual_11
attr virSEC msgRepeat 0
attr virSEC room 085System
attr virSEC subType virtual
attr virSEC webCmd press short:press long


define virtual_BD_Fenster CUL_HM 22xxxx04
attr virtual_BD_Fenster expert 1_on
attr virtual_BD_Fenster model virtual_1
attr virtual_BD_Fenster peerIDs 27xxxx03,
attr virtual_BD_Fenster room 085System
attr virtual_BD_Fenster webCmd postEvent open:postEvent closed

Die peerID 27xxxx03 ist der Badregler.

Habt ihr eine Idee, was da schief läuft? Es sieht so aus, als wenn der virt. Kontakt mit allen Heizungen pepeert wäre, dem ist aber nicht so. Oder muss ich die virt. Kontakte (irgendwie) anders definieren?

Anbei noch ein Screeshot (ca. 16:18 habe ich das Badfenster geöffnet und sowohl Bad als auch Wohnzimmer gehen auf Frostschutz).

Vielen Dank Uwe

[martinp876]

Stelle sicher, dass du die register aller beteiligten gelesen hast.
Dann pruefe wer gepeert ist. Mache es einzeln oder ueber das system mit hminfo:
Autoreadreg in allen devices auf 5 setzen.
In hminfo alle msgevents loeschen, wegen der uebersicht.
Autoreadreg in hminfo ausloesen.
Mit protevents pruefen, wenn es fertig ist.
Dann peerxref ansehen, wer mit wem gepeert ist.

[stromer-12]

Ich habe das auch schon festgestellt, die Regler werten scheinbar nur das Device und nicht den Channel aus.
Ich habe bei mir für jeden virtuellen Kontakt für die Heizkörper je ein virtuelles Device mit unterschiedlicher HMID angelegt.

[locodriver]

@Stromer: D.h. vom virtuellen Fensterkontakt zum virtuellen Regler und dann weiter zum realen Regler? Das wird ja ganz schön aufwendig...

Meine Vermutung liegt eher im Bereich der virt. Kontakte - möglicherweise ist es besser diese in zwei getrennten Devices anzulegen und nicht als Kanäle in einem...?

Momentan bin ich etwas zu eingespannt, um das unmittelbar auszuprobieren.

@Martin: Danke für die Hinweise, werde ich sobald als möglich durchgehen.

Uwe

[stromer-12]

Ich habe virtuelle Fensterkontakte zum entkoppeln der realen Fensterkontakte.

Gesendet von meinem GT-I9295

[locodriver]

Ich auch, s. erster Post. Wie hast du diese definiert?

Uwe

[stromer-12]

Deinen Virtuellen Kontakt

Code Auswählen Erweitern

define virSEC CUL_HM 22xxxx
define virtual_BD_Fenster CUL_HM 22xxxx04
die 22xxxx muss je Heizkörpergruppe eindeutig sein, da die 04 (Channel) nicht beachtet wird.

Ich habe aktuell 2 Heizkörpergruppen und da hatte ich auch dein Problem.
Im Obergeschoß das Fenster geöffnet und unten ging die Heizung mit aus,
da ich 2 Fensterkontakte auf als 2 Channel definiert hatte.

[locodriver]

Da muss man erstmal drauf kommen... Danke! Werde das anpassen.

Uwe

[martinp876]

Sicher ein fw lapsus. Fenster Kontakte haben nur einen Kanal, da hat der Entwickler schlampig gearbeitet, was in der hmrealitaet kein Problem ist. Nutzt man es extended klappt es eben nicht.
Beim remote Kanal ist das korrekt, Kanäle werden beachtet.

[Hollo]

Ich habe das auch schon festgestellt, die Regler werten scheinbar nur das Device und nicht den Channel aus.
Ich habe bei mir für jeden virtuellen Kontakt für die Heizkörper je ein virtuelles Device mit unterschiedlicher HMID angelegt.

Die Erfahrung habe ich bei der Verwendung von externen Temperatursensoren über virtuelle HM-Devices gemacht.
1 virtuelles Device mit 2 Kanälen kam dann immer durcheinander, wenn ich die unterschiedlichen Tempwerte an die 2 verschiedenen Heizungen geben wolte.

[martinp876]

Als Faustregel zum bug: wenn die Sender device typisch nur einen Kanal haben wertet der Empfänger dies nicht aus. Typisch hat ein Fenster Kontakt und ein Thermostat nur einen Kanal Empfänger die genau dafuer gemacht sind achten nicht auf den Kanal, muss eh eins sein.

[locodriver]

Also Quintessenz: für jeden einzelnen Virtuellen Kontakt in solchen Fällen ein eigenes Device anlegen!?

[martinp876]

Wenn es ein Fenster Kontakt sein soll, ja