Hallo zusammen,
ich möchte in mein bestehndes System eine tägliche Prüfung des Garagentor_Sensors um 20:00 Uhr ausführen lassen, falls dieses geöffnet ist soll es das Garagentor Automatisch schließen.
Hab schon einige Codeschnippsel mit at probiert leider bewegt es sich nicht.
Hier meine config:
define Garagentor CUL_HM 34D953
setuuid Garagentor 5c7d8884-f33f-118b-0db5-de7aadabb917307d
attr Garagentor .mId 00EB
attr Garagentor IODev CUL_HM
attr Garagentor alias Garagentor bRoL
attr Garagentor autoReadReg 4_reqStatus
attr Garagentor eventMap /on-for-timer 1:Garagentor Taster/
attr Garagentor expert 2_raw
attr Garagentor firmware 2.5
attr Garagentor icon hue_room_carport
attr Garagentor model HM-LC-SW1-PL-CT-R1
attr Garagentor peerIDs 00000000,400FEB04,577F8201,6922EA04,6922EA05,
attr Garagentor room Garage,CUL_HM
attr Garagentor serialNr MEQ1844343
attr Garagentor subType switch
attr Garagentor webCmd Garagentor Taster
define FileLog_Garagentor FileLog ./log/Garagentor-%Y.log Garagentor
setuuid FileLog_Garagentor 5c7d8884-f33f-118b-1642-abad48ad14a2f4a1
attr FileLog_Garagentor logtype text
attr FileLog_Garagentor room CUL_HM
define Garagen_Torsensor CUL_HM 577F82
setuuid Garagen_Torsensor 5c7d8884-f33f-118b-ac3c-471f35e00fc29d8e
attr Garagen_Torsensor .mId 00C7
attr Garagen_Torsensor IODev CUL_HM
attr Garagen_Torsensor actCycle 002:50
attr Garagen_Torsensor actStatus alive
attr Garagen_Torsensor alias Garagen Torsensor
attr Garagen_Torsensor autoReadReg 4_reqStatus
attr Garagen_Torsensor event-on-change-reading state
attr Garagen_Torsensor eventMap closed:geschlossen open:offen
attr Garagen_Torsensor expert 251_anything
attr Garagen_Torsensor firmware 1.0
attr Garagen_Torsensor model HM-SEC-SCO
attr Garagen_Torsensor peerIDs 00000000,
attr Garagen_Torsensor room Garage
attr Garagen_Torsensor serialNr OEQ0424218
attr Garagen_Torsensor subType threeStateSensor
define FileLog_Garagen_Torsensor FileLog ./log/Garagen_Torsensor-%Y.log Garagen_Torsensor
setuuid FileLog_Garagen_Torsensor 5c7d8884-f33f-118b-346e-8154fa05a341b0cf
attr FileLog_Garagen_Torsensor logtype text
attr FileLog_Garagen_Torsensor room CUL_HM
#Pushover-Benachrichtigung wenn Garagen Tor (Roland) geöffnet od. geschlossen wurde
define GaragentorPushover dummy
setuuid GaragentorPushover 5c7d8884-f33f-118b-e968-f3436a9cd9d50c03
attr GaragentorPushover webCmd on:off
define Garagentoroffen notify Garagen_Torsensor {if(Value("GaragentorPushover") eq "on"){my $temp_Status = Value("Garagen_Torsensor");; fhem ("set Pushnachricht msg 'Achtung Garagentor (Roland) Bewegung erkannt' 'Tor ist jetzt: $temp_Status' '' 0 ''")}}
setuuid Garagentoroffen 5c7d8884-f33f-118b-4ad8-e6c4889a99db9f02
[b]#Garagentor täglich um 20 Uhr prüfen ob geschlossen, falls geöffnet schließen
define Garagentor_Roland_Automatik at *20:30:00 {if (Value("Garagen_Torsensor") eq "open") {fhem("set Garagentor on-for-timer 1")} }
setuuid Garagentor_Roland_Automatik 5d0aaa14-f33f-118b-2d1a-d7fc639e54390714[/b]
Vielleicht kann mir einer von euch weiter helfen, wäre um jede Hilfe dankbar.
Beste Grüße
Roland
Poste doch mal ein list, also:
list Garagentor
in FhemWeb und die Ausgabe dann posten.
Ich nehme an (kenne/habe diesen Aktor nicht / aber ähnliche), dass es einen "Switch-Channel" geben müsste:
Garagentor_Sw (falls du "set DeviceName rename NewDeviceName" genommen hast)...
Dann sollte set Garagentor_Sw on bzw. off funktionieren...
Gruß, Joachim
Hier das List vom Gargentor
Internals:
CUL_HM_MSGCNT 2
CUL_HM_RAWMSG A0DEEA41034D953F1123406010000::-86:CUL_HM
CUL_HM_RSSI -86
CUL_HM_TIME 2019-06-20 22:49:47
DEF 34D953
FUUID 5c7d8884-f33f-118b-0db5-de7aadabb917307d
IODev CUL_HM
LASTInputDev CUL_HM
MSGCNT 2
NAME Garagentor
NOTIFYDEV global
NR 161
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:EE - t:10 s:34D953 d:F11234 06010000
peerList Funk_Fernbedienung_01_open,Garagen_Torsensor,Funk_Fernbedienung_02_Btn_03,Funk_Fernbedienung_02_chn-05,
protLastRcv 2019-06-20 22:49:47
protRcv 2 last_at:2019-06-20 22:49:47
protSnd 2 last_at:2019-06-20 22:49:47
protState CMDs_done
rssi_CUL_HM cnt:1 min:-84 max:-84 avg:-84 lst:-84
rssi_at_CUL_HM cnt:2 min:-86 max:-85 avg:-85.5 lst:-86
READINGS:
2019-06-20 22:49:43 CommandAccepted yes
2019-06-20 21:31:08 D-firmware 2.5
2019-06-20 21:31:08 D-serialNr MEQ1844343
2019-06-20 00:19:27 PairedTo 0xF11234
2019-06-20 00:19:29 R-Funk_Fernbedienung_01_open-lgActionType jmpToTarget
2019-06-20 00:19:29 R-Funk_Fernbedienung_01_open-shActionType jmpToTarget
2019-06-20 00:19:30 R-Funk_Fernbedienung_02_Btn_03-lgActionType jmpToTarget
2019-06-20 00:19:30 R-Funk_Fernbedienung_02_Btn_03-shActionType jmpToTarget
2019-06-20 00:19:31 R-Funk_Fernbedienung_02_chn-05-lgActionType jmpToTarget
2019-06-20 00:19:31 R-Funk_Fernbedienung_02_chn-05-shActionType jmpToTarget
2019-06-20 00:19:29 R-Garagen_Torsensor_chn-01-lgActionType jmpToTarget
2019-06-20 00:19:29 R-Garagen_Torsensor_chn-01-shActionType jmpToTarget
2019-06-20 00:19:27 R-pairCentral 0xF11234
2019-06-20 00:19:27 R-sign off
2019-06-20 00:19:27 RegL_00. 00:00 02:01 0A:F1 0B:12 0C:34 15:FF 18:00
2019-06-20 00:19:27 RegL_01. 00:00 08:00 30:06 56:00 57:24
2019-06-20 00:19:28 RegL_03.Funk_Fernbedienung_01_open 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:14 8C:63
2019-06-20 00:19:30 RegL_03.Funk_Fernbedienung_02_Btn_03 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:14 8C:63
2019-06-20 00:19:31 RegL_03.Funk_Fernbedienung_02_chn-05 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:13 8C:33
2019-06-20 00:19:29 RegL_03.Garagen_Torsensor_chn-01 00:00 02:00 03:00 04:32 05:64 06:00 07:04 08:00 09:FF 0A:01 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:06 88:00 89:FF 8A:21 8B:13 8C:33
2019-06-20 22:49:47 deviceMsg off (to CUL_HM)
2019-06-20 22:49:47 level 0
2019-06-20 22:49:47 pct 0
2019-06-20 21:36:37 peerList Funk_Fernbedienung_01_open,Garagen_Torsensor,Funk_Fernbedienung_02_Btn_03,Funk_Fernbedienung_02_chn-05,
2019-06-20 22:49:47 recentStateType info
2019-06-20 22:49:47 state off
2019-06-20 22:49:47 timedOn off
helper:
HM_CMDNR 238
cSnd ,11F1123434D9530201C800000140
mId 0002
peerFriend peerSens,peerVirt
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +34D953,00,00,00
nextSend 1561063787.49181
prefIO
rxt 0
vccu
p:
34D953
00
00
00
mRssi:
mNo EE
io:
CUL_HM:
-84
-84
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO CUL_HM
flg A
ts 1561063787.39317
ack:
HASH(0x4708b00)
EE8002F1123434D95300
rssi:
CUL_HM:
avg -84
cnt 1
lst -84
max -84
min -84
at_CUL_HM:
avg -85.5
cnt 2
lst -86
max -85
min -86
tmpl:
Attributes:
IODev CUL_HM
alias Garagentor bRoL
autoReadReg 4_reqStatus
eventMap /on-for-timer 1:Garagentor Taster/
expert 2_raw
firmware 2.5
icon hue_room_carport
model HM-LC-SW1-PL-CT-R1
peerIDs 00000000,400FEB04,577F8201,6922EA04,6922EA05,
room Garage,CUL_HM
serialNr MEQ1844343
subType switch
webCmd Garagentor Taster
Ok, wohl kein Kanal...
Dann funktioniert er wohl eher wie die Schaltsteckdosen ohne Leistungsmessung...
(macht Sinn)
Ein:
set Garagentor on
bzw.
set Garagentor off
öffnen bzw. schließen das Tor nicht?
Geht es denn über die "angelernten" (gepeerten) Fernbedienung etc.!?
Kannst du aus fhem heraus das Garagentor schalten?
Poste doch auch mal einen deiner "at-Versuche"...
Gruß, Joachim
Hab bereits 2 Fernbedienungen mit dem Aktor gepeered funktioniert auch alles. Ich verwende aber on for Timer 1 anstatt on|off.
Hier ein At Versuch wie bereits im ersten Beitrag enthalten.
define Garagentor_Roland_Automatik at *20:00:00 {if (Value("Garagen_Torsensor") eq "open") {fhem("set Garagentor on-for-timer 1")} }
Wer kann mir helfen?
Gesendet von meinem SM-N950F mit Tapatalk
Ja, sorry hab ich übersehen.
Liegt daran, dass "alles zusammen" gepostet wurde...
Und: besser lists als Auszüge der fhem.cfg posten...
Und: bitte immer in code-Tags...
Liest sich leichter und steckt mehr Info drin...
Also bitte noch ein list vom Sensor...
Funktioniert denn ein:
set Garagentor on-for-timer 1
in FhemWeb!?
Was hast du alles (Attribute etc.) selbst/nachträglich eingetragen?
Und welche Attribute wozu?
Z.B. das event-map...
Wenn du ein:
set Garagentor on-for-timer 1
in FhemWeb eingibst öffne dazu doch mal den Eventmonitor und schaue was tatsächlich passiert...
Was sind das eigentlich alles für verbundene Peers?
Bzw. warum:
Funk_Fernbedienung_02_Btn_03 und Funk_Fernbedienung_02_chn-05
Warum hast du den "Offen/Geschlossen-Sensor" (Garagen_Torsensor) gepeert?
Was soll da passieren?
Wenn du auf die FB drückst, macht der Aktor dann auch nur für 1s an!?
Hast du dazu ein Register im Aktor gesetzt?
Editierst du selbst in der fhem.cfg (besser lassen)...
Gruß, Joachim
Moin,
rssi_CUL_HM cnt:1 min:-84 max:-84 avg:-84 lst:-84
rssi_at_CUL_HM cnt:2 min:-86 max:-85 avg:-85.5 lst:-86
kleiner als -80 kann funktionieren - muss aber nicht. Sagt man immer ...
Es ist nicht unterirdisch, aber könnte auch ein Grund sein warum FHEM nicht an den Aktor senden kann.
Gruß Otto
Nur ne Idee am Rande da ich da auch schon mal drüber nach gedacht habe.
Hast du eine Prüfung, dass das Garagentor immer "frei" ist? Z.b das Auto steht nur halb in der Garage und dann wird das Tor geschlossen (Oder gar Personen unterm Tor).
Nur mein Gedankengang :)
Gruß
Mahlzeit zusammen,
ok soweit bekomm ich momentan mit ach und krach noch alles soweit hin, kann definitiv sein das zuviele Attribute gesetzt sind. Stimmt auch ich fummle da recht viel in der fhem.cfg rum :| schimpft mich noch ihr habt schon recht :)
Wg. der Reichweite das stimmt liegt ziemlich an der Grenze aber funktioniert noch, da ich übers Fhem das Tor mit on-for-timer 1 öffnen und schließen kann.
Das Peering mit dem Sensor hab ich letztens aus dem Grund durchgeführt da ich der Meinung war, hierdurch eine bessere Funkabdeckung erreichen zu können !?
Kann das funktionieren?
Hier das List vom Garagentor Sensor:
Internals:
CHANGED
CUL_HM_MSGCNT 16
CUL_HM_RAWMSG A0D008610577F8200000006010000::-95:CUL_HM
CUL_HM_RSSI -95
CUL_HM_TIME 2019-06-21 10:53:55
DEF 577F82
FUUID 5c7d8884-f33f-118b-ac3c-471f35e00fc29d8e
IODev CUL_HM
LASTInputDev CUL_HM
MSGCNT 16
NAME Garagen_Torsensor
NOTIFYDEV global
NR 164
STATE geschlossen
TYPE CUL_HM
chanNo 01
lastMsg No:00 - t:10 s:577F82 d:000000 06010000
protCmdDel 4
protLastRcv 2019-06-21 10:53:55
protRcv 16 last_at:2019-06-21 10:53:55
protResnd 3 last_at:2019-06-20 23:59:28
protResndFail 1 last_at:2019-06-21 00:56:27
protSnd 4 last_at:2019-06-21 00:56:22
protState CMDs_done_Errors:1
rssi_at_CUL_HM cnt:16 min:-95 max:-87 avg:-89.9 lst:-95
READINGS:
2019-06-19 22:15:51 Activity alive
2018-02-16 16:01:09 D-firmware 1.0
2018-02-16 16:01:09 D-serialNr OEQ0424218
2019-06-21 10:53:55 alive yes
2019-06-21 10:53:55 battery ok
2019-06-21 10:53:55 contact closed (to broadcast)
2019-06-21 10:53:55 recentStateType info
2019-06-21 10:53:55 sabotageError off
2019-06-21 10:53:55 state closed
2019-06-20 22:49:44 trigger_cnt 230
helper:
HM_CMDNR 0
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +577F82,00,00,00
nextSend 1561107235.42425
prefIO
rxt 2
vccu
p:
577F82
00
00
00
mRssi:
mNo 00
io:
CUL_HM:
-93
-93
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_HM:
avg -89.90625
cnt 16
lst -95
max -87
min -95
tmpl:
Attributes:
IODev CUL_HM
actCycle 002:50
actStatus alive
alias Garagen Torsensor
autoReadReg 4_reqStatus
event-on-change-reading state
eventMap closed:geschlossen open:offen
expert 251_anything
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000,
room Garage
serialNr OEQ0424218
subType threeStateSensor
Hier noch der Event Monitor beim setzen von on-for-timer-1
2019-06-21 11:40:11 CUL_HM Garagentor set_Garagentor Taster
2019-06-21 11:40:11 CUL_HM Garagentor deviceMsg: on (to CUL_HM)
2019-06-21 11:40:11 CUL_HM Garagentor level: 100
2019-06-21 11:40:11 CUL_HM Garagentor pct: 100
2019-06-21 11:40:11 CUL_HM Garagentor on
2019-06-21 11:40:11 CUL_HM Garagentor timedOn: running
2019-06-21 11:40:12 Pushover Pushnachricht msg 'Achtung Garagentor (Roland) Bewegung erkannt' 'Tor ist jetzt: offen' '' 0 ''
2019-06-21 11:40:12 CUL_HM Garagen_Torsensor offen
2019-06-21 11:40:13 Pushover Pushnachricht apiRemaining: 7176
2019-06-21 11:40:13 Pushover Pushnachricht lastTitle: Achtung Garagentor (Roland) Bewegung erkannt
2019-06-21 11:40:13 Pushover Pushnachricht lastMessage: Tor ist jetzt: offen
2019-06-21 11:40:13 Pushover Pushnachricht lastAction: -
2019-06-21 11:40:13 Pushover Pushnachricht lastDevice: galaxynote8,Note7,Note8
2019-06-21 11:40:13 Pushover Pushnachricht lastRequest: eaad1013-c53f-4807-b92c-8d2743d1a215
2019-06-21 11:40:13 Pushover Pushnachricht lastResult: ok
2019-06-21 11:40:14 CUL_HM Garagentor deviceMsg: off (to CUL_HM)
2019-06-21 11:40:14 CUL_HM Garagentor level: 0
2019-06-21 11:40:14 CUL_HM Garagentor pct: 0
2019-06-21 11:40:14 CUL_HM Garagentor off
2019-06-21 11:40:14 CUL_HM Garagentor timedOn: off
sollte ich mal mit den Attributen beginnen, diese zu optimieren und bereinigen?
Wg. dem Tor (Lichtschranke) berechtigte Frage von Darkness, wäre noch Verbesserungswürdig aber es ist zu 95% frei und falls etwas dazwischen kommt stoppt das Tor!
Mhhh, wie kann ich den vergrabenen Hund nur finden?
also on-for-timer geht, aber dein Code im at geht nicht?
Deswegen:? eventMap closed:geschlossen open:offen
Geht denn der Perl Code ohne at in der FHEM Kommandozeile?
Was gibt Dir {Value("Garagen_Torsensor")}
zurück.
Gruß Otto
Hallo Otto,
hab jetzt das Problem gefunden durch auslesen des Wertes
{Value("Garagen_Torsensor")}
hier kam als Rückgabe offen
und ich hatte als Parameter open eingestellt diesen Wert hat er dann wohl nicht akzeptiert!
PS.: Meine unötigen Peers hab ich nun auch gleich bereingt inclusive den Garagentor_Sensor vom Aktor entfernt,
da es wohl keine bessere verbindung erzeugt.
Ein weiteres Danke an euch alle, da kann man ja nur noch was lernen :)
Beste Grüße
Roland
Aber entfernt heißt jetzt nicht "nur" aus der fhem.cfg gelöscht!?
Weil das ist Quatsch...
Peers stehen in den Geräten (Register) und das wird von fhem ausgelesen und eingetragen...
D.h. wenn du das Peering nicht per set-Befehl "gelöscht" hast, dann kommen die Einträge wohl wieder: beim nächsten getConfig...
EDIT: wenn du Attribute änderst (gerade eventMap) musst du gegebenenfalls dein at etc. wieder anpassen... Wenn es so läuft... Erst mal lassen...
Gruß, Joachim
Danke an den Hinweis Joachim,
ich hab sie mit dem Befehl im Device peerSmart remove peer1;peer2 entfernt
hatte kürzlich schon solch ein Problem, da sich von der Keymatic ein peer nicht lösen wohlte.
Nach mehreren Versuchen hat es dann auch funktioniert.
Ok, dann entschuldige!
(war wohl weil du zugegeben hast in der fhem.cfg rumzuschreiben ;) )
Wollte nur sicherstellen... ;)
Gruß, Joachim
Idee:
Vielleicht sollte "man" mal noch einen struktuierteren Artikel im Wiki zum Thema "at, notify & co debuggen" machen:
Der Teil vom notify https://wiki.fhem.de/wiki/Notify#Anweisung passt ja analog auch fast für ein at .
Gruß Otto
Wiedermal ot, aber ich selber hab was ähnliches bei mir und stand auch schon vor der Frage, soll ich das Tor irgendwann automatisch schließen.
Was ich sagen will, man muss bedenken zu prüfen ob irgendwas den Weg versperrt oder sich die Finger einklemmen kann.
Ich für mein Teil habe zwar alles mögliche in Betracht gezogen wie ich überprüfen kann ob und in wie weit Gefahr, oder mögliche Blockade des Tor abgefangen werden kann.
- Lichtschranke
- Utraschallsensor
- Lichttaster
- Whatever
Habe zwar noch keine ordentlich Kontrollmöglichkeit und auch noch keine Automatik deswegen, aber ich hab in meiner Steuerung ein kleinen piezo Pieper der vor toraktion (auf/ab) immer erstmal ein paar mal piep.
Nur jetzt so als kleine Anregung
Und sorry fürs ot ;)
Wobei ja im topic steht ,,prüfen"
Sorry auch OT!
Wofür der Aufwand?
Mein Antrieb ist über 20 Jahre alt und bleibt bei einem Hindernis stehen und fährt in die Gegenrichtung! Meine Katze hat es auch schon ohne Kratzer überstanden ;D
Machen das die neuen Antriebe nicht mehr? Hast du beim Herunterfahren das Tor zum Test mal festgehalten?
Nur Interessehalber!
Gruß
Hab ich und der torantrieb ist ein Bosch aus den 80zigern. Der schaltet bei dem Hebel, bei gefühlt 10-15kg ab und um.
Aber das Tor hat auf der Innenseite, Führungen und umlegmechanik, vom regulären Tor. Da wenn den Finger reinsteckst, Is er ab. Und hier springen Kleinkinder rum. ;)
Auch denk ich, kommt die torunterkannte auf dem neuen Autodach extremst uncool.
Ich mein ja nur, der teufel steckt im Detail und ich kenn den ganzen Sicherheitskack aus 15jahre sondermaschinenbau ... da härteste den Einfall so nie abgenommen bekommen.
Zitat von: DasQ am 21 Juni 2019, 18:12:07
Aber das Tor hat auf der Innenseite, Führungen und umlegmechanik, vom regulären Tor. Da wenn den Finger reinsteckst, Is er ab. Und hier springen Kleinkinder rum. ;)
Ahh, ich hab ein Sektionaltor. Also kein Problem :)
Zitat von: DasQ am 21 Juni 2019, 18:12:07
Auch denk ich, kommt die torunterkannte auf dem neuen Autodach extremst uncool.
Ist bei mir ne dicke Gummileiste. Frau hat es auch schon getestet, nichts passiert ;D
Danke!
(set OT off) ;)
Ich unterscheide zwischen FHEM-getriggertem und Schlüsselschalter/Taster (Garagentor-Bordmittel) getriggertem Garagentor Öffnen/Schließen.
Entsprechend umfangreich ist meine Umsetzung.
Ursprung war die Idee eine Lüftungsstellung zu realisieren, ohne zusatzzeug von hörmann kaufen zu müssen und die Kiste in FHEM abbilden und stabil halten zu können.
Vor Produktivschaltung hab ich das Ganze auf nem FHEM-Testrechner durchgespielt, was die Fehlersuche extrem vereinfacht.
Mit HM-Aktor erzeuge ich via FHEM mit "on-for-timer 1" über relais einen simulierten Tastendruck zur eigentlichen Garagentorsteuerung (hörmann sektionaltor)
ich hab ein doif, welches diese Fälle abdeckt:
- Tor schließen/öffnen über bedienstelle (eh klar... und natürlich auch vom moped aus...)
- Lüftungsstellung, wenn innenfeuchte > außenfeuchte (mit hysterese)
- Tor schließen/öffnen aus lüftungsstellung heraus über bedienstelle oder wenn innenfeuchte <= außenfeuchte (mit hysterese)
- Tor schließen bei windgeschwindigkeit > schwelle wenn offen
- Tor schließen um 22 uhr wenn offen
- watchdog zum öffnen/schließen wenn mittelstellung für 1min (mittelstellung wird wg. einklemmschutz angefahren). WD weiß aber nicht, ob Mittelstellung nach auf- oder zufahren war: somit unterscheide ich auch den durch die WD-Aktion eingenommenen Garagentorzustand auf/zu
- Tor schließen, wenn alle Smartphones absent für 30min melden, wenn Tor offen
- Robustheitsabfangen wegen Lüftungsstellung/manueller Bedienung via Schlüsselschalter. von letzterm bekommt FHEM ja nix mit. Das ist etwas tricky.
- Lüftungsstellung mach ich mit 2x mit on-for-timer 1 kurz hintereinander. klappt auch. bis der fall auftritt, dass eine der beiden übers Gateway nicht gestellt werden kann (noch andere Sachen in der Queue oder overload). In dem Fall ist das Tor dann offen. Das fang ich auch ab, da der Lüftungsstellung-state und das reading für auf/zu nicht korrelieren, also wieder zufahren nach x sekunden
- bypass der doif-logik via dummy
Meine 2 HM Neigungssensoren (obere+untere Tor-Sicke) hab ich wg Vetrauenswürdigkeit ersetzt. Einer der beiden hat trotz etlicher Versuche über regsets und anderer Filter/event-min-intervall... nicht nur Neigung, sondern auch sehr sensibel Erschütterungen gemeldet. Resultat war eine von den Sensoren ermittelte Mittelstellung, obwohl das Tor zu war. Nach meiner Logik oben fährt das Teil natürlich auf :-(
Jetzt verwende ich diskrete Kugel-Neigungssensoren pro sicke, identisch diesem thread
https://forum.fhem.de/index.php/topic,50670.msg422947.html#msg422947
(https://forum.fhem.de/index.php/topic,50670.msg422947.html#msg422947)
Top Sache und meine doif-logik funzt sauber mit allen eventualitäten.
Vieleicht dienen meine Infos als Denkanstöße oder Hilfestellung.