Shelly DoorWindow2: Status an HomeMatic

Begonnen von OiledAmoeba, 11 November 2022, 21:21:52

Vorheriges Thema - Nächstes Thema

OiledAmoeba

Moin,
ich hoffe, dass das hier richtig ist, sonst bitte verschieben.

Gegeben sind:
HomeMatic Heizkörperventil (nicht: hmIP! Hier: HM-CC-RT-DN), welches über CUL_HM angebunden ist
CUL (nanoCUL, CUL, CUN, CUNO, whatever, Hauptsache es kann das HM-Protokoll und das Ventil kann über das Modul CUL_HM angebunden werden)
Shelly DoorWindow 2 (per MQTT2-Device angebunden und Template "shellydw" zugewiesen)
VCCU (für die virtuellen CUL-Geräte, siehe VCCU in der Wiki)

Unsere Hausverwaltung hat die Wohnungen nummeriert nach Lage, daher habe ich mich in meiner Phantasielosigkeit dafür (laut Mietvertrag 01/02) und den vierten Raum entschieden, daher 010204. Der "Code" ist aber euch überlassen und muss nur hexadezimal (0-9,A-F), sechsstellig und einzigartig sein.

1. Fensterdummy für das Modul CUL_HM erstellen:
defmod bzWin_Virt CUL_HM 010204
attr bzWin_Virt modelForce VIRTUAL

erstellt ein virtuelles Gerät und
defmod bzWin_vW CUL_HM 01020403

erstellt den für die Kommunikation mit der Fenstererkennung des Heizkörperthermostat notwendigen Kanal 3.

2. Fensterdummy mit dem Kanal für die Fenstererkennung des Heizkörpers "verheiraten"
set bzWin_vW peerChan 0 CUL_bz.Heizung_WindowRec single set


3. Notify, welches auf den Shelly reagiert und den Fensterdummy ansteuert:
defmod n_bzWin_vW notify Badfenster:doorWindow.* {\
my $status=ReadingsVal("Badfenster","doorWindow","");;\
$status=$status eq "close"?"closed":"open";;\
fhem("set bzWin_vW postEvent ".$status)\
}


Da der Fensterdummy kein "echter" Dummy ist, sondern ein CUL-Dummy, übernimmt die VCCU den Befehl und gibt ihn an die Heizung, Kanal Window_Rec, weiter.

Hier ist die Stolperfalle: Der Shelly sendet im Reading doorWindow die Status "open" und "close", HM erwartet aber "open" und "closed". Wenn man das Reading von doorWindow einfach durchreichen würde, wird der Heizkörper zwar auf "Fenster offen", aber nie wieder auf normal gestellt. Meine if-Konstruktion prüft also auf "close", macht daraus ein "closed" und alles andere wird "open". Nicht weiter schlimm, denn doorWindow kann nur "open" und "close" annehmen ;-)

Man könnte auch auf den state des Shelly gehen, denn das Template schreibt auch schon "close" auf "closed" um. Allerdings ergänzt das Template auch "tiltet", was Homematic wiederum nicht versteht. Ich hab mich daher für das Reading doorWindow entschieden, das sieht mir hier am passendsten aus.

Viel Spaß beim Nachmachen ;-)
Gruß
Florian

Jail auf XigmaNAS (freeBSD); CCU2 mit CULv3, nanoCUL868 und JeeLink-Clone; div. FS20-Komponenten; andFHEM; div. hm- und hmip-Komponenten; div. IT+

Beta-User

Moin.

Habe das shellydw so angepaßt, dass eigentlich gleich das "übliche" closed rauskommen sollte. Wäre super, wenn du das testen könntest.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files