Hallo,
ich habe einen zweifach intertechno Wandschalter batteriebetrieben (its-2000).
Wenn ich die eine Seite betätige sehe ich im Log genau das erwartete:
3 mal Schalten
2017-01-08 14:29:52 IT ku.SchalterLichterKette on
2017-01-08 14:29:55 IT ku.SchalterLichterKette off
2017-01-08 14:29:57 IT ku.SchalterLichterKette on
Nun habe ich diesen mit einem notify versehen:
define ku.EventLichterKette notify ku.SchalterLichterKette set ku.LichterKette $EVENT
ku.LichterKette ist eine Funksteckdose (cmi OBI/LuX ip44).
Danach sehen die Log-Einträge wie folgt aus:
1 mal Schalten (Leerzeilen eingefügt)
2017-01-08 14:37:32 IT ku.LichterKette on
2017-01-08 14:37:32 CUL culNano433 raw: is000FFF00FFFF
2017-01-08 14:37:32 IT ku.SchalterLichterKette on
2017-01-08 14:37:32 IT ku.LichterKette on
2017-01-08 14:37:33 CUL culNano433 raw: is000FFF00FFFF
2017-01-08 14:37:33 IT ku.SchalterLichterKette on
2017-01-08 14:37:33 IT ku.LichterKette on
2017-01-08 14:37:33 CUL culNano433 raw: is000FFF00FFFF
2017-01-08 14:37:33 IT ku.SchalterLichterKette on
2017-01-08 14:37:34 IT ku.LichterKette on
2017-01-08 14:37:34 CUL culNano433 raw: is000FFF00FFFF
2017-01-08 14:37:34 IT ku.SchalterLichterKette on
Die Kommunikation scheint mir übertrieben, es dauert relativ lange, bis
die Steckdose schaltet und ich bin irritiert, dass ich vier mal das selbe
sehe.
und wieder aus zeigt wieder 4 mal das selbe
2017-01-08 14:38:37 IT ku.LichterKette off
2017-01-08 14:38:37 CUL culNano433 raw: is000FFF00FFF0
2017-01-08 14:38:37 IT ku.SchalterLichterKette off
2017-01-08 14:38:37 IT ku.LichterKette off
2017-01-08 14:38:38 CUL culNano433 raw: is000FFF00FFF0
2017-01-08 14:38:38 IT ku.SchalterLichterKette off
2017-01-08 14:38:38 IT ku.LichterKette off
2017-01-08 14:38:38 CUL culNano433 raw: is000FFF00FFF0
2017-01-08 14:38:38 IT ku.SchalterLichterKette off
2017-01-08 14:38:39 IT ku.LichterKette off
2017-01-08 14:38:39 CUL culNano433 raw: is000FFF00FFF0
2017-01-08 14:38:39 IT ku.SchalterLichterKette off
Ich habe jeweils einen Block erwartet - ist das ein Denkfehler?
Grüße
Karsten
Hallo Karsten,
kennst Du den Eventmonitor? Dann gib dort im Filter ku.SchalterLichterKette.* und schau Dir an was passiert. Das wird Deine 4 Events erklären.
Formatiere Deine Post bitte mit Codetags -> der # Knopf über den Smilies.
Hier noch etwas Lektüre zu notify -> https://wiki.fhem.de/wiki/Notify
Gruß Otto
Hallo Otto,
ja den EventMonitor kenne ich, dort habe ich die Events gefunden (nicht wie fälschlicher weise geschrieben im Log).
Aber das hilft mir nicht weiter, dort sehe ich wie schon geschrieben 4 mal das selbe, vielleicht muss ich mal den verbose level erhöhen. Momentan läuft die Zeit mal wieder weg.
Den Artikel zu Notify kenne ich auch, habe ihn aber nicht komplett gelesen. Ich ging davon aus, dass für das sehr einfache Beispiel die Grundlagen ausreichen - wohl ein Trugschluss.
Ist der "vierfach Event" denn normal?
Danke für Deine Bemühungen, Grüße
Karsten
Hallo Karsten,
Du triggerst nur auf das Gerät
define ku.EventLichterKette notify ku.SchalterLichterKette set ku.LichterKette $EVENT
Damit wird jeder Event den das Gerät ku.SchalterLichterKette weitergereicht! Jeder!
Wenn es vier sind dann werden vier weitergereicht.
Gruß Otto
Hallo Otto,
ich versteh's nicht, eventuell ein Brett vorm Kopf.
Ich habe jetzt im Event-Monitor auf ku.Schalter gefiltert und das fhem log mit eingeschaltet.
Das Ergebnis ist ähnlich wie oben
2017.01.08 19:29:18 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.08 19:29:18 2 : culNano433 IT_set: ku.LichterKette off
2017-01-08 19:29:19 IT ku.SchalterLichterKette off
2017.01.08 19:29:19 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.08 19:29:19 2 : culNano433 IT_set: ku.LichterKette off
2017-01-08 19:29:19 IT ku.SchalterLichterKette off
2017.01.08 19:29:20 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.08 19:29:20 2 : culNano433 IT_set: ku.LichterKette off
2017-01-08 19:29:20 IT ku.SchalterLichterKette off
2017.01.08 19:29:20 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.08 19:29:20 2 : culNano433 IT_set: ku.LichterKette off
2017-01-08 19:29:21 IT ku.SchalterLichterKette off
Die Meldungen culNano... von off -> off sind mir nicht klar. Wenn er das tut, dann ist klar, das notify 4 mal gerufen wird.
Wenn ich jedoch das Event/Notify disable
attr ku.EventLichterKette disable 1
dann erhalte ich nach Schalten nur
2017.01.08 19:35:19 3 : culNano433 IT: ku.SchalterLichterKette off->on
2017-01-08 19:35:19 IT ku.SchalterLichterKette on
Bleibt also die Frage: Warum wird durch ein aktives notify die Zeile
2017.01.08 19:29:19 3 : culNano433 IT: ku.SchalterLichterKette off->off
mehrfach aufgerufen?
Grüße
Karsten
Hallo Karsten,
ehrlich gesagt ich verstehe Deinen Post nicht.
Aber egal Du kannst nicht auf alle Events triggern, das macht keinen Sinn.
Du darfst nur auf das triggern was Du weiter verwenden willst.
Bitte mach es so:
define ku.EventLichterKette notify ku.SchalterLichterKette:(on|off) set ku.LichterKette $EVENT
Gruß Otto
Hi Otto,
sein Problem scheint zu sein, dass 1 event(Tastendruck) zu mehrfachem Auslösen des notifys führt.
Interessant wären die üblichen notwendigen Infos:
firmware des Cul, list von schalter und dose, Aktualität von fhem, speziell 10_IT.pm....
Grüße Markus
Hallo Markus, hallo Otto,
richtig mehrfaches unklares Auslösen von notify ist mein Problem.
Wenn ich mir die Meldungen im Event-Monitor anschaue, dann vermute ich, das der culNano433 diese Events auslöst. Der erste ist klar, z.B. on -> off, die nächsten 3 nicht: off ->off.
Was mir dabei jedoch völlig schleierhaft ist, ist die Tatsache, dass die 3 zusätzlichen von off->off fehlen, wenn ich den notify deaktiviere.
Die fehlenden Informationen liefere ich nach, ich habe fhem erst im Dezember 2016 installiert und zu diesem Zeitpunkt die a-culfw verwendet
Grüße
Karsten
dann flash auf jeden Fall mal die aktuellste aculfw.
Hallo zusammen,
hier dann die fehlenden Informationen.
culNano433 version => V 1.23.01 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
im Datei-Kopf der 10_IT.pm findet sich:
# $Id: 10_IT.pm 12179 2016-09-19 19:26:01Z dancer0705 $
der Schalter (list)
list ku.SchalterLichterKette
Internals:
DEF 01011011101010110101011110 0 0000
IODev culNano433
LASTInputDev culNano433
MSGCNT 83
NAME ku.SchalterLichterKette
NR 115
STATE off
TYPE IT
XMIT 0101101110101011010101111000000
XMITdimdown 00
XMITdimup 00
XMIToff 0
XMITon 1
culNano433_MSGCNT 83
culNano433_RAWMSG i669a999a666a9555
culNano433_RSSI -58.5
culNano433_TIME 2017-01-08 21:32:07
Code:
1 0101101110101011010101111000000
Readings:
2017-01-07 16:28:17 group 0
2017-01-07 16:28:17 protocol V3
2017-01-08 21:32:07 state off
2017-01-07 16:28:17 unit 0000
Attributes:
IODev culNano433
room IT
Die Steckdose (list)
list ku.LichterKette
Internals:
DEF 000FFF00FF FF F0
IODev culNano433
NAME ku.LichterKette
NR 116
STATE off
TYPE IT
XMIT 000fff00ff
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon ff
Code:
1 000fff00ff
Readings:
2017-01-08 08:59:22 protocol V1
2017-01-08 21:32:07 state off
Attributes:
IODev culNano433
alias Lichterkette Küche
group Licht
model itswitch
room Wohnzimmer
und die Version der fhem-Installation
Latest Revision: 12718
File Rev Last Change
fhem.pl 12717 2016-12-05 21:53:35Z rudolfkoenig
96_allowed.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
90_at.pm 12717 2016-12-05 21:53:35Z rudolfkoenig
98_autocreate.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
00_CUL.pm 12667 2016-11-27 09:12:29Z rudolfkoenig
10_CUL_HM.pm 12707 2016-12-03 18:39:36Z martinp876
No Id found for 14_CUL_REDIRECT.pm
14_CUL_TCM97001.pm 11294 2016-04-21 20:32:28Z dancer0705
70_ENIGMA2.pm 12317 2016-10-10 23:12:02Z loredo
91_eventTypes.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
01_FHEMWEB.pm 12613 2016-11-21 10:40:20Z rudolfkoenig
92_FileLog.pm 12378 2016-10-18 19:45:22Z rudolfkoenig
14_Hideki.pm 12233 2016-10-01 22:22:51Z mrsidey
98_HMinfo.pm 12705 2016-12-03 15:37:05Z martinp876
98_HTTPMOD.pm 12220 2016-09-29 18:25:09Z ststrobel
10_IT.pm 12179 2016-09-19 19:26:01Z dancer0705
91_notify.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
No Id found for 70_RASPIO.pm
33_readingsProxy.pm 12689 2016-11-29 21:43:01Z justme1968
# $Id: 99_RpiUtils.pm $
14_SD_WS07.pm 12233 2016-10-01 22:22:51Z mrsidey
99_SUNRISE_EL.pm 12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm 12482 2016-11-01 09:25:59Z rudolfkoenig
42_SYSMON.pm 11105 2016-03-20 19:37:02Z hexenmeister
98_telnet.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
99_Utils.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
98_version.pm 11987 2016-08-19 17:13:41Z markusbloch
59_Weather.pm 12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
Blocking.pm 12648 2016-11-24 12:15:25Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
DevIo.pm 12716 2016-12-05 09:11:31Z rudolfkoenig
HMConfig.pm 12707 2016-12-03 18:39:36Z martinp876
HttpUtils.pm 12174 2016-09-19 05:53:59Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 12688 2016-11-29 20:40:24Z rudolfkoenig
TcpServerUtils.pm 11908 2016-08-06 15:09:55Z rudolfkoenig
YahooWeatherAPI.pm 12465 2016-10-29 09:01:31Z borisneubert
Ein update check gibt eine lange Liste aus - das hatte ich nicht erwartet. Ich werde wenn ich etwas Zeit finde (wahrscheinlich Dienstag) mal ein update anstoßen, die firmware aktualisieren und dann schauen wie es aussieht. Heute Abend möchte ich das nicht mehr tun.
Grüße
Karsten
Hi Karste,
dann halten wir doch mal als erstes learning fest, dass man vor dem posten eines Problems erst mal ein update ausführt ;)
Die lists der Geräte sind unauffällig.
Hi,
das Problem gab es in einem anderen Thread auch schon: https://forum.fhem.de/index.php?topic=23200.0 (https://forum.fhem.de/index.php?topic=23200.0)
Da hat das Attribut event-on-Change-reading geholfen.
Hallo,
ich habe jetzt die culfw auf den neuesten Stand gebracht, wobei das changelog nicht auf Änderungen hindeutet, die für mich so aussehen, als hätten Sie etwas mit dem Problem zu tun (wenn es denn eins ist).
Außerdem ein update durchgeführt.
Es ergibt sich keine Änderung beim Verhalten.
Ich lese jetzt mal den Post in wuehlers Antwort.
Grüße
Karsten
Nochmals hallo,
jetzt ist auch der Vorschlag in wuehlers Link geprüft.
Also attr ku.SchalterLichterKette event-onchange-reading .*
Das Ergebnis sieht bei zwei Schaltvorgängen wie folgt aus:
2017.01.09 21:18:06 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.09 21:18:06 2 : culNano433 IT_set: ku.LichterKette off
2017-01-09 21:18:07 IT ku.SchalterLichterKette off
2017.01.09 21:18:07 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.09 21:18:21 3 : culNano433 IT: ku.SchalterLichterKette off->on
2017.01.09 21:18:21 2 : culNano433 IT_set: ku.LichterKette on
2017-01-09 21:18:21 IT ku.SchalterLichterKette on
2017.01.09 21:18:21 3 : culNano433 IT: ku.SchalterLichterKette on->on
Es kommt also nur noch ein zusätzlicher Eintrag von off->off bzw on -> on
Die events / log-Einträge werden also um zwei reduziert.
Die Grundfrage bleibt jedoch: Warum sorgt das Definieren eines notifiers für 3 zusätzliche Events oder Log-Einträge?
Grüße
Karsten
Hallo Karsten,
mein Vorschlag aus https://forum.fhem.de/index.php/topic,64400.msg556629.html#msg556629
hat nicht funktioniert?
Gruß Otto
Hallo Otto,
sorry - das hatte ich sofort ausprobiert, meine Definition sieht so aus:
ku.SchalterLichterKette:(on|off) set ku.LichterKette $EVENT
Die Anzeige im regexp wizard verstehe ich allerdings nicht, ich habe mich mit diesem noch nicht
auseinander gesetzt. Das ändern hat keine Wirkung gezeigt, es wird ja auch immer on oder
off in der Ausgabe angezeigt.
Grüße
Karsten
Hallo Karsten,
der regExp Wizard kann mit diesem regEx nichts so richtig was anfangen. Das ist aber egal.
Du hast doch einen Event:
Zitat2017-01-09 21:18:21 IT ku.SchalterLichterKette on
egal was ringsrum ist, dieser Event muss das notify triggern. Und zwar genau einmal.
Geht dabei die ku.LichterKette an? Also gibt es dabei genau einen Event set ku.LichterKette on?
Was bedeutet das?:
ZitatDas ändern hat keine Wirkung gezeigt, es wird ja auch immer on oder
off in der Ausgabe angezeigt.
Definiere zum Test bitte Dein notify neu:
define ku.EventLichterKette notify ku.SchalterLichterKette:(on|off) { Log 1, "Hier kommt der Event: $EVENT"}Und schau dann ins Log. Poste bitte das relevante Stück.
Gruß Otto
Ich habe den Thread jetzt mehrfach gelesen - aber das Problem verstehe ich immer noch nicht.
Wo wird denn da irgendwas mehrfach ausgelöst?
2017.01.09 21:18:06 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.09 21:18:06 2 : culNano433 IT_set: ku.LichterKette off
2017-01-09 21:18:07 IT ku.SchalterLichterKette off
2017.01.09 21:18:07 3 : culNano433 IT: ku.SchalterLichterKette off->off
- ku.SchalterLichterKette wechselt von on auf off (Taste wurde gedrückt)
- ku_Lichterkette wird auf off gesetzt (Reaktion des notify, das den set Befehl ausführt)
- ku.SchalterLichterKette ist off (Das Wechseln von on auf off aus Schritt 1 ist beendet)
- Der Vorgang ist abgeschlossen
Zeilen 1,2,4 sind völlig normale Meldungen von der Funkhardware.
Zeile 3 ist der eigentlich event, auf den korrekt getriggert wird (Ergebnis ist in Zeile 2 zu sehen)
Hallo zusammen,
ich habe jetzt Ottos Vorschlag aufgegriffen und wie folgt definiert:
ku.SchalterLichterKette:(on|off) { Log 1, "Hier kommt der Event: $EVENT"}
Das Ergebnis, ist das was ich erwartet hätte (2 mal schalten):
2017.01.11 20:56:16 3 : culNano433 IT: ku.SchalterLichterKette off->on
2017.01.11 20:56:16 1 : Hier kommt der Event: on
2017-01-11 20:56:16 IT ku.SchalterLichterKette on
2017.01.11 20:56:22 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.11 20:56:22 1 : Hier kommt der Event: off
2017-01-11 20:56:22 IT ku.SchalterLichterKette off
Definiere ich wie folgt
ku.SchalterLichterKette:(on|off) { Log 1, "Hier kommt der Event: $EVENT"; fhem("set ku.LichterKette $EVENT");}
erhalte ich bei zwei mal schalten das folgende Ergebnis:
2017.01.11 21:06:02 3 : culNano433 IT: ku.SchalterLichterKette off->on
2017.01.11 21:06:02 1 : Hier kommt der Event: on
2017.01.11 21:06:02 2 : culNano433 IT_set: ku.LichterKette on
2017-01-11 21:06:02 IT ku.LichterKette on
2017-01-11 21:06:02 IT ku.SchalterLichterKette on
2017.01.11 21:06:02 3 : culNano433 IT: ku.SchalterLichterKette on->on
2017.01.11 21:06:02 1 : Hier kommt der Event: on
2017.01.11 21:06:02 2 : culNano433 IT_set: ku.LichterKette on
2017-01-11 21:06:02 IT ku.LichterKette on
2017-01-11 21:06:03 IT ku.SchalterLichterKette on
2017.01.11 21:06:03 3 : culNano433 IT: ku.SchalterLichterKette on->on
2017.01.11 21:06:03 1 : Hier kommt der Event: on
2017.01.11 21:06:03 2 : culNano433 IT_set: ku.LichterKette on
2017-01-11 21:06:03 IT ku.LichterKette on
2017-01-11 21:06:03 IT ku.SchalterLichterKette on
2017.01.11 21:06:03 3 : culNano433 IT: ku.SchalterLichterKette on->on
2017.01.11 21:06:03 1 : Hier kommt der Event: on
2017.01.11 21:06:03 2 : culNano433 IT_set: ku.LichterKette on
2017-01-11 21:06:03 IT ku.LichterKette on
2017-01-11 21:06:04 IT ku.SchalterLichterKette on
2017.01.11 21:06:07 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.11 21:06:07 1 : Hier kommt der Event: off
2017.01.11 21:06:07 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 21:06:07 IT ku.LichterKette off
2017-01-11 21:06:07 IT ku.SchalterLichterKette off
2017.01.11 21:06:07 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.11 21:06:07 1 : Hier kommt der Event: off
2017.01.11 21:06:07 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 21:06:07 IT ku.LichterKette off
2017-01-11 21:06:07 IT ku.SchalterLichterKette off
2017.01.11 21:06:08 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.11 21:06:08 1 : Hier kommt der Event: off
2017.01.11 21:06:08 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 21:06:08 IT ku.LichterKette off
2017-01-11 21:06:08 IT ku.SchalterLichterKette off
2017.01.11 21:06:08 3 : culNano433 IT: ku.SchalterLichterKette off->off
2017.01.11 21:06:08 1 : Hier kommt der Event: off
2017.01.11 21:06:08 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 21:06:08 IT ku.LichterKette off
2017-01-11 21:06:09 IT ku.SchalterLichterKette off
Das gesetzte: attr ku.SchalterLichterKette event-onchange-reading .*
habe ich vorher wieder gelöscht gehabt, da die Steckdose sonst nicht reagiert, hat.
So wie es jetzt ist, scheint sie ganz am Ende des Prozesses zu reagieren, das kann aber eine Täuschung meinerseits zu sein.
Im zweiten längeren Code-Block verstehe ich die ersten 5 Zeilen:
2017.01.11 21:06:07 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.11 21:06:07 1 : Hier kommt der Event: off
2017.01.11 21:06:07 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 21:06:07 IT ku.LichterKette off
2017-01-11 21:06:07 IT ku.SchalterLichterKette off
Danach kommen 3 bis auf die Logzeiten identische Blöcke a 5 Zeilen, die ich nicht verstehe.
Die Ausgaben ähneln den Angaben in meinem ersten Post der Unterschied resultiert daraus,
dass ich das log im Eventmonitor zugeschaltet und den Tipp von Otto eingebaut habe.
Grüße
Karsten
Hallo Karsten,
also ich verstehe, dass mein Vorschlag mit dem notify der Richtige ist. Das funktioniert.
Was nicht funktioniert ist Dein set ku.LichterKette !
Dieser set Befehl löst offenbar auch einen set Befehl für ku.SchalterLichterKette aus. Warum musst Du rausfinden.
Was ist das Gerät IT_set ?
Aber eventuell versteh ich von dem IT Zeug zu wenig, aber anders, als das Du mit ku.LichterKette noch was Zusätzliches auslöst, kann ich es mir nicht erklären.
Gruß Otto
Hallo Otto,
ich habe kein Gerät IT_Set, ein grep auf die Quellcodes zeigt an, dass die SetFn im Modul
10_IT auf die Funktion gesetzt ist.
Da der Notify ohne dass ich die Steckdose schalte ganz normale Log-Einträge / Events
ergibt, vermute ich auch, dass es am IT_Modul liegt. Vielleicht ist die Entfernung zu groß
und deshalb wird mehrfach gesendet bis die Steckdose schaltet, wobei dann die Steckdose
ein Signal zurück liefern müsste, dass kann ich mir bei der Baumarkt-Dose nicht vorstellen.
Grüße
Karsten
Zitatdass kann ich mir bei der Baumarkt-Dose nicht vorstellen.
korrekte Vorstellung :D
ZitatWas ist das Gerät IT_set ?
ist nur die Protokollierung, dass ein set des devices aus fhem heraus erfolgt ist(im Gegensatz zum schalten durch einen Sensor/FB)
diese Gerätebezeichnungen machen mich ganz wuschig im Kopf. Benenn doch einfach mal als Taster und Dose.
ZitatDieser set Befehl löst offenbar auch einen set Befehl für ku.SchalterLichterKette aus. Warum musst Du rausfinden.
andere Idee hab ich auch nicht :(
oder doch. bau mal ein eigentlich unsinniges "sleep 1" vor den Schaltbefehl....
Grüße Markus
Edit: und wenn das nicht hilft: Dein notify ist richtig und es brennt durch das mehrfache Schalten ja nichts an. Besser noch: Die Sicherheit des Schaltens wird durch die Redundanz erhöht ;D
der sendet nicht mehrfach, der schaltbefehl auf ku.LichterKette löst weitere Befehle aus.
Mach doch mal ein manuelles set ku.LichterKette on.
Und gib mal ein list ku.LichterKette.
Gruß Otto
Hallo Markus,
der sleep ist eine interessante Idee. Eine Sekunde hat eine der m.E. seltsamen Einträge im Event-Monitor /log verschwinden lassen. Setze ich auf 2 Sekunden, erhalte ich die folgende Rückmeldung (wieder zwei mal schalten):
2017.01.11 22:54:56 3 : culNano433 IT: ku.SchalterLichterKette off->on
2017.01.11 22:54:56 1 : Hier kommt der Event: on
2017.01.11 22:54:58 2 : culNano433 IT_set: ku.LichterKette on
2017-01-11 22:54:58 IT ku.LichterKette on
2017-01-11 22:54:59 IT ku.SchalterLichterKette on
2017.01.11 22:55:03 3 : culNano433 IT: ku.SchalterLichterKette on->off
2017.01.11 22:55:03 1 : Hier kommt der Event: off
2017.01.11 22:55:05 2 : culNano433 IT_set: ku.LichterKette off
2017-01-11 22:55:05 IT ku.LichterKette off
2017-01-11 22:55:05 IT ku.SchalterLichterKette off
Genau das, was ich erwartet hätte. Die Dose schaltet natürlich nicht schneller, das lässt sich anscheinend hardware-bedingt nicht lösen.
Welche Überlegung steckte hinter Deinem als "unsinnig" angekündigten sleep.
Ps.: ich muss mein eigenes sleep jetzt auch einschalten, finde den Schalter gerade nicht :-)
Grüße
Karsten
Hallo Otto,
ein set ku.LichterKette on liefert im Log-File folgendes:
2017.01.11 22:55:05 2: culNano433 IT_set: ku.LichterKette on
ein list ku.LichterKette liefert:
Internals:
DEF 000FFF00FF FF F0
IODev culNano433
NAME ku.LichterKette
NR 116
STATE on
TYPE IT
XMIT 000fff00ff
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon ff
Code:
1 000fff00ff
Readings:
2017-01-08 08:59:22 protocol V1
2017-01-11 23:03:47 state on
Attributes:
IODev culNano433
alias Lichterkette Küche
group Licht
model itswitch
room Wohnzimmer
Grüße
Karsten
tut mir Leid, ich kann mir da keinen Reim drauf machen.
Der Befehl alleine löst diese Kette also icht aus.
Der sofortige hinterher geschickte Befehl löst irgendwie dies Kette aus. Mit der Verzögerung des Folge Befehls passiert das nicht.
Wahrscheinlich ne Eigenheit von IT
Gruß Otto
ZitatWahrscheinlich ne Eigenheit von IT
eher nicht !
Zitatset ku.LichterKette on
funktioniert ja problemlos
da würd ich eher noch am nanoCUL zweifeln.
ZitatWelche Überlegung steckte hinter Deinem als "unsinnig" angekündigten sleep.
War nur so ein hilfloser Gedanke. Die IT-Sender senden einen Befehl(Datentelegramm) mehrfach. Nur der Empfang 2er Telegramme wird im CUL als Befehl erkannt. Hätte sein können, dass der Taster noch sendet, während fhem/CUL schon den Tasterdruck erkannt hat und das notify ausgelöst hat. Wenn das dann aber als erneuter Tastendruck erkannt worden wäre, hätte es auch weitere notifys geben müssen :'(
Du hast nur einen Transceiver(nanoCUL) am fhem-System und auch nur ein System ?
Ich würd die Geräte mal einfacher benennen und die DIPs an der Dose auch mal verändern....
Hi,
Mir fällt dann noch sowas ein, ob das, das sleep ersetzen kann, weiß ich nicht.
define ku.EventLichterKette notify ku.SchalterLichterKette:(on|off) set ku.LichterKette:FILTER=STATE!=$EVENT $EVENT
Gruß Otto
Hallo Otto,
ich habe Deinen Vorschlag ausprobiert, das funktioniert in soweit, dass die Mehrfach-Ausgaben weg sind.
Allerdings schaltet die Steckdose dann nicht.
Ich habe zum Testen mal alles umbenannt und in einen Raum gelegt.
Es sind jetzt auf der Weboberfläche wie folgt aus.
kschalter Birnchen on off
kdose Birnchen on off
Schalte ich mit einem Click auf kschalter, so wird kdose sofort analog geschaltet.
Im Eventmonitor / Log ist nur ein einmaliger Eintrag (ein Block) vorhanden.
Schalte ich mit dem Hardwareschalter, so wird in der Weboberfläche kschalter und kdose mit ganz leichter Verzögerung geschaltet.
Die Steckdose wird jedoch gar nicht oder mit deutlicher Verzögerung geschaltet.
Im Eventmonitor / Log sind vier Einträge (Blöcke) vorhanden.
Mein culNano433 oder die Steckdose kommen also nicht damit klar, das mehr oder weniger gleichzeitig "herumgefunkt" wird.
Ich werde daher mal den Vorschlag von Markus aufnehmen und den Dip-Schalter umsetzen und / oder mal versuchen mit einem zweiten cul an die Dose zu senden. Der ist auf 868 MHz eingestellt, aber wenn ich es richtig verstanden habe, müsste er auf 433 herunter gehen wenn nötig.
Ich berichte.
Grüße
Karsten
Hallo zusammen,
ich habe nun beide Varianten ausprobiert, das Verhalten ändert sich nicht.
Bleibt als Workaround also nur der sleep mit 2 Sekunden.
Grüße und Dank an alle die mit gedacht haben.
Grüße
Karsten
Nochmal guten Tag zusammen,
da ich sowieso noch 2 Steckdosen brauchte habe ich im Baumarkt mal einen Dreierpack itr-1500 mitgenommen. Diese lassen sich problemlos in fhem integrieren und zur Not könnte ich ja den Schalter in der Wand an die Dose anlernen.
Die Dose zeigt exakt das gleiche Verhalten, im Eventmonitor / Log tauchen die gleichen Einträge auf und die Dose schaltet in der Regel nicht. Ich denke also, dass es am CUL liegt. Da ich es auch mit einem anderen cul probiert habe (allerdings 868 MHz), denke ich nicht, dass es an der Hardware liegt, sondern an der Firmware. Auf beiden ist die culfw-a geflasht.
culNano433 version => V 1.23.05 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
Indirektes schalten ist somit nur mit einer zusätzlichen Zeitverzögerung möglich, jedenfalls mit der von mir bisher geprüften Hardware. Das finde ich doch ziemlich unbefriedigend....
aber anscheinend normal, u.a. der Thread https://forum.fhem.de/index.php/topic,64501.0.html (https://forum.fhem.de/index.php/topic,64501.0.html) behandelt das Thema.
Grüße
Karsten