Mein ursprünglicher Gedanke ist, öffnet sich die Tür soll das Licht angehen.
Der Türkontakt ich wie folgt definiert.
define Flur.HM CUL_HM 3FB7A6
attr Flur.HM IODev myCUL
attr Flur.HM actCycle 001:05
attr Flur.HM actStatus alive
attr Flur.HM alias Haustürkontakt
attr Flur.HM autoReadReg 4_reqStatus
attr Flur.HM devStateIcon open:fts_door_open closed:fts_door
attr Flur.HM expert 2_full
attr Flur.HM firmware 1.0
attr Flur.HM group Sensoren
attr Flur.HM icon scene_stairs
attr Flur.HM model HM-SEC-SC-2
attr Flur.HM room Flur
attr Flur.HM serialNr MEQ1135604
attr Flur.HM stateFormat {if (ReadingsVal("Flur.HM","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Flur.HM","contact","")}}
attr Flur.HM subType threeStateSensor
Das notify...
define FensterleuchteNotify notify Flur.HM { if (Value ("Flur.HM") eq "open") {fhem ("set Fensterleuchte on")} else {fhem ("set Fensterleuchte off")} }
auch habe ich es mit ... probiert.
define FlurLicht notify Flur.HM:state.*open { if (Value("Fensterleuchte") eq "off") { fhem ("set Fensterleuchte on") } }
Funktioniert aber Beides nicht.
Öffne ich die Tür erscheint unter readings open oder closed. Auch ein manuelles Absetzen von set Fensterleuchte on funktioniert.
Nur das notify nicht.
Irgendeine Idee ?
Danke
wenn die Lampe auch Homematic ist, dann würde ich diese direkt peeren ...
dann funktioniert es auch ohne FHEM völlig autonom
Ist eine einfache Elro.
probier bitte
define FensterleuchteNotify notify Flur.HM:.* { if (Value ("Flur.HM") eq "open") {fhem ("set Fensterleuchte on")} else {fhem ("set Fensterleuchte off")}}
Funktioniert leider auch nicht.
schau in den EventMonitor wie das Tür-öffnen-Event genau aussieht. Danach kannst du dann dein Notify stricken. Oder die Ausgabe des EventMonitor hier posten wenn du nicht klar kommst.
attr Flur.HM stateFormat {if (ReadingsVal("Flur.HM","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Flur.HM","contact","")}}
tippe mal das es daran liegt...
so sieht meine Eingangstür im Def Teil des Notifies im Web Fronten aus
hm.sec.2:open.* {
DebianMail('blablablubb@blafasel.quatsch', "Eingang $NAME:$EVENT", "$EVENT");
fhem("set hm.sw.6 on-for-timer 90");
CheckOpenWindows();
}
hm.sw.6 ist meine Beleuchtung
CheckOpenWindows gibt mir alle geöffneten Fenster und Türen als Pushover
dises stateFormat hatte ich schon auskommentiert.
Hab mal die Türe geöffnet und geschlossen und folgendes steht im evenLog...
2016-06-17 18:36:35.577 dummy Fensterleuchte on
2016-06-17 18:36:35.619 dummy Fensterleuchte on
2016-06-17 18:36:35.651 dummy Fensterleuchte on
2016-06-17 18:36:35.683 dummy Fensterleuchte on
2016-06-17 18:36:35.716 dummy Fensterleuchte on
2016-06-17 18:36:35.745 CUL_HM Flur.HM battery: ok
2016-06-17 18:36:35.745 CUL_HM Flur.HM contact: open (to vccu)
2016-06-17 18:36:35.745 CUL_HM Flur.HM open
2016-06-17 18:36:35.745 CUL_HM Flur.HM trigDst_vccu: noConfig
2016-06-17 18:36:35.745 CUL_HM Flur.HM trigger_cnt: 60
2016-06-17 18:36:38.825 dummy Fensterleuchte off
2016-06-17 18:36:38.877 dummy Fensterleuchte off
2016-06-17 18:36:38.909 dummy Fensterleuchte off
2016-06-17 18:36:38.941 dummy Fensterleuchte off
2016-06-17 18:36:38.971 dummy Fensterleuchte off
2016-06-17 18:36:38.978 CUL_HM Flur.HM battery: ok
2016-06-17 18:36:38.978 CUL_HM Flur.HM contact: closed (to vccu)
2016-06-17 18:36:38.978 CUL_HM Flur.HM closed
2016-06-17 18:36:38.978 CUL_HM Flur.HM trigDst_vccu: noConfig
2016-06-17 18:36:38.978 CUL_HM Flur.HM trigger_cnt: 61
dummy Fensterleuchte on
und dummy Fensterleuchte off...
scheint doch zu funzen, oder?
Wie gesagt, die Fensterleuchte und der Türkontakt als einzelnes funktionieren. Nur das Zusammenspiel mit notify nicht.
Dann ein list des Türkontakt und der Fensterleuchte einwerfen.
Ein Auszug aus dem EventMonitor wäre nicht verkehrt wenn der Fensterkontakt triggert und ein list des notify.
Also das übliche Programm.
Das EventLog habe ich ja schon rauskopiert, als ich die türe mal auf bzw. zu gemacht habe.
Fensterleuchte
Internals:
NAME Fensterleuchte
NR 152
STATE off
TYPE dummy
Readings:
2016-06-17 21:43:04 state off
Attributes:
alias Fensterleuchte
devStateIcon on:light_light_dim_100@orange off:light_light@505050
group Schalter
room Wohnzimmer
setList on off
Türe
Internals:
DEF 3FB7A6
IODev myCUL
LASTInputDev myCUL
MSGCNT 5
NAME Flur.HM
NR 188
STATE closed
TYPE CUL_HM
lastMsg No:44 - t:41 s:3FB7A6 d:F11034 013F00
myCUL_MSGCNT 5
myCUL_RAWMSG A0C44A2413FB7A6F11034013F00::-101:myCUL
myCUL_RSSI -101
myCUL_TIME 2016-06-17 21:41:06
protLastRcv 2016-06-17 21:41:05
protSnd 5 last_at:2016-06-17 21:41:06
protState CMDs_done
rssi_at_myCUL avg:-101.4 cnt:5 lst:-101 min:-104.5 max:-97
Readings:
2016-06-17 21:43:04 Activity alive
2016-06-13 17:10:10 CommandAccepted yes
2016-06-13 17:10:09 D-firmware 2.4
2016-06-13 17:10:09 D-serialNr MEQ1135604
2016-06-13 17:10:10 PairedTo 0xF11034
2016-06-13 17:10:10 R-cyclicInfoMsg off
2016-06-13 17:10:10 R-eventDlyTime 0 s
2016-06-13 17:10:10 R-pairCentral 0xF11034
2016-06-13 17:10:10 R-sabotageMsg on
2016-06-13 17:10:10 R-sign off
2016-06-13 17:11:15 alive yes
2016-06-17 21:41:02 battery ok
2016-06-17 21:41:02 contact closed (to vccu)
2016-06-13 17:11:15 recentStateType info
2016-06-13 17:11:15 sabotageError off
2016-06-17 21:41:02 state closed
2016-06-13 09:15:05 trigDst_F11034 noConfig
2016-06-17 21:41:02 trigDst_vccu noConfig
2016-06-17 21:41:02 trigger_cnt 63
Helper:
HM_CMDNR 68
mId 00B1
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3FB7A6,00,00,00
nextSend 1466192466.05465
prefIO
rxt 2
vccu
p:
3FB7A6
00
00
00
Mrssi:
mNo 44
Io:
myCUL -99
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rpt:
IO myCUL
flg A
ts 1466192465.95752
ack:
HASH(0x56cedb0)
448002F110343FB7A60101C800
Rssi:
At_mycul:
avg -101.4
cnt 5
lst -101
max -97
min -104.5
Tmpl:
Attributes:
IODev myCUL
actCycle 001:05
actStatus alive
alias Haustürkontakt
autoReadReg 4_reqStatus
devStateIcon open:fts_door_open closed:fts_door
expert 2_full
firmware 1.0
group Sensoren
icon scene_stairs
model HM-SEC-SC-2
room Hausflur
serialNr MEQ1135604
subType threeStateSensor
T
Zitat von: en-trust am 17 Juni 2016, 14:45:13
Ist eine einfache Elro.
Der Dummy wird ja wohl geschaltet wie automatisierer schon festgestellt hat.
Zitat von: automatisierer am 17 Juni 2016, 21:06:38
dummy Fensterleuchte on
und dummy Fensterleuchte off...
scheint doch zu funzen, oder?
Nur ist die Fensterleuchte kein Elro - logischerweise.
ZitatNAME Fensterleuchte
TYPE dummy
Wie dir entgangen sein dürfte.
Edith: Was die Frage aber im HM-Bereich zu suchen hat wird sich mir wohl nie erschliessen :-X
Fensterleuchte wird über eine Elsro steckdose via 433er geschalten und der Türkontakt ist ein Homematic
Zitat von: en-trust am 17 Juni 2016, 22:52:26
Fensterleuchte wird über eine Elsro steckdose via 433er geschalten und der Türkontakt ist ein Homematic
Dein notify schaltet den Dummy und keine Elro-Steckdose - egal ob 433 oder 868 MHz oder pilight oder sonstwas.
Was deine Elro-Steckdose damit zu tun haben soll sehen wir hier nicht da du den Zusammenhang zu deiner Steckdose nicht zeigst.
Oder ich hab das notify falsch interpretiert
set Fensterleuchte on
Ich habe mal was anderes versucht. Aber auch das tut er nicht.
define nHausDoor1 notify Flur.HM.open { if(Value("Vitrine") eq "off") {system("sudo /home/pi/raspberry-remote/send 10110 5 1 & ")}}
Du machst jetzt bitte erstmal folgendes
Bei Deinem Türkontakt machst Du ein
attr Flur.HM event-on-change-reading state,battery,sabotageError
Dann passt Du Dein notify an
define FensterleuchteNotify notify Flur.HM.(open|closed) { if ($EVTPART1 eq "open") { fhem ("set Fensterleuchte on")} else {fhem ("set Fensterleuchte off")} }
So sollte es eigentlich gehen. Zumindest ist es so sauberer und Dein notify löst nicht mehr 3 mal hintereinander ein on oder off des dummys aus.
@CoolTux
Das Zieldevice ist ein Dummy ;)
Egal welche Attribute gesetzt werden wird das vermeindliche Device nie reagieren.
Aber en-trust ist ja lese-resistent - also viel Spaß noch und gn8.
Also erstmal spricht ja nix dagegen das das Zieldevice ein Dummy ist, so lange ein weiteres notify auf den Dummy reagiert und das notify dann mal endlich die Lampe schaltet. Ich traue dem Threadersteller erstmal zu zu wissen was er da machen will und auch macht. Sollte dem nicht so sein bin ich natürlich auch raus.
ZitatIch traue dem Threadersteller erstmal zu zu wissen was er da machen will und auch macht.
Ich frage lieber nach und orientiere mich an den Antworten die ich bekomme.
Wozu einen Umweg über einen Dummy und dann noch nichtmal das zugehörige notify/DOIF/wasauchimmer zeigen und die Helfenden raten lassen ???
Edith: Traurig das man nur raten kann/darf/soll/
muss - also daher gn8 und viel Spaß noch.
Hau rein, und gute Nacht. Ich schau hier noch kurz und dann mache ich mich auch weg. Mal sehen was der TE so zu vermelden hat.
Zitat von: automatisierer am 17 Juni 2016, 21:06:38
dummy Fensterleuchte on
und dummy Fensterleuchte off...
scheint doch zu funzen, oder?
also ich wollte damit quasi nur sagen, dass es nicht an dem notify liegt, dass die Lampe nicht angeht - an der Tür übrigens auch nicht. Denn, wenn du die Tür öffnest, wird der Befehl den du in dem notify angegeben hast ausgeführt.
Und damit wäre ja das Ursprungsproblem (Türkontakt löst kein notify aus) quasi gelöst...
Leute, habt doch etwas Verständnis für einen Neuling. Die Lampendefinition habe ich aus einem der zahlreichen Threats (http://mathias-biedert.de/2014/08/25/raspberry-pi-fhem-433mhz-elro-funksteckdosen-schalten/) (https://forum.fhem.de/index.php?topic=45679.0) übernommen, also weis ich nicht was ich da tue. Daher wäre vielleicht eine Korrektur beider hilfreich.
Wie sollte denn die Definition der Lampe richtigerweise aussehen bzw. dass dazugehörge notify ?
momentan siehts ja so aus...
# Fensterleuchte (ELRO 10110 D)
define Fensterleuchte dummy
attr Fensterleuchte alias Fensterleuchte
attr Fensterleuchte devStateIcon on:light_light_dim_100@orange off:light_light@505050
attr Fensterleuchte group Schalter
attr Fensterleuchte room Wohnzimmer
attr Fensterleuchte setList on off
define on_Fensterleuchte notify Fensterleuchte:on {system("sudo /home/pi/raspberry-remote/send 10110 4 1 & ")}
define off_Fensterleuchte notify Fensterleuchte:off {system("sudo /home/pi/raspberry-remote/send 10110 4 0 & ")}
... und ist denn wenigstens der Türkontakt richtig definiert ?
#
# Tür- und Fensterkontakte (CUL_HM)
#
define Flur.HM CUL_HM 3FB7A6
attr Flur.HM event-on-change-reading state,battery,sabotageError
attr Flur.HM IODev myCUL
attr Flur.HM actCycle 001:05
attr Flur.HM actStatus alive
attr Flur.HM autoReadReg 4_reqStatus
attr Flur.HM devStateIcon open:fts_door_open closed:fts_door
attr Flur.HM expert 2_full
attr Flur.HM firmware 1.0
attr Flur.HM icon scene_stairs
attr Flur.HM model HM-SEC-SC-2
attr Flur.HM alias Haustürkontakt
attr Flur.HM group Sensoren
attr Flur.HM room Hausflur
attr Flur.HM serialNr MEQ1135604
attr Flur.HM subType threeStateSensor
Türkontakt sieht gut aus.
So wie Du es machst ist es schon ok. Aber Du musst erstmal eine Baustelle zu Ende machen.
Also fangen wir von hinten an. Du willst erstmal das Deine Lampe an geht wenn Du in Fhem einen Knopf drückst. Hierfür hast du einen Dummy als Knopf gemacht und dazu ein Notify welches reagieren und Dein schaltcode ausführen soll wenn der Knopf gedrückt wird.
Frage. Funktioniert das??? Wenn nicht, brauchen wir und über Deine Zur erstmal gar nicht weiter unterhalten sondern müssen erstmal das richten.
Wie ich schon geschrieben habe, funktioniert die Lampe wenn ich sie in fhem schalte. auch per set ... on schaltet sie.
Sehr gut. Nun müssen wir also dafür sorgen das unser notify für den Türkontakt den Dummy Schalter ordentlich schaltet. Eigentlich hatte er das ja schon mal gemacht.
Ich habe Dir da Code für das Notify gegeben. Hast Du den eingetragen?
define FensterleuchteNotify notify Flur.HM.(open|closed) { if ($EVTPART1 eq "open") { fhem ("set Fensterleuchte on")} else {fhem ("set Fensterleuchte off")} }
Das war der hier.
Jep. Hatte ich. Tat sich aber nix. Oh man fhem dauert bei mir ewig mit Laden so komme ich hier zu nix :(
wieso mit laden. Was genau machst Du denn????
ich bin grade dabei in fhem in der config zu basteln. und jedes Mal lädt er ewig bis gar nicht. Aber das ist nur ein Nebenkrieksschauplatz (Raspberry Temperatur liegt trotz Kühlkrper bei 50 Grad, kann dass zu dieser Verzögerung führen).
So... jetzt habe ich mal das alles umgestellt.
# Fensterleuchte (ELRO 10110 D)
define Fensterleuchte GenShellSwitch sudo /home/pi/raspberry-remote/send 10110 4 1 0
attr Fensterleuchte alias Fensterleuchte
attr Fensterleuchte devStateIcon on:light_light_dim_100@orange off:light_light@505050
attr Fensterleuchte group Schalter
attr Fensterleuchte room Wohnzimmer
Kein dummy mehr... und die Fensterleuchte schaltet auch. Aber das notify mit dem türkontakt tut es noch immer nicht.
Bist Du willig zu lernen? Möchtest Du fhem verwenden und lernen wie man damit arbeitet? Kannst Du auf einen Lehrer hören und vertrauen?
sonst wäre ich nicht hier !
Ähm,... jetzt dreht hier alles am Rad. Mein Türkontakt liefert statt grüne LED ne rote. Dann mache ich die türe auf und zu, nichts passiert. 5 Minuten später schaltet plötzlich die Fensterleuchte ein und wieder aus und das 2mal hinter einander.
Scheinbar funktionieren die Statements und ich muss nur rausfinden welcher.
Das Hauptproblem ist wohl die Performance von fhem. Läuft auf nem raspi 3 mit raspian. Aber warum der so lahm reagiert entzieht sich meiner Kenntnis. Raspi und CUL stehen derzeit im Wohnzimmer wo auch Türkontakt und Fenster sind.
Zitat von: en-trust am 18 Juni 2016, 13:59:03
sonst wäre ich nicht hier !
Gut. Dann fangen wir mal an.
REGEL NUMMER 1 - EDITIERE NIE NIE NIE WIEDER DIE CONFIG SELBER (von Hand)
Sowas macht man nicht mehr und sollte als verpöhnt abgestempelt werden. Ab sofort machen wir alles über die Weboberfläche von FHEM. Es hilft sehr wenn Du Dir hierfür das Einsteiger PDF durch ließt. Ansonsten kannst Du auch Fragen.
Aber erstmal hast Du wohl andere Sorgen. Das die LED nicht sofort Grün geworden ist hat aber erstmal nichts mit FHEM zu tun sondern mit Deinem HM Empfangs Gerät. Was verwendest Du als Empfangsgerät. HMLAN oder einen CUL?
mach mal bei laufenden FHEM ein top und schaue wie die CPU Auslastung ist
Die fhem.cfg editiere ich seit Beginn an über die webOberfläche. Verwende einen CUL v3 868.
#
# Auswertung für Homematic Geräte (http://blog.wenzlaff.de/?p=4759)
#
define hm HMinfo
attr hm room CUL_HM
attr hm sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hm sumStatus battery,sabotageError,powerError,motor
attr hm webCmd update:protoEvents short:rssi:peerXref:configCheck:models
#
# Definition des CUL v3
#
# define myCUL CUL /dev/serial/by-id/usb-busware.de_CUL868-if00 0000
define myCUL CUL /dev/ttyACM0@38400 1034
attr myCUL group Hardware
attr myCUL hmId F11034
attr myCUL icon cul_868
attr myCUL model CUL
attr myCUL rfmode HomeMatic
attr myCUL room System
attr myCUL verbose 5
define vccu CUL_HM F11034
attr vccu IODev myCUL
attr vccu IOList myCUL
attr vccu model CCU-FHEM
attr vccu subType virtual
attr vccu webCmd virtual:update
Habe zudem noch...
sudo apt-get -y update
sudo apt-get -y dist-upgrade
sudo apt-get -y autoremove
sudo apt-get -y autoclean
sudo rpi-update
durchgeführt.
Zitat von: en-trust am 18 Juni 2016, 14:28:24
Die fhem.cfg editiere ich seit Beginn an über die webOberfläche. Verwende einen CUL v3 868.
Und genau das machen wir in Zukunft bitte nicht mehr. Es gibt zum anlegen, editieren und anlegen von Attributen von Geräten FHEM Befehle. Genau so wie für das umbenennen und kopieren. Und das versuchen wir bitte auch zu verwenden.
Du verwendest anscheinend einen dieser Multifrequenz CUL's, ist das korrekt?
Mach doch mal folgendes. Mach mal Deine Tür auf und lass sie auf. Schaue ob der Turkontakt grün wird und dann schau in den Eventmonitor was alles an Events generiert wird. Das stellst Du hier ein genau so wie den entsprechenden log teil. Alles in Code Tags eingebettet bitte.
Ja Multifrequenz.
Habe die Tür geöffnet und die LED wurde erst oange und danach statt grün, rot. im EventLog stand zum Kontakt nur der Eintrag [i]2016-06-18 15:15:11.144 CUL_HM Flur.HM open[/i] hat aber die Leuchte angeschalten. Allerdings mit Verzögerung. Sprich dir Programmierung funktioniert. Danke schonmal an alle Beteiligten.
Scheint nur jetzt ein Problem mit der Performance zwischen Raspi, Fhem und CUl zu geben.
Ich würde mir Gedanken wegen dem rot machen. Da stimmt noch irgendwas nicht.
Wie viel Zeit vergeht denn zwischen Fenster auf und Lampe an? Bis zu 3s sind naja sagen wir vorsichtig akzeptabel.
Gerade nochmal die Tür geöffnet, LED grün. Beim Schließen jetzt rot. Wenn die tür offen, dauert es ca. 20 Sek bis Lampe leuchtet.
Ok das ist bei Licht bisschen lästig. Ganz ehrlich mal davon ab empfehle ich Dir den HMLan Adapter zu holen. Das ist dieses Ufo Teil.
Wie viele Geräte hast Du denn? Macht Dein FHEM viel. Schau Dir mal den Eventmonitor an, ist da viel los?
*Kicher*
Das dein Dummy noch ein weiteres notify triggern soll das dann deine ELRO schalten soll hast du ja erst auf der zweiten Seite des Beitrags gezeigt ;)
In meinem angepinnten Beitrag im Anfängerbereich bitte ich doch darum ALLES zu zeigen was mit der vermeintlichen "Nicht-Funktion" zu tun hat.
Da ist es wenig hilfreich ein weiteres notify zu "verheimlichen".
Aber nun gut - du hast ja jetzt ein bischen Lesestoff im Anfängerbereich bekommen 8)
Das die Lampe erst nach 20 Sekunden angeht ist nicht nur ärgerlich sondern einfach nicht brauchbar.
Wenn du die Tür (oder einen anderen Tür-Fensterensor zum testen neben dem Monitor) betätigst - kommen dann die Events sofort im EventMonitor an oder dauert das auch?
Wenn du in FHEM beim Dummy auf on klickst - schaltet dann die Lampe sofort ein oder dauert das und kommen die Events im EventMonitor sofort oder dauert das auch?
Dein RasPi-3 (wenn ich das richtig im Kopf habe benutzt du einen 3-er) ist auf jeden Fall potent genug um FHEM zu betreiben.
fheminfo wirft bei mir das aus:
Fhem info:
Release : 5.7 FeatureLevel: 5.7
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
uniqueID : xxxxxxxxxxxxxxxxxxxxxx
upTime : 2 days, 22:26:03
Defined modules:
CUL : 4
CUL_EM : 5
CUL_FHTTK : 15
CUL_HM : 324
CUL_TX : 1
CUL_WS : 6
DbLog : 1
FHEM2FHEM : 2
FHEMWEB : 3
FHT : 11
FS20 : 23
FileLog : 1
HMLAN : 2
HMS : 2
HMinfo : 1
HTTPMOD : 4
KS300 : 1
PRESENCE : 10
SONOS : 1
SONOSPLAYER : 6
STV : 1
SVG : 126
SYSMON : 1
TelegramBot : 1
Twilight : 1
Weather : 1
WeekdayTimer : 1
at : 37
autocreate : 1
average : 2
cloneDummy : 1
dewpoint : 1
dummy : 62
holiday : 4
notify : 110
readingsGroup : 25
remotecontrol : 6
telnet : 1
watchdog : 11
weblink : 7
Defined models per module:
CUL_HM : ActionDetector,CCU-FHEM,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-Dim1L-Pl-2,HM-LC-SW1-BA-PCB,HM-LC-SW1-FM,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-OU-CFM-PL,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-WM55,HM-PB-6-WM55,HM-SCI-3-FM,HM-SEC-RHS,HM-SEC-SCo,HM-SEC-SD,HM-SEC-TIS,HM-SEC-WIN,HM-Sen-MDIR-O,HM-Sen-MDIR-O-2,HM-Sen-MDIR-WM55,HM-Sen-Wa-Od,HM-WDS10-TH-O,HM-WDS30-OT2-SM,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,virtual_1,virtual_2
FS20 : fs20as4
SONOSPLAYER : Sonos_S1,Sonos_S3,Sonos_ZB100
und läuft auf einem Cubietruck mit DBLog.
Ich habe keines meiner HM-Geräte direkt gepeert sondern alle nur mit FHEM gepairt und jede Aktion/Reaktion wird über notify gesteuert.
Wenn meine Frau aber in der Garderobe das Licht einschaltet und sie müsste auch nur 2 Sekunden warten bis das Licht angeht wäre bei mir Feuer am Dach ;D
FHEM reagiert aber wunderbar und ohne Verzögerungen die meine bessere Hälfte bemerken würde.
Allerdings bearbeite ich meine Konfig auch schon seit Ewigkeiten nicht mehr direkt sondern nur und ausschliesslich über das jeweilige DEF in der Detailansicht.
Du darfst gerne mal die Forumsuche benutzen und nach Beiträgen von mir mit fhem.cfg bearbeiten suchen - dort habe ich mal versucht zu erklären wie man ganz ohne Konfig wunderbar sein FHEM konfigurieren kann.
O Puschel. Werde mal stöbern. Wenn ich die Leuchten direkt im Fhemweb ansteuere schalten diese sofort.
Habe mal die Türe erneut göffnet und im Eventmonitor dann folgendes entdeckt...
2016.06.18 19:36:58.489 5 : CUL/RAW: /A0C83A6413FB7A6F11034017EC8D5
2016.06.18 19:36:58.489 4 : CUL_Parse: myCUL A 0C 83 A641 3FB7A6 F11034 017EC8D5 -95.5
2016.06.18 19:36:58.490 5 : myCUL dispatch A0C83A6413FB7A6F11034017EC8::-95.5:myCUL
2016.06.18 19:36:58.495 5 : myCUL sending As0D838002F110343FB7A60101C800
2016.06.18 19:36:58.496 5 : CUL 3FB7A6 dly:94ms
2016.06.18 19:36:58.591 4 : CUL_send: myCULAs 0D 83 8002 F11034 3FB7A6 0101C800
Einen Rssi Wert von -95,5 ist dich mehr als nur schlecht ? Wie kommt das zu stande wenn der Raspi derzeit direkt im Wohnzimmer steht, wo auch die Leuchte ist ?
fheminfo liefert...
Fhem info:
Release : 5.7 FeatureLevel: 5.7
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.20.2
uniqueID : ce6021f726fb7dd42420ddb6e26b7ab7
upTime : 00:14:28
Defined modules:
ABFALL : 1
CALVIEW : 3
CUL : 1
CUL_HM : 4
Calendar : 4
DOIF : 2
FB_CALLLIST : 1
FB_CALLMONITOR : 1
FHEMWEB : 1
FRITZBOX : 1
FileLog : 5
HMinfo : 1
HTTPMOD : 9
HTTPSRV : 1
JeeLink : 1
LaCrosse : 2
PRESENCE : 2
PROPLANTA : 1
SVG : 3
SYSMON : 1
Twilight : 1
YAMAHA_AVR : 1
at : 7
autocreate : 1
dummy : 10
eventTypes : 1
notify : 21
readingsGroup : 3
weblink : 1
Defined models per module:
CUL : CUL
CUL_HM : ActionDetector,CCU-FHEM,HM-LC-Bl1PBU-FM,HM-SEC-SC-2
JeeLink : [LaCrosseITPlusReader.10.1q (RFM69 f:868310 t:30~3)]
YAMAHA_AVR : RX-V777
Transmitting this information during an update: yes
You can change this via the global attribute sendStatistics
myCUL ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Kann die 101 das Problem sein ? Wollte es auf 464 in fhem ändern, erhalte dort dann aber This command is not valid in the current rfmode
Wenn du einen funktionierenden Stand hast würde ich vorschlagen - lass mal die Finger von der fhem.cfg und schau wie sich dein FHEM bzw. das einschalten der Leuchte durch den Sensor dann verhält.
Aber 2 notify und ein Dummy für eine Funktion sind schon des guten zu viel ;)
Du kannst den Dummy rauswerfen und das notify des Sensors direkt die Leuchte schalten lassen.
Du kannst die Leuchte über das Frontend auch direkt schalten.
attr Fensterleuchte webCmd on:off
sollte genügen.
Ich seh grad - dein Dummy heisst gleich wie dein ELRO.
Sowas schafft man nur wenn man die Konfig direkt bearbeitet 8)
Über das Frontend bearbeitet sagt dir FHEM sofort das sowas nicht geht da es nur ein Device mit dem Namen geben kann/darf.
Daher wundere ich mich erstmal nicht weiter über deine "Verzögerungen" und "Probleme".
Ich habe fhem jetzt mal machen lassen. Cul hat er erkannt und den Türkontakt hat er auch eingefügt. Habe jetzt einfach noch das notify von cool hinzugefügt. Aber passieren tut nix. Zudem ist der rssi Wert des Cul -98. Was sehr schlecht ist. Wie bekomme ich den in eine normale Range ?
attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global group Software
attr global logfile /opt/fhem/log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB has no associated allowed device with basicAuth.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global mseclog 1
attr global room FHEM
attr global sendStatistics onUpdate
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 4
define WEB FHEMWEB 8083 global
attr WEB CssFiles CssFiles niceclocks/niceclocks.css
attr WEB JavaScripts JavaScripts niceclocks/fhem_niceclocks.js
attr WEB editConfig 1
attr WEB group Software
attr WEB hiddenroom GDS Files
attr WEB longpoll 1
attr WEB longpollSVG 1
attr WEB niceclocksParam {"clockStyle" : "analog","clockFace" : "black","keepBg" : false,"fixMenu" : false,"keepHeader" : true }
attr WEB plotfork 1
attr WEB room FHEM
attr WEB stylesheetPrefix ios7touchpad
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog /opt/fhem/log/fhem-%Y-%m.log fakelog
attr Logfile group Software
attr Logfile room FHEM
define autocreate autocreate
attr autocreate autosave 1
attr autocreate devStateIcon disabled:ios-off:on active:ios-on-blue:off
attr autocreate disable 0
attr autocreate filelog /opt/fhem/log/%NAME-%Y.log
attr autocreate group Software
attr autocreate ignoreTypes CUL_HOERMANN.*|FHT.*|CUL_WS.*
attr autocreate room FHEM
define eventTypes eventTypes /opt/fhem/log/eventTypes.txt
attr eventTypes group Software
attr eventTypes room FHEM
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
#
# TabletUI Definition
#
define TABLETUI HTTPSRV ftui/ ./www/tablet Tablet-UI
attr TABLETUI group Software
attr TABLETUI room FHEM
define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 rfmode HomeMatic
define CUL_TX_36 CUL_TX 36
attr CUL_TX_36 room CUL_TX
define FileLog_CUL_TX_36 FileLog /opt/fhem/log/CUL_TX_36-%Y.log CUL_TX_36
attr FileLog_CUL_TX_36 logtype temp4hum4:Temp/Hum,text
attr FileLog_CUL_TX_36 room CUL_TX
define SVG_CUL_TX_36 SVG FileLog_CUL_TX_36:SVG_CUL_TX_36:CURRENT
attr SVG_CUL_TX_36 label "CUL_TX_36 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_CUL_TX_36 room Plots
define HM_3FB7A6 CUL_HM 3FB7A6
attr HM_3FB7A6 IODev CUL_0
attr HM_3FB7A6 actCycle 028:00
attr HM_3FB7A6 actStatus alive
attr HM_3FB7A6 autoReadReg 4_reqStatus
attr HM_3FB7A6 expert 2_raw
attr HM_3FB7A6 firmware 2.4
attr HM_3FB7A6 model HM-SEC-SC-2
attr HM_3FB7A6 room CUL_HM
attr HM_3FB7A6 serialNr MEQ1135604
attr HM_3FB7A6 subType threeStateSensor
define FileLog_HM_3FB7A6 FileLog /opt/fhem/log/HM_3FB7A6-%Y.log HM_3FB7A6
attr FileLog_HM_3FB7A6 logtype text
attr FileLog_HM_3FB7A6 room CUL_HM
define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
define Fensterleuchte GenShellSwitch sudo /home/pi/raspberry-remote/send 10110 4 1 0
define FensterleuchteNotify notify CUL_0.(open|closed) { if ($EVTPART1 eq "open") {system("sudo /home/pi/raspberry-remote/send 10110 4 1 & ")} else {system("sudo /home/pi/raspberry-remote/send 10110 4 0 & ")} }
ZitatHabe jetzt einfach noch das notify von cool hinzugefügt. Aber passieren tut nix.
Dein notify lauscht auf den CUL_0 und nicht auf den Tür-Fensterkontakt.
In diesem Fall kannst du die Tür auf und zumachen sooft du willst, da wird sich nix tun ;)
ZitatZudem ist der rssi Wert des Cul -98.
Nicht der Wert am Cul ist interessant sondern der Wert am Tür-Fensterkontakt.
Einer meiner CUNO hat auch einen rssi von -80.5
Ein damit angesprochenes Device hat aber z.B. den Wert -49 - und dieser Wert ist relevant.
Zeig mal ein
list CUL_0 und ein
list HM_3FB7A6Jeweils oben in die FHEM-BEfehlszeile eingeben und den Output in Code-Tags posten.
Bei den Readings des Türkontaktes habe ich einmal contact mit open (to myVCCU) und state mit open. Was davon muss in diesem Notify denn abgefragt werden ?
Zudem habe ich nun x Versionen einer solchen if abfrage erhalten und bin jetzt mehr als verwirrt.
notify FL.Tuerkontakt.(open|closed) { if ($EVTPART1 eq "open")
notify FL.Tuerkontakt:open.* { if((Value("FL.Tuerkontakt") eq "open") das Ganze noch mit ReadingVal
notify FL.Tuerkontakt { if ("$EVENT" eq "open")
was muss man denn jetzt wann nehmen ?
Du weißt doch selbst am besten was du willst. Willst Du immer noch das das Licht an geht wenn die Tür auf geht? Wenn ja, wieso sollte Dein Notify auf ein closed Event reagieren. Überlege doch mal selber.
notify FL.Tuerkontakt.open set Licht an
Meine frage war doch ob ich auf das Reading contact oder state abfragen muss und welche der Abfragetypen man für was nimmt. Eigentlich ist das eine generelle Frage, weil jeder was anderes erzählt und das verwirrt so Anfänger wie mich.
Zitat von: en-trust am 11 Juli 2016, 07:34:40
Meine frage war doch ob ich auf das Reading contact oder state abfragen muss und welche der Abfragetypen man für was nimmt. Eigentlich ist das eine generelle Frage, weil jeder was anderes erzählt und das verwirrt so Anfänger wie mich.
du musst dich leider selber entscheiden, denn das, was dich wohl interessiert, steht in beiden readings. :)
ich würde contact nehmen, weil in diesem reading die gesuchte info exclusiver ist.
Wenn ich contact nehme muss ich dann sicherlich auch genau auf "open (to myVCCU)" abfragen ?
müssen musst Du eigentlich gar nicht, wie immer: "viele Wege führen nach Rom" ...
im notify fragst Du primär nicht ab, Du reagierst auf events. Diese kannst(manchmal musst) Du mit regEx "filtern" damit es Sinn macht
Bei contact würde ich auf open.*
notify FL.Tuerkontakt.open set Licht an
notify FL.Tuerkontakt.contact:.open.* set Licht an
reagieren, denn open ist das was Dich interessiert, das dieser Sensor noch "to myVCCU" dazu gibt kann beim nächsten Sensor anders sein.
Letztendlich musst Du Dir im Eventmonitor anschauen welche Events erzeugt werden und die passenden nehmen. Letztlich könnten auch mal in den readings und im state in unetrschiedlichen Situationen Events erzeugt oder nicht erzeugt werden. Hängt vom konkreten Fall ab.
Gruß Otto