HM-SEC-SCo => LED ausschalten

Begonnen von Bastel-Frank, 27 November 2016, 15:09:37

Vorheriges Thema - Nächstes Thema

Cluni

Ein Wunschzettel wäre toll! Ich würde gerne die rote LED geziehlt blinken lassen in gewissen Abständen, wenn das Fenster geöffnet ist, aber eine Taupunktberechnung innen/außen zum Ergebnis kommt, dass das Lüften kontraproduktiv ist. Da würde sich die rote LED als Warnelement (z.B. kurzes Aufblitzen alle 10s) wirklich anbieten...  8)

Wie warnt ihr davor? Möglich ist ja auch noch die TTS-Ausgabe und/oder irgendeine Push-Message aufs Handy. Aber so eine Möglichkeit direkt am Ort des Geschehens wäre natürlich am Besten. Man könnte dann ja auch nach 5min ohne Reaktion einfach den Rollladen schließen. :P Aber ich schweife vom Thema ab und werde OT.

Pfriemler

Der Wunsch krankt wie bei vielen anderen Geräten an der fehlenden Dualität (m.W. ist der Regensensor der einzige Sensor, der einen von außen schaltbaren Aktorkanal (Sensorheizung) besitzt). eq3 kennt sonst fast nur Aktoren oder Sensoren.
Die Sensoren sind also zumeist als Batteriegeräte nicht von außen aufweckbar (eigentlich gut, weil das sehr zu Lasten der Batterielebensdauer ginge. Einzig der Modus Rotblinken ließe sich theoretisch im Rahmen einer Quittierung einschalten, also wenn der SCo zyklisch oder wegen Zustandsänderung eine Meldung absetzt.
Was ginge: FHEM könnte die Quittierung aktiv blockieren, also etwa die Taupunkte innen und außen zyklisch berechnen und damit ein Flag setzen, ob dem SCo quittiert werden sollte: also Du machst Fenster auf und guckst: grün ok, bei rot lieber gleich wieder schließen.
Ich habe das mal experimentell mit meinem Garagentor gemacht: ein Short auf einer Fernbedienung wurde von dieser mit grün = zu oder rot = auf quittiert, ein long hat dann den Antrieb gestartet. Gelöst habe ich das praktisch über das peering mit einem virtuellen Kanal (vccu oder dummy), bei denen man ja anders als bei realen Geräten per attr peerIDs die Peerpartner direkt setzen kann.
Hat sich aber praktisch nicht bewährt, auch wegen ständiger Meckereien der HM-peerChecks und Co.
Jm2c.

via Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Cluni

Dank dir für die Antwort - hatte mir schon gedacht, dass das nur über Trixereien möglich ist. Und das mit den Meckereien in den PeerChecks würde mich irgendwann auch tierisch nerven... :D

andies

Also das sieht dämlich aus, erfüllt aber seinen Zweck.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Pfriemler

Das sieht in der Tat "dämlich" aus. Dann lieber Kappe ab, ein paar Mal mit einem dicken schwarzen Edding tupfen und Kappe wieder drauf. So bleibt eine geringe Restlichtmenge, die als Diagnose auch hilfreich sein kann. Den Knopf drückt man nach erfolgter Durchkonfiguration ja eigentlich nie wieder.

Aber jeder wie er mag.  ;D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."