added AVANTEK Wireless doorbell & LED night light

[HomeAutoUser]

• Please check if the PR fulfills these requirements

• Tests for the changes have been added / modified (needed for for bug fixes / features)
• commandref has been added / updated (needed for bug fixes / features)
• CHANGED has been updated (needed for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  feature

• What is the current behavior? (You can also link to an open issue here)
  no receive signal

• What is the new behavior (if this is a feature change)?
  receive signal

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

• Other information:

[HomeAutoUser]

@sidey79
als Testdaten kannst du die RAW nuzen aus dem Protokolldatei.
Bei Übernahme wird das JSON erweitert um diese Nachricht.

[sidey79]

@sidey79
als Testdaten kannst du die RAW nuzen aus dem Protokolldatei.
Bei Übernahme wird das JSON erweitert um diese Nachricht.

Wäre es möglich das JSON zuerst zu erweitern?
Dann hätten wir hier bereits die Testergebnisse zur Verfügung.

[HomeAutoUser]

@sidey79 bittesehr RFD-FHEM/SIGNALduino_TOOL@cb725f4

[sidey79]

Was hältst Du von einem einzeiler um $msg zu bilden?
my $msg = qq[SN;R=;$repeats;D=$split[1];98ABCDE;]

[HomeAutoUser]

Als Einzeiler ist es auch möglich.
Ich habe mich nach dem "Muster" des Bestandcodes orientiert, wo ich die Variable dann Schrittweise und sofort erkenntlich nacheinander fülle. Bei dem Einzeiler spart man Code und muss ggf 2x hinschauen.

[sidey79]

Für mich als Einzeiler eher erkennbar, wie hier msg zusammengesetzt wird.
Das auf mehrere Zeilen verteilen hätte ich jetzt als schwerer lesbar erachtet .

So sind die Geschmäcker wohl verschieden :)

[sidey79]

Wäre hier nicht sendMsg eher angebracht anstelle von raw um zu senden? Vermutlich hast Du dir was dabei gedacht was ich nicht auf Anhieb sehe :)

[HomeAutoUser]

Ich bilde mir ein vor zu Bett gehen, das sendMsg etwas Aufsich hatte wieso ich dies nicht nutzte.

[HomeAutoUser]

@sidey79 der Grund ist in der Verarbeitung von sendMsg. Dieses versucht anhand der Pattern alles zusammen zu bauen. Das gibt es bei FSK nicht :-) .

[sidey79]

Meinst Du damit, sendMSG kann derzeit kein FSK oder es gibt nichts zusammenzusetzen?
Zeile 221 sieht für mich auf den 1. Blick so aus, als ob dort etwas zusammengesetzt wird, was in sendMSG generisch erfolgen könnte.

Gibt es hier denn einen eklatanten Unterschied zu MC?

[HomeAutoUser]

@sidey79 der Unterschied besteht darin, das sendMSG aus der SD_ProtocolData.pm haben möchte wie Bsp:

        one             => [1,-8],  # 500,-4000
        zero            => [1,-4],  # 500,-2000
        sync            => [1,-18], # 500,-9000
        clockabs        => 500,

die Bsp. (Sync / Start/ ....) hier https://github.com/RFD-FHEM/RFFHEM/blob/master/FHEM/00_SIGNALduino.pm#L876-L917
benötigt werden. Diese gibt es aber nicht bei FSK:

      {
        name            => 'Avantek',
        comment         => 'Wireless doorbell & LED night light',
        id              => '112',
        knownFreqs      => '433.3',
        datarate        => '50.087',
        sync            => '0869',
        modulation      => '2-FSK',
        rfmode          => 'Avantek',
        register        => ['0001','0246','0301','0408','0569','06FF','0780','0802','0D10','0EAA','0F56','108A','11F8','1202','1322','14F8','1551','1916','1B43','1C40','20FB','2156','2211'],
        preamble        => 'P112#',
        clientmodule    => 'SD_BELL',
        length_min      => '16',
        length_max      => '16',
      },

Aus diesem Grunde wird die Routine raw genutzt.
Mit Unterschieden zu MC hat das nichts zu tun. Wenn du dir eine FSK Definition ansiehst, so siehst du den Unterschied zu ASK/OOK.

Die Routine sendMSG muss somit nicht für FSK abgeändert werden. Du würdest somit unnötig dort eingreifen.

[sidey79]

Ich bin wohl mal wieder der Spielverderber. :( Sorry schon mal dafür.

Ich verstehe den Ansatz. Es sieht auf den 1. Blick nach einfach und funktional aus.
Zugegeben, es ist auch funktional und auch erst einmal einfach.,

Allerdings halte ich nichts davon, dass das logische Modul, Befehle der verwendeten Hardware an das System übergibt.
Dazu einen kleinen Ausflug in die Vergangenheit.
Als ich das Signalduino Modul angefangen habe zu entwickeln, gab es bereits logische Module, hardware und phyische Module.
Vieles war auf einen CUL ausgelegt. Mein Ziel war es, ein physiches Modul für eine andere Hardware zu entwicken. Logische Module wollte ich mit nutzen. Eines war dann das IT Modul. Super gedacht. Empfangen war dann auch rasch umgesetzt, aber senden klappte so nicht, denn das IT Modul hat die Befehle von der Hardware direkt selbst abgesendet.
Also erst mal wrapper code und einen CUL für das Modul emuliert. Glücklicherweise konnte dem logischen Modul beigebracht werden, dass es auch andere Hardware als einen CUL gibt.

Worauf ich hinaus will ist vermutlich klar. Das logische Modul sollte nicht direkte Hardware Befehle übergeben.
Intuitiv würde ich auch nie darauf kommen, dass ich MU, MS, MC über sendMsg senden kann, aber MN nicht.
Die Implementierung könnte ähnlich wie bei MC erfolgen. Hier wird ja auch nichts umgewandelt.

Ich habe mich mit FSK Senden nicht sonderlich intensiv beschäftigt, aber Sync und die passenden Register müssen ja vermutlich für das Protokoll / Frequenz passend gesetzt werden und da sollten wir durch das phyische Modul vornehmen lassen und nicht hart in das logische Modul verdrahten.
Das führt nur Dazu, dass eine ggf. Zukünftige Hardware oder Firmware zu Kompatibilitätsverlust führt.

[HomeAutoUser]

Hallo Spielverderber @sidey79 grins

Ich denke zu verstehen was du erläutert hast.
Eine Nachbesserung erfolgte und ich hoffe nun es richtig umgesetzt zu haben nach deinen Vorstellungen.

Ich habe mich mit FSK Senden nicht sonderlich intensiv beschäftigt, aber Sync und die passenden Register müssen ja vermutlich für das Protokoll / Frequenz passend gesetzt werden und da sollten wir durch das phyische Modul vornehmen lassen und nicht hart in das logische Modul verdrahten.
Das führt nur Dazu, dass eine ggf. Zukünftige Hardware oder Firmware zu Kompatibilitätsverlust führt.

Vor dem Senden musst du das Register und Sync nicht setzen. Die Einstellungen sind schon vorgenommen mit dem rfmode Attribut übernommen wurden um überhaupt das Device zu empfangen.

[HomeAutoUser]

Hand heb

[sidey79]

Ich habe noch eine Frage,

an welcher Stelle wird der Sender auf die passende Betriebsart / Frequenz gestellt

[sidey79]

Ich habe noch eine Frage,

an welcher Stelle wird der Sender auf die passende Betriebsart / Frequenz gestellt

Okay, habe die vorherige Antwort noch mal gelesen. Bedeutet, der Empfänger muss zuvor mittels rfmode umgestellt werden, es ist nicht möglich den Empang auf z.B. OOK zu lassen und im Bedarfsfall dann beim Senden (so wie bei diversen anderen Protokollen) automatisch auf FSK umzustellen.

[HomeAutoUser]

Okay, habe die vorherige Antwort noch mal gelesen. Bedeutet, der Empfänger muss zuvor mittels rfmode umgestellt werden, es ist nicht möglich den Empang auf z.B. OOK zu lassen und im Bedarfsfall dann beim Senden (so wie bei diversen anderen Protokollen) automatisch auf FSK umzustellen.

Genau richtig. Du musst vorher wissen welche Hardware du hast weil der cc1101 sich nicht selbstständig umstellt. Man muss ja für die andere Modulation die Register umstellen.

Wenn du den Empfang auf OOK belässt und beim Senden auf FSK bringen möchtest, so müsste vor dem Senden immer der cc1101 umkonfiguriert werden. Das ganze geht einfacher mit mehreren cc1101. Da gibts schöne und einfache Umsetzungen smile