Indirekte Kopplung, nanoCUL, Aktor schaltet nicht

[hanshome]

Hallo zusammen,

nachdem ich über Weihnachten erfolgreich FHEM auf einem Raspi3 installiert habe, einen nanoCUL zusammengebaut habe und sogar die Alexa-Anbindung hinbekommen habe, komme ich jetzt gerade nicht weiter.

Aktuelle Anwendungswunsch: Mit einem Wandschalter Licht in einem kompletten Zimmer schalten, dabei handelt es sich dann um zwei Intertechno-Funksteckdosen und eine HUE-Lampe. Indirekte Kopplung im Wiki habe ich mir angeschaut und das funktioniert im Prinzip auch. Bei Betätigen des Schalters in der Oberfläche wird die per notify gekoppelte Steckdose geschaltet.

Allerdings funktioniert es nicht, wenn ich den Schalter tatsächlich betätige. FHEM erkennt dass der Schalter betätigt wurde und zeigt dies auch in der Oberfläche an, das notify wird ausgeführt. Nur dass in dieser Kombination der Aktor/die Steckdose nicht schaltet.

Die Details:
Sender: zwei Sachen ausprobiert:
- Smartwares AP-Schalter, wird als IT V3 erkannt und laut Log ohne Fehler verarbeitet
- die bei der Steckdose beigelegte Fernbedienung, hier habe ich einfach einen anderen Hauscode eingestellt, so dass die Dose nicht direkt auf die FB reagiert.
Empfänger:
- Funksteckdose renkforce, funktioniert einwandrei als IT V1

CUL:  V 1.67 nanoCUL433
FHEM: Release  : 5.7 FeatureLevel: 5.7

Und hier der Auszug aus dem Log:

Code Auswählen Erweitern

2017.01.09 19:50:05 4: WEB_192.168.178.25_49371 GET /fhem?XHR=1&inform=type=status;filter=eventTypes;since=1483987804;fmt=JSON&fw_id=300×tamp=1483987805684; BUFLEN:0
2017.01.09 19:50:08 4: Connection closed for WEB_192.168.178.25_49371: EOF
2017.01.09 19:50:08 4: Connection accepted from WEB_192.168.178.25_49372
2017.01.09 19:50:08 4: WEB_192.168.178.25_49372 GET /fhem?XHR=1&inform=type=status;filter=;since=1483987792;fmt=JSON&fw_id=297×tamp=1483987808888; BUFLEN:0
2017.01.09 19:50:41 4: Connection closed for WEB_192.168.178.25_49372: EOF
2017.01.09 19:50:41 4: Connection accepted from WEB_192.168.178.25_49375
2017.01.09 19:50:41 4: WEB_192.168.178.25_49375 GET /fhem?room=all; BUFLEN:0
2017.01.09 19:50:41 4: name: /fhem?room=all / RL:2723 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.01.09 19:50:41 4: WEB_192.168.178.25_49375 GET /fhem?XHR=1&inform=type=status;filter=room=all;since=1483987840;fmt=JSON&fw_id=302×tamp=1483987841943; BUFLEN:0
2017.01.09 19:50:47 5: CUL/RAW: /iA6
2017.01.09 19:50:47 5: CUL/RAW: iA6/696665
2017.01.09 19:50:47 5: CUL/RAW: iA6696665/55555
2017.01.09 19:50:47 5: CUL/RAW: iA669666555555/6563B
2017.01.09 19:50:47 5: CUL/RAW: iA6696665555556563B
/

2017.01.09 19:50:47 4: CUL_Parse: nanoCUL iA6696665555556563B -44.5
2017.01.09 19:50:47 5: nanoCUL: dispatch ia669666555555656
2017.01.09 19:50:47 4: nanoCUL IT: message "ia669666555555656" (17)
2017.01.09 19:50:47 4: nanoCUL ITv3: bin message "1010011001101001011001100110010101010101010101010101011001010110" (64)
2017.01.09 19:50:47 4: nanoCUL IT: msgcode "11010110010101000000000000010001" (32) bin = 1010011001101001011001100110010101010101010101010101011001010110
2017.01.09 19:50:47 3: nanoCUL IT: Schalter1_1 off->on
2017.01.09 19:50:47 5: Triggering Schalter1_1 (1 changes)
2017.01.09 19:50:47 5: Starting notify loop for Schalter1_1, 1 event(s), first is on
2017.01.09 19:50:47 5: Triggering n_mySchalter2
2017.01.09 19:50:47 4: n_mySchalter2 exec set Steckdose $EVENT
2017.01.09 19:50:47 5: Cmd: >set Steckdose $EVENT<
2017.01.09 19:50:47 2: nanoCUL IT_set: Steckdose on
2017.01.09 19:50:47 5: Triggering Steckdose (1 changes)
2017.01.09 19:50:47 5: Starting notify loop for Steckdose, 1 event(s), first is on
2017.01.09 19:50:47 5: Triggering FB_klein_2 (1 changes)
2017.01.09 19:50:47 5: Starting notify loop for FB_klein_2, 1 event(s), first is on
2017.01.09 19:50:47 5: nanoCUL IT_set: Type=CUL Protocol=V1
2017.01.09 19:50:47 5: SW: is0FFFF0FFFFFF
2017.01.09 19:50:48 5: CUL/RAW (ReadAnswer): is0
2017.01.09 19:50:48 5: CUL/RAW (ReadAnswer): FFFF0
2017.01.09 19:50:48 5: CUL/RAW (ReadAnswer): F
2017.01.09 19:50:48 5: CUL/RAW (ReadAnswer): FFFFF
2017.01.09 19:50:48 5: CUL/RAW (ReadAnswer):

2017.01.09 19:50:48 5: Triggering nanoCUL (1 changes)
2017.01.09 19:50:48 5: Starting notify loop for nanoCUL, 1 event(s), first is raw: is0FFFF0FFFFFF
2017.01.09 19:50:48 5: IT_Set: GetFn(raw): message = is0FFFF0FFFFFF Antwort =   raw => is0FFFF0FFFFFF
2017.01.09 19:50:48 4: ITSet: Answer from nanoCUL:   raw => is0FFFF0FFFFFF
2017.01.09 19:50:51 5: CUL/RAW: /iA
2017.01.09 19:50:51 5: CUL/RAW: iA/669666
2017.01.09 19:50:51 5: CUL/RAW: iA669666/55555
2017.01.09 19:50:51 5: CUL/RAW: iA66966655555/555638
2017.01.09 19:50:51 5: CUL/RAW: iA66966655555555638/

2017.01.09 19:50:51 4: CUL_Parse: nanoCUL iA66966655555555638 -46
2017.01.09 19:50:51 5: nanoCUL: dispatch ia669666555555556
2017.01.09 19:50:51 4: nanoCUL IT: message "ia669666555555556" (17)
2017.01.09 19:50:51 4: nanoCUL ITv3: bin message "1010011001101001011001100110010101010101010101010101010101010110" (64)
2017.01.09 19:50:51 4: nanoCUL IT: msgcode "11010110010101000000000000000001" (32) bin = 1010011001101001011001100110010101010101010101010101010101010110
2017.01.09 19:50:51 3: nanoCUL IT: Schalter1_1 on->off
2017.01.09 19:50:51 5: Triggering Schalter1_1 (1 changes)
2017.01.09 19:50:51 5: Starting notify loop for Schalter1_1, 1 event(s), first is off
2017.01.09 19:50:51 5: Triggering n_mySchalter2
2017.01.09 19:50:51 4: n_mySchalter2 exec set Steckdose $EVENT
2017.01.09 19:50:51 5: Cmd: >set Steckdose $EVENT<
2017.01.09 19:50:51 2: nanoCUL IT_set: Steckdose off
2017.01.09 19:50:51 5: Triggering Steckdose (1 changes)
2017.01.09 19:50:51 5: Starting notify loop for Steckdose, 1 event(s), first is off
2017.01.09 19:50:51 5: Triggering FB_klein_2 (1 changes)
2017.01.09 19:50:51 5: Starting notify loop for FB_klein_2, 1 event(s), first is off
2017.01.09 19:50:51 5: nanoCUL IT_set: Type=CUL Protocol=V1
2017.01.09 19:50:51 5: SW: is0FFFF0FFFF00
2017.01.09 19:50:52 5: CUL/RAW (ReadAnswer): is0FF
2017.01.09 19:50:52 5: CUL/RAW (ReadAnswer): FF0FF
2017.01.09 19:50:52 5: CUL/RAW (ReadAnswer): FF00
2017.01.09 19:50:52 5: CUL/RAW (ReadAnswer):

2017.01.09 19:50:52 5: Triggering nanoCUL (1 changes)
2017.01.09 19:50:52 5: Starting notify loop for nanoCUL, 1 event(s), first is raw: is0FFFF0FFFF00
2017.01.09 19:50:52 5: IT_Set: GetFn(raw): message = is0FFFF0FFFF00 Antwort =   raw => is0FFFF0FFFF00
2017.01.09 19:50:52 4: ITSet: Answer from nanoCUL:   raw => is0FFFF0FFFF00
2017.01.09 19:50:54 4: Connection closed for WEB_192.168.178.25_49375: EOF
2017.01.09 19:50:54 4: Connection accepted from WEB_192.168.178.25_49376
2017.01.09 19:50:54 4: WEB_192.168.178.25_49376 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-01.log; BUFLEN:0

Ich seh keinen Fehler in dem Code, aber das heißt ja nix. Übersehe ich irgendwas? Oder kann man nicht mit einem nanoCUL IT empfangen und gleichzeitig senden? Ich habe hierzu weder im Wiki noch sonstwo was gefunden, aber vielleicht habe ich's ja auch übersehen. Das einzige was ich bei der Suche sonst so gefunden habe, war eine Verdrahtungsfehler zwischen Raspi und nanoCUL. Das habe ich bei mir aber schon mal kontrolliert, das passt.

Danke vorab! Und wenn ich noch mehr Infos liefern soll, einfach sagen.

Grüße

[kaihs]

Ich hatte es vor ein paar Tagen bereits in einem anderen Thread geschrieben, deshalb hier  nur die Kurzfassung : zwischen Empfang und Senden muss eine kurze Pause sein damit sich die Signale nicht überlagern. Ein sleep 0.5 sollte reichen.

[hanshome]

Danke, das war's. Den anderen Thread hatte ich natürlich nicht gefunden. Sollte man das vielleicht irgendwo im Wiki unterbringen? Vielleicht bei SlowRF?

EDIT: Bei mir reicht auch noch ein sleep 0.25. Ein 0.1 ist allerdings zu wenig.

[KölnSolar]

Sollte man das vielleicht irgendwo im Wiki unterbringen?

Ich bin mir da nicht sicher. Habe den Fall mit einem busware-CUL auf meinem Testsystem(wenig Sendelast, wenig notifys .....) nachgestellt und funktioniert auch ohne sleep.

@kaihs: Ist das möglicherweise nur auf den nanoCUL bezogen oder hängt es eher mit "sonstigen" Randbedingungen des Systems zusammen ?
Grüße Markus

[kaihs]

Das hat m. E. nichts mit dem verwendeten Funkinterface zu tun, sondern mit dem Funkprotokoll.

Da es bei diesen Protokollen keine Rückmeldung vom Empfänger gibt sendet der Sender zur Sicherheit das selbe Telegramm mehrfach, z. B. fünfmal.
Die simplen Empfänger wie Steckdosen reagieren dann erst wenn sie ein Telegramm z. B. dreimal direkt nacheinander erhalten.

In fhem gibt es solch eine Logik normalerweise nicht, direkt nach dem ersten Empfang eines Telegramms wird reagiert.
Wird dann unmittelbar auf der selben Frequenz von fhem gesendet, so überschneidet sich das mit dem noch sendenden Sender (s.o.).

Beim Senden gibt es ja diese Wiederholung auch in fhem/culfw, siehe http://culfw.de/commandref.html#cmd_i und das Attribut ITrepetition im IT Modul.

[karo]

Hallo kaihs,
ich habe / hatte vor ein paar Tagen ein ähnliches Problem, den Thread habe ich geschlossen.
Meine Definition des notifiers sieht wie folgt aus:

Code Auswählen Erweitern


kschalter:(on|off) sleep 0.5 ; set kdose $EVENT

Zumindest bei mir ist es so, dass bei Betätigen des Schalters im Webinterface im Log nur ein Schaltbefehl an die Dose (ITR-1500)  aufgezeichnet wird (2 mal schalten):

Code Auswählen Erweitern


2017.01.15 10:24:27 2: culNano433 IT_set: kschalter on
2017.01.15 10:24:27 2: culNano433 IT_set: kdose on
2017.01.15 10:24:36 2: culNano433 IT_set: kschalter off
2017.01.15 10:24:36 2: culNano433 IT_set: kdose off


Schalte ich nun mit dem Lichtschalter (Hardware its-2000), dann erhalte ich folgende log-Einträge, ebenfalls zwei mal schalten

Code Auswählen Erweitern


2017.01.15 10:26:20 3: culNano433 IT: kschalter off->on
2017.01.15 10:26:20 2: culNano433 IT_set: kdose on
2017.01.15 10:26:21 3: culNano433 IT: kschalter on->on
2017.01.15 10:26:22 2: culNano433 IT_set: kdose on

2017.01.15 10:26:27 3: culNano433 IT: kschalter on->off
2017.01.15 10:26:28 2: culNano433 IT_set: kdose off
2017.01.15 10:26:28 3: culNano433 IT: kschalter off->off
2017.01.15 10:26:29 2: culNano433 IT_set: kdose off

Es sind zwei Einträge pro Schaltvorgang (bei einer anderen Dose Obi/CMI hatte ich vier Einträge).
Die Dose schaltet, aber mit ca 2 Sekunden Verzögerung.


Setze ich den sleep auf 1.5 Sekunden, also

Code Auswählen Erweitern

kschalter:(on|off) sleep 1.5 ; set kdose $EVENT
so schaltet die Dose überhaupt nicht und ich sehe im Log:

Code Auswählen Erweitern


2017.01.15 10:34:15 3: culNano433 IT: kschalter off->on
2017.01.15 10:34:17 2: culNano433 IT_set: kdose on

2017.01.15 10:34:31 3: culNano433 IT: kschalter on->off
2017.01.15 10:34:32 2: culNano433 IT_set: kdose off

Nach dem ersten Schalten habe ich langsam bis 10 gezählt. Die Dose ist nicht angeschaltet worden. Damit hat das aus natürlich keine Wirkung.

Lösche ich den Sleep, dann habe ich 3 Einträge  bei Schalten per ITS-2000 im Log und die Dose schaltet nicht:

Code Auswählen Erweitern


2017.01.15 10:39:28 3: culNano433 IT: kschalter off->on
2017.01.15 10:39:28 2: culNano433 IT_set: kdose on
2017.01.15 10:39:29 3: culNano433 IT: kschalter on->on
2017.01.15 10:39:29 2: culNano433 IT_set: kdose on
2017.01.15 10:39:29 3: culNano433 IT: kschalter on->on
2017.01.15 10:39:29 2: culNano433 IT_set: kdose on

2017.01.15 10:39:41 3: culNano433 IT: kschalter on->off
2017.01.15 10:39:41 2: culNano433 IT_set: kdose off
2017.01.15 10:39:41 3: culNano433 IT: kschalter off->off
2017.01.15 10:39:41 2: culNano433 IT_set: kdose off
2017.01.15 10:39:42 3: culNano433 IT: kschalter off->off
2017.01.15 10:39:42 2: culNano433 IT_set: kdose off


Zusammenfassend meine (vielleicht falsche) Lesart der Protokoll-Einträge
Schalten per Webinterface: Ein Befehl über notify an kdose, diese schaltet.
Schalten per ITS-2000, kein sleep              : drei Befehle über notify an kdose, sie schaltet nicht
Schalten per ITS-2000, 0.5 Sekunden sleep: zwei Befehle über notify an kdose, sie schaltet
Schalten per ITS-2000, 1.5 Sekunden sleep: ein Befehl über notify an kdose, sie schaltet nicht

Das verstehe ich immer noch nicht. Verwendet wird auf dem culNano433: culNano433 version => V 1.23.05 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)

Grüße
   Karsten

[kaihs]

Zumindest bei mir ist es so, dass bei Betätigen des Schalters im Webinterface im Log nur ein Schaltbefehl an die Dose (ITR-1500)  aufgezeichnet wird (2 mal schalten):

Ich habe jetzt nicht alle deine Logs analysiert, aber hier gibt es wohl noch ein Missverständnis.

Die Sendewiederholung wird nicht von fhem durchgeführt, sondern vom IO-Device, also. z. B. dem CUL
Ich weiß nicht wie die Standardeinstellung dafür in der aculfw ist, aber sicher > 1.

Ich verweise dazu nochmal auf http://culfw.de/commandref.html#cmd_i und das Attribut ITrepetition im IT Modul.

In den Sendern wird oft das IC PT2262, verwendet. In dessen Datenblatt steht:

CODE FRAME
A Code Frame consists of four (4) continuous Code Words. When PT2262 detects "0" on the /TE (meaning, the /TE is
active "low"), it outputs a Code Frame at DOUT. If /TE is still active at the time the Code Frame transmission ends, T2262
outputs another Code Frame. It should be noted that the Code Frame is synthesized at the time of transmission.

Der wiederholt also viermal.

Das IC PT2272 ist der zugehörige Empfänger, bei dem steht:

VALID TRANSMISSION
When PT2272 receives a transmission code word, it initially checks whether this is a valid transmission. For a transmission
to be valid, (1) it must be a Complete Code Word, and (2) the Address Bits must match the Address Setting at the Address
Pins. After two consecutive valid transmissions, PT2272 (1) drives the data pins according to the data bits received, and (2)
raises VT to high voltage (high state).

Der reagiert also erst nach zwei empfangenen Paketen.

Man könnte jetzt ausrechnen oder ausmessen, wie lange so ein vierfaches Senden dauert.
Dazu fehlt mir gerade die Muße, vielleicht fühlt sich jemand anders angesprochen.