Autor Thema: [gelöst]Unzuverlässige Signalübertragung CUL433  (Gelesen 2132 mal)

Offline fhemjan

  • Jr. Member
  • **
  • Beiträge: 56
[gelöst]Unzuverlässige Signalübertragung CUL433
« am: 06 August 2022, 22:17:14 »
Hallo,
ich versuche gerade folgendes mit einem CUL433 mit a-culfw umzusetzen:
Ein PIR-1000 Bewegungsmelder löst aus, FHEM registriert das Signal. --> Eine ITR-1500 Steckdose wird angeschaltet.
Nach der einstellbaren Wartezeit des PIR-1000 (z.B. 5 Sec.) sendet dieser off und FHEM gibt das Signal an die Steckdose weiter.

Ich konnte den PIR-1000 und die ITR-1500 über autocreate anlernen.
Attribute PIR-1000:
IODev
nanoCUL
model
itremote
room
Arbeitszimmer

Attribute ITR-1500:
IODev
nanoCUL
model
itswitch
room
Arbeitszimmer

Die Steckdose kann ich sehr zuverlässig über den Knopf in FHEM schalten.
Und die Signale des PIR-1000 werden im Event monitor und auch im Icon angezeigt. Hier bei interessant: Es werden immer zwei Signale gesendet.

Nun habe ich ein notify erstellt:
define BewegungImFlur notify Bewegungsmelder set Steckdose $EVENTAufgrund der doppelten Signale des PIR-1000 habe ich das Attribut "disabledAfterTrigger" = 1 gesetzt.

Im Event monitor wird das alles herrlich angezeigt, jedoch tut sich bei der Steckdose nichts..
2022-08-06 22:09:46.130 IT IT_V3_19443ac1 off
2022-08-06 22:09:46.628 CUL nanoCUL raw: is00110010100010000111010110000001
2022-08-06 22:09:46.630 IT Bewegungsmelder off
2022-08-06 22:09:46.828 IT Bewegungsmelder off
2022-08-06 22:09:51.785 IT IT_V3_19443ac1 on
2022-08-06 22:09:52.284 CUL nanoCUL raw: is00110010100010000111010110010001
2022-08-06 22:09:52.286 IT Bewegungsmelder on
2022-08-06 22:09:52.484 IT Bewegungsmelder on
2022-08-06 22:09:56.028 IT IT_V3_19443ac1 off
2022-08-06 22:09:56.527 CUL nanoCUL raw: is00110010100010000111010110000001
2022-08-06 22:09:56.530 IT Bewegungsmelder off
2022-08-06 22:09:56.729 IT Bewegungsmelder off
2022-08-06 22:09:59.846 IT IT_V3_19443ac1 on
2022-08-06 22:10:00.344 CUL nanoCUL raw: is00110010100010000111010110010001
2022-08-06 22:10:00.346 IT Bewegungsmelder on
2022-08-06 22:10:00.542 IT Bewegungsmelder on
2022-08-06 22:10:06.879 IT IT_V3_19443ac1 off
2022-08-06 22:10:07.378 CUL nanoCUL raw: is00110010100010000111010110000001
2022-08-06 22:10:07.380 IT Bewegungsmelder off
2022-08-06 22:10:07.578 IT Bewegungsmelder off

Tendenziell finde ich das Timing der Signale komisch.. warum schaltet er erst die Steckdose bevor das Bewegungsmelder Signal geloggt wird? Zumindest passiert nichts. Zwischenzeitlich hatte es mal kurz und etwas unzuverlässig geklappt, aber nun nicht mehr.
Muss ich noch irgendwas am notify anpassen? Besten Dank schon mal.
« Letzte Änderung: 25 Oktober 2022, 14:56:01 von fhemjan »

Offline DetlefR

  • Full Member
  • ***
  • Beiträge: 297
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #1 am: 06 August 2022, 22:31:54 »
define BewegungImFlur notify Bewegungsmelder:.* set Steckdose $EVTPART1Und dann mal in Ruhe die Funktionsweise eines Notify durchlesen.

Zitat
Hier bei interessant: Es werden immer zwei Signale gesendet.
Das macht er nicht ohne Grund. Es gibt bei diesem System keine Rückmeldung. Da ist es schon besser wenn EIN/AUS doppelt kommt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19331
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #2 am: 06 August 2022, 22:40:17 »
define BewegungImFlur notify Bewegungsmelder:.* set Steckdose $EVTPART1
Sicher, dass $EVTPART1 in diesem Fall existiert ;) ?

Davon abgesehen: Macht es Sinn, die Steckdose nach 5 Sekunden wieder auszuschalten?

Und irgendwie kommt bei mir der Eindruck auf, dass das auszugsweise (teil-geschwärzte?) Posten nicht nur den TE durcheinanderbringt... Gibt es denn ein Device namens "Steckdose"?
Lesetipp: SetExtensions
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline fhemjan

  • Jr. Member
  • **
  • Beiträge: 56
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #3 am: 09 August 2022, 18:06:08 »
Vielen Dank schon einmal für eure Rückmeldungen!

@DetlefR: Danke für den Hinweis mit den zwei Signalen... Habe den disabledAfterTrigger Befehl wieder deaktiviert und nun reagiert die ITR zumindest ab und zu. Mit $EVTPART1 und dem :.* muss ich mich noch beschäftigen, leider ist mein Urlaub vorbei, daher muss ich mal schauen wann ich weiter testen kann.

@Beta-User: Die 5 Sek. waren nur zum testen, sonst dauert es solange... Zu den SetExtensions finde ich extrem wenig; ein paar Beiträge hier im Forum, die mir jedoch recht komplex erscheinen. In der Dokumentation hab ich nicht so recht was finden können.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19331
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #4 am: 09 August 2022, 19:48:29 »
SetExtensions werden von vielen Modulen genutzt, um "Timer-Aktionen" zu verwalten. Hier ein Beispiel:
define BewegungImFlur notify Bewegungsmelder:on sleep 0.2; set Steckdose on-for-timer 5Das "sleep" soll verhindern, dass sich das Signal vom Bewegungsmelder und das von FHEM an die Steckdose gehende Kommando funktechnisch überkreuzen.

Was es mit $EVTPART1 auf sich hat (und ggf. welche Bedenken hinter meiner Frage stehen) möge dir derjenige erklären, der meint, es würde funktionieren ;) .
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline fhemjan

  • Jr. Member
  • **
  • Beiträge: 56
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #5 am: 09 August 2022, 21:36:40 »
Hier ein Beispiel:
define BewegungImFlur notify Bewegungsmelder:on sleep 0.2; set Steckdose on-for-timer 5Das "sleep" soll verhindern, dass sich das Signal vom Bewegungsmelder und das von FHEM an die Steckdose gehende Kommando funktechnisch überkreuzen.

Ich hatte gerade kurz Zeit und hab genau das umgesetzt und es scheint super zu funktionieren :) Das on-for-timer hat er nicht direkt genommen, konnte ich aber per modify hinzufügen. Vielen Dank für das kleine Erfolgserlebnis ;) Nun kann die Reise weitergehen.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19331
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #6 am: 09 August 2022, 21:39:58 »
Oh, sorry, da hatte ich den Strichpunkt nicht escaped.

[gelöst]?

Kannst aber trotzdem gerne noch Fragen stellen, falls was offen ist ;) . Viel Spaß beim weiteren Einarbeiten!
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline fhemjan

  • Jr. Member
  • **
  • Beiträge: 56
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #7 am: 10 August 2022, 21:58:31 »
Ist gelöst, danke!
Was heißt Strichpunkt escaped?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19331
Antw:Unzuverlässige Signalübertragung CUL433
« Antwort #8 am: 11 August 2022, 15:22:45 »
Ist gelöst, danke!
Das war ein "Schubs" in Richtung https://forum.fhem.de/index.php/topic,71806.0.html

Zitat
Was heißt Strichpunkt escaped?
https://fhem.de/commandref_modular_DE.html#command
Dort dem Bereich um das eine fett markiete Wort herum besondere Beachtung schenken ;) .
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files
Gefällt mir Gefällt mir x 1 Liste anzeigen