PCA301 Steckdose: Rückmeldung auswerten

Begonnen von Schlimbo, 11 Oktober 2015, 09:44:35

Vorheriges Thema - Nächstes Thema

Schlimbo

Hallo zusammen,

Es ist ja bekannt, dass die PCA301 Funksteckdosen nicht immer zuverlässig schalten.
Die Steckdose gibt nach dem senden eines Befehle immer den aktuellen Status zurück.
Manchmal passiert es aber, das die Steckdose nach einem z.B "set-on" nicht Schaltet und den Zustand "off"  zurück gibt. 

Ich habe mir jetzt ein kleines Script in der 99_myUtils erstellt,  um die Rückmeldung zu überwachen und bei einer falsch Rückmeldung das Kommando nochmal zu Senden.

Der Aufruf sieht so aus:
define PCA301.ntfy notify .*.(on|off|set-on|set-off) {if($TYPE eq 'PCA301') {PCA301_check($NAME,$EVENT)}}


und das Script in der 99_myUtils:
sub PCA301_check($$){
  my ($Name,$Event) = @_;

  #Reading warte auf acknowledge setzen
  if (($Event eq "set-on") or ($Event eq "set-off")) {
    readingsSingleUpdate($defs{$Name}, "waitforACK", $Event,1);
    Log 1, ("PCA301_check: Schaltsignal $Event zu $Name gesendet");
  }

  #Rückmeldung Kontrollieren
  if ($Event eq "on") {
    if (ReadingsVal($Name, 'waitforACK', '') eq "set-on") {
      readingsSingleUpdate($defs{$Name}, "waitforACK", "ACK:on",1);
      Log 1, ("PCA301_check: Rückmeldung $Event von $Name erhalten");
    } elsif (ReadingsVal($Name, 'waitforACK', '') eq "set-off") {
      fhem ("sleep 1;set $Name off");
      Log 1, ("PCA301_check: Falsche Rückmeldung $Event von $Name erhalten");
    }
  } elsif ($Event eq "off") {
    if (ReadingsVal($Name, 'waitforACK', '') eq "set-off") {
      readingsSingleUpdate($defs{$Name}, "waitforACK", "ACK:off",1);
      Log 1, ("PCA301_check: Rückmeldung $Event von $Name erhalten");
 
    } elsif (ReadingsVal($Name, 'waitforACK', '') eq "set-on") {
     fhem ("sleep 1;set $Name on");
     Log 1, ("PCA301_check: Falsche Rückmeldung $Event von $Name erhalten");
    }
  }
}


Zur Funktion:
Beim senden von "set-on" oder "set-off" wird  am jeweiligen Device ein Userreading "waitforACK" mit dem Schaltbefehl gesetzt.
Kommt eine Rückmeldung von der Steckdose wird der Status mit dem letzten Schaltbefehl vergleichen.
Stimmt die Rückmeldung mit dem "set-Befehl"  überein,  wird das Reading auf "OK" gesetzt, stimmt es nicht überein wird der Befehl noch einmal gesendet.

Hoffe ich konnte damit einigen Helfen, die das selbe Problem mit den PCA301 Dosen haben.

Gruß Schlimbo


justme1968

#1
schau mal hier: http://forum.fhem.de/index.php/topic,11648.msg320423.html#msg320423 und drei posts danach da gibt es zwei varianten die das mit einem watchdog löst. entweder für genau einen retry oder so lange bis wirklich geschaltet wurde.

gruss
  andre

edit: ich hab beide varianten ins wiki gestellt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Schlimbo

Hallo justme1968,

ja die Variante habe ich mir auch schon angesehen, allerdings wollte ich nicht für jede Dose einen eigenen Aufruf.
Mit meiner Variante werden alle Dosen überwachen und ich muss mir bei neuen Dosen keinen Kopf mehr machen.
Ach habe ich keine endlos Schleife, wenn ein set-Kommando an eine Dose gesendet wird, die nicht eingesteckt ist,  denn das Script sendet nur,  wenn es eine falsche Rückmeldung bekommt, kommt gar keine Rückmeldung passiert auch nichts.

justme1968

ob ein einziges notify effizienter ist als je ein watchdog hängt sehr davon ab wie viele dosen es wirklich sind. die event handler sind intern effizienter wenn sie nur auf ein einziges device definiert sind.

das dauernde senden gibt es nur wenn man den watchdog in der zweiten reihenfolge verwendet. es kann ja durchaus erwünscht sein auch ein kurzes raus ziehen und wieder reinstecken zu behandeln.

ansonsten ist es doch schön wenn es mehr als eine lösung mit unterschiedlichen schwerpunkten gibt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Schlimbo

Da hast du natürlich recht, sollte auch keine Kritik an der watchdog Lösung sein.
Danke fürs ins Wiki stellen.
Gruß Schlimbo

Posti123

18xHM-CC-RT-DN, 5xHM-TC-IT-WM-W-EU, HMLAN, 2xJeeLink 868, 1xJeeLink433, 1xCUL868, HM-LC-Bl1PBU-FM, HM-LC-Sw2-FM, HM-LC-SW1-FM, HM-LC-Sw1PBU-FM, 5xHM-Sec-SC-2, 2xHM-Sec-SCo, HM-ES-TX-WM, HM-Sen-MDIR-O-2, HM-WDS10-TH-O, 6xTechnoline, 2x PCA301,2xHM-PB-2-WM55-2,2xHM-RC-4-2,2xHM-WDS30-T-O, HM-SEC-WDS-2

ioT4db

Hallo, ich bin übers Wiki in diesem Thread gelandet und es behandelt genau mein Problem - danke für die beiden Lösungsansätze!

Nur muß ich kurz nochmal nachhaken was die Vor- bzw. Nachteile der beiden Lösungen betrifft. Ich skizziers mal wie ich es verstanden hab:

Watchdog:
+ zuverlässiger, da über event handler die einzelne Dose angesprochen wird
- bei vielen Dosen unübersichtlicher, da mehr code

Notify + Skript in 99_myUtils
+ übersichtlicher, da einmal eingerichtet alle Dosen vom Typ PCA301 damit erreicht werden
- ?

Das "-" bei der Notify-Lösung ist mir nur noch nicht ganz klar. Könnte es hier so sein, dass da wieder Dosen "durchs Raster fallen", da bei erhöhtem Schaltaufkommen Befehle verloren gehen können???

Für mich sieht die Notify-Lösung programmiertechnisch schöner aus. Da ich aber in Kürze mehr als meine momentan 6 Dosen betreiben möchte, ist mir die Zuverlässigkeit wichtiger, als die Übersichtlichkeit.

BTW: in dem Thread, den "justme1968" verlinkt hat, wurde ja auch schon drüber gesprochen die Funktionalität direkt in den Sketch einzubauen. Wäre das nicht die beste Lösung?

Danke schonmal für eure Hilfe...
Daniel



FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

Schlimbo

Hallo Daniel,
Sehe momentan keinen Grund warum die eine Lösung zuverlässiger sein sollte als die andere.
Seit dem ich das Skript bei mir am laufen habe, hatte eich kein Problem mit fehlschaltungen mehr. Würde mich hier aber über Rückmeldungen freuen, wie zuverlässig das Skript bei anderen läuft.
Denke auch dass Andre mit "effizienter" nicht "zuverlässiger" gemeint hat, sondern das eher auf die Systemlast bezogen hatte und wenn man nur eins, zwei Dosen nutzt kein großes Skript bemühen muss. 
Generell fände ich es natürlich auch am besten, wenn das Sketch dies schon mit abfangen würde,  weiß aber nicht ob hierzu noch etwas geplant ist.

Gruß
Schlimbo

ioT4db

Hallo Schlimbo,

ok, verstehe.

Das mit der noch fehlenden Implementierung direkt im Sketch könnte vielleicht am beschränkten Speicher des Arduinos hängen, hatte da mal sowas gelesen, weiß es aber nicht genau.

Auf jeden Fall funktioniert Dein Skipt tadellos und macht die PCA301 zu nun zuverlässigen Aktoren. Systemlast ist deswegen nicht merklich gestiegen. Aber ich betreibe ja unter 10 Stück, mal sehen wie es wird wenn ich noch mehr dran hänge.

Momentan kann ich sagen, dass jede meiner 6 Stecker bis dato mindestens einmal eine Falschmeldung beim ersten mal zurückgegeben hat, aber nie mehr als 2 Durchläufe gebraucht hat, um den Schaltbefehl umzusetzen.

Danke nochmal und Grüße
Daniel
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

Schlimbo

Ab FHEM Version 5.7 muss im notify "%" durch "$" ersetzt werden: http://forum.fhem.de/index.php/topic,44094.0.html

alter code:

define PCA301.ntfy notify .*.(on|off|set-on|set-off) {if("%TYPE" eq 'PCA301') {PCA301_check("%NAME","%EVENT")}}


neuer code:
define PCA301.ntfy notify .*.(on|off|set-on|set-off) {if("$TYPE" eq 'PCA301') {PCA301_check("$NAME","$EVENT")}}

Habe meinen ersten Eintrag schon abgeändert.

@andre: Könntest du bitte den Wiki Eintrag auch noch anpassen?  Danke

justme1968

hatte krikan schon gemacht. ich habe aber eben noch mal etwas bei den unnötigen " aufgeräumt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

pnewman

Hallo Schlimbo,

vielen Dank für das Script.
Nun benötige ich nicht für jede PCA301 2 Watchdogs!


durch die Einträge im LOG kann ich den Erfolg sehen:

2016.02.20 11:13:13 1: PCA301_check: Schaltsignal set-off zu OG.hz.SD.WP gesendet
2016.02.20 11:13:13 1: PCA301_check: Rückmeldung off von OG.hz.SD.WP erhalten
2016.02.20 11:15:44 1: PCA301_check: Schaltsignal set-off zu OG.hz.SD.WP gesendet
2016.02.20 11:15:51 1: PCA301_check: Rückmeldung off von OG.hz.SD.WP erhalten
2016.02.20 11:25:04 1: PCA301_check: Schaltsignal set-on zu OG.hz.SD.WP gesendet
2016.02.20 11:25:04 1: PCA301_check: Rückmeldung on von OG.hz.SD.WP erhalten
2016.02.20 11:27:38 1: PCA301_check: Schaltsignal set-off zu OG.hz.SD.WP gesendet
2016.02.20 11:27:39 1: PCA301_check: Falsche Rückmeldung on von OG.hz.SD.WP erhalten
2016.02.20 11:27:40 1: PCA301_check: Schaltsignal set-off zu OG.hz.SD.WP gesendet
2016.02.20 11:27:40 1: PCA301_check: Rückmeldung off von OG.hz.SD.WP erhalten
2016.02.20 11:28:04 1: PCA301_check: Schaltsignal set-off zu OG.hz.SD.WP gesendet
2016.02.20 11:28:04 1: PCA301_check: Rückmeldung off von OG.hz.SD.WP erhalten



Gruß
Ralf
Raspberry Pi3B+ / Nano-Cul 868 - MAX!=Heizung, HM-Lan - Rollo+Licht, JeeLink-Clone 868 - LaCrosse, JeeLink-Clone 868 - PCA301, CUL 434 - IT-Steckdosen+Fernbedienung