MAX! Fensterkontakt als Schalter für Dunstabzugshaube

Begonnen von thburkhart, 01 Oktober 2020, 17:57:31

Vorheriges Thema - Nächstes Thema

thburkhart

Hallo,
ich steuere meine MAX-Thermostate in jedem Raum über MAX Fensterkontakte.

Nun hat der Kaminkehrer reklamiert, dass die Dunstabzugshaube in der Küche nur eingeschaltet werden darf, wenn das Küchenfenster offen ist. Ich solle eine entsprechende Vorrichtung installieren  lassen, die dies sicherstellt.

Ich brauche dazu also Fensterkontakt, der  -falls geschlossen- mittels eines  WLAN-Schalters die Abzugshaube ausschaltet.

Meine Frage ist nun, ob der vorhandene MAX-Schalter verwendet werden kann ;z.B. über MQTT und meinen vorhandenen IO-Broker.

Beste Grüße

Thomas
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

dirk.k

Ich lese alle MAX Informationen für FHEM mittels 868MHz  NANO_CUL mit.
Dazu kommt das CUL_MAX als FHEM-Device.
Offene Fensterkontakte erfasse ich damit auch.
Wenn die Information in FHEM erst mal drin ist, kann man alles damit schalten (ich nehm SonOff Tasmota WLAN Steckdosen)
Der CUL hängt per USB am FHEM-Server im Keller und reicht gerade so durch das ganze EFH.
Ob es ein SignalESP auch tut habe ich noch nicht probiert. Der wäre frei platzierbar.
Aber die Küche ist ja meist recht zentral gelegen.

thburkhart

vielen Dank für den Hinweis..

auch ich habe die Schalterinformation in FHEM.
Was ich nicht weiß, wie genau ich diese Information an einen SonOFF-Schalter weiterreiche. Einen solchen habe ich sogar noch rumliegen.

gibt es dazu irgendeine genauere Anleitung
Beste Grüße

Thomas
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

Wzut

#3
Zitat von: thburkhart am 01 Oktober 2020, 18:53:55
gibt es dazu irgendeine genauere Anleitung
Platz 1 -> https://forum.fhem.de/index.php/topic,19621.0.html
Platz 2 -> command.ref zu notify / DOIF

und vor einigen Monaten : https://forum.fhem.de/index.php/topic,112021.0.html
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

shamal2008

Hello,

ich habe sowas mit meinen Aqara-Sensoren gemacht - allerdings für die Therme im Badezimmer. Sicherheitshalber hängt der Dunstabzug auch auf einem Shelly, sodass er sozusagen "stromlos" gemacht werden kann, wenn es denn sein sollte.

(([sw.kue.dunstabzug:state] eq "on")
and ([sw.bz.theme:state] eq "on")
(set sw.bz.therme off)
        (set MaLaBot message @CO-Schutz aktiv - Therme ist aus!)
DOELSE (set sw.bz.therme.on)
(set MaLaBot message @#Heizung ist wieder an)


Vielleicht hilft euch das für den Anfang,
lg aus Wien,
shamal2008
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

dirk.k

Bevor ich abfing "ordentlich" mit notify usw zu arbeiten, hab ich das einfach im userreading eingebaut:

tmp:onoff.* {
  if(ReadingsVal("$NAME","onoff",0) == 1 ) {
    fhem("set Sonoff_S20_01 0") ;
    return "auf"
  };
},



Ist zwar einfach und funktioniert aktuell auch, wird aber irgendwann unübersichtlich.
Außerdem wurde mir bereits gesagt, so etwas gehöre nicht ins userreading.

Wzut

@dirk.k, ist schon ein bissel gruselig .... ich würde mir auch keine set Kommandos in userreading bauen :)
Aber ganz schlimm ist in meinem Augen diese Perl->FHEM->Perl Geschüttel mit fhem("set , sowas sehe ich hier im Forum verdammt oft,
warum nicht viel eleganter einfach bei Perl bleiben und CommandSet benutzen ?
Anyway, es wird OT, mir stellt sich allerdings die Frage ob der liebe schwarze Glücksbringer mit Zylinder & Leiter überhaupt so eine Software Lösung akzeptiert ?
Kein FHEM oder Bat leer -> keine Abschaltung der Haube. IMHO gibt es da fertige Schaltungen zu kaufen die das simpel Wire coded machen. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

dirk.k

#7
Ich versuche derzeit mir die Kommandos in den Userreadings abzugewöhnen und diese zurückzubauen.
Anfangs wusste ich noch nichts von der besten Vorgehensweise. Es ist einfach, funktioniert und ich habe nur 1 Objekt.
Erst die Reaktion auf meine Fragen mit Codeschnipseln hier im Forum ließ mich ahnen, dass dies nicht best Practice ist.
(Auch habe ich noch nicht den wirklichen/funktionalen Nachteil verstanden, wenn Kommandos im Userreading stehen ... )
Gibt es einen Guide für die empfohlene Vorgehensweise, der das erwähnt?
Über Kommentare dazu würde ich mich hier freuen: https://forum.fhem.de/index.php/topic,114717.0.html

Da ich mir die meisten Funktionen aus Beispielen zusammenstückeln musste und meine Programmierkenntnisse nicht existent sind, erkenne ich die Grenzen zwischen FHEM & Perl nicht mal.  Für Unterstützung bei der Codebereinigung wäre ich echt dankbar.
Da es hier ziemlich oft Anmerkungen zur Code-mischung gibt und ich das Chaos in meiner Konfiguration erahne, werde ich das wohl mal in einem eigenen Thread behandeln.

rudolfkoenig

Zitat(Auch habe ich noch nicht den wirklichen/funktionalen Nachteil verstanden, wenn Kommandos im Userreading stehen ... )
userReadings sind dazu da, um benutzerspezifische Readings zu setzen.
Falls man Befehle nach einem Event ausfuehren will, dann tut man das mit notify, watchdog, DOIF, etc.

Es ist zwar moeglich mit Hilfe der userReadings FHEM-Befehle auszufuehren, aber man (Sprich wir, der Support) erwartet das nicht, und zaehlt damit fuer mich als Hack. D.h. es gibt wenig Erfahrung mit Problemen/Nebeneffekten, und diese werden im Zweifel auch nicht behoben.