Well-Light (433 MHz) Funksteckdosen und Signalduino

[Ralf9]

Hallo @HomeAuto_User,

bitte gib bescheid, falls Du fürs übernehmen ins offizelle Modul noch was benötigst.

Gruß Ralf

[Ralf9]

@HomeAuto_User,

liest Du hier noch mit?

[HomeAuto_User]

Hallo Ralf,

Das hier hochgeladene Modul ist erst mal nur zum Testen, per PM kann ich ja keine Anlagen mitschicken.
Die Bitte es zu übernehmen wäre noch gekommen.
Die Bitte es ins offizelle Modul zu übernehmen reiche ich hiermit nach. Die Protocol ID 201 ist nur ein Platzhalter, Du kannst gerne eine freie Protocol ID raussuchen.

das war keine Kritik. Wir müssen nur aufpassen und ggf. das für den User besser beziffern, das es sich nur um ein Modul zum testen handelt.

Hallo @HomeAuto_User,

bitte gib bescheid, falls Du fürs übernehmen ins offizelle Modul noch was benötigst.

Gruß Ralf

Ich habe es auf dem Schirm und werde es nach dem Urlaub einspielen.

@HomeAuto_User,

liest Du hier noch mit?

Ich lese nicht jeden Faden hier mit.
Es ist für die Zukunft vielleicht hilfreich in solchen Fällen eine PN zu senden mit dem Forumslink weil da erhalte ich sofort eine Benachrichtigung weitergeleitet.

Die Einarbeitung wird erfolgen aber die private Auszeit geht vor sonst kommt der böse Blick von Frauchen

Grüße Marco

[Ralf9]

Es ist für die Zukunft vielleicht hilfreich in solchen Fällen eine PN zu senden mit dem Forumslink weil da erhalte ich sofort eine Benachrichtigung weitergeleitet.

es wäre dazu hilfreich, wenn Du dies "(Link als PM an HomeAuto_User)" in die MAINTAINER.txt eintragen würdest, wie es z.B. auch tupol macht.

[Ralf9]

Ich habe in der aktuellen dev-Version meiner Variante der 00_SIGNALduino.pm für Well-Light die Protocol Id von 201 nach 114 geändert.

Damit es mit der Protocol Id 114 funktioniert, muss die 14_SD_UT.pm in der Anlage verwendet werden.

Gruß Ralf

[HomeAuto_User]

Hallo Ralf,
dein Anliegen ist nicht vergessen. Es liegt schon in der Schublade.
Zur Info, das Model wird bei mir etwas anders heißen, da Well-Light nur ein Händler ist und der ChinaHersteller die Remote mit TR401 beziffert. Somit heißt das Model in der Übernahme nur TR401.

Die Tage wird es überrnommen.

MfG

[HomeAuto_User]

Hallo Ralf,
Hallo Jake,

die Erweiterung / Anpassung im Modul SD_UT wurde vollzogen und befindet sich im SVN.
Mfg

[Ralf9]

Ich habe es getestet, es funktioniert, habe aber vergessen die WellLight_TR401 devices vor dem austauschen des  SD_UT Modul zu löschen.
Da Du das Model umbenannt hast, wurden die WellLight_TR401 nicht mehr geladen, ich musste in der fhem.cfg alle "WellLight_TR401" in "TR401" umbenennen.

Gruß Ralf

[KölnSolar]

Hallo Ihr Zwei,
ich hab eine alte Alarmanlage "ausgegraben".
Bei einer FB zeigt der Signalduino mir P114 an.
Zuerst war ich aber auf dem "Trip", dass es Button_five sein könnte, weil der Holtek HT12E verbaut ist. Aber in P29 ist das Protokoll gar nicht nach Datenblatt.

Ich hab die Vermutung, dass einige Protokolle auf dem HT12E basieren. Es kommen 29, 30,79,81,83,86 u. 114 in Frage, weil alle die Spec

Code Auswählen Erweitern

one => [-2,1],
zero => [-1,2],
clockpos => ['one',1],
format          => 'twostate',
length_min      => '12',
length_max      => '12',wie der HT12E haben.
Grundsätzlich hat der HT12E 8 Adressbits und 4 Datenbits(bei p29 Westinghouse hat man das wohl unsauber implementiert).
Die Präambel beträgt 12bits low(36 Pulse), ein Syncpuls high und dann die 12bits. Das Ganze mindestens 4 Mal.

Hinzu kommt, dass die base clock je nach Hardwareimplementierung unterschiedlich sein kann. Das lässt sich durch einen Widerstand zwischen den Oszillator-Pins "einstellen". Bei mir ist es ein 3MOhm(Datenblatt empfiehlt 1,1 MOhm=3kHz) was zu ca. 1 kHz und baseclock=1ms  führen müsste. Allerdings bekomme ich ca. 700µs als baseclock(Standard wäre 333µs).

Code Auswählen Erweitern

2022-05-21 06:46:04 SD_UT unknown_please_select_model unknownMSG: 100100110100  (protocol: 114)
MU;P0=7772;P1=-1451;P2=565;P3=-767;P4=1259;P5=-23378;CP=2;R=58;D=01234341234341212341234345212343412343412123412343452123434123434121234123434521;e;0also ca. 1,4kHz.
Die base clock ist auch noch spannungsabhängig. Ich gehe daher davon aus, dass Empfänger(HT12D) sehr tolerant bzgl. der Pulsweiten sind.
Und hier stellt sich mir die 1. Frage:
Wie tolerant ist der Signalduino(mit cc1101) ? Ich vermute, dass die base clock noch "egal" ist, aber wie sieht es mit den Pulslängen low/high bzw. zero/one aus ?
(Hintergrund ist auch, dass weder meine 2. Fb, noch der Bwm vom Signalduino erkannt werden)
Seht Ihr wie ich den Sinn, ein "allgemeingültiges" Protokoll für den HT12E zu implementieren ?

Grüße Markus

[Ralf9]

Wie tolerant ist der Signalduino(mit cc1101) ? Ich vermute, dass die base clock noch "egal" ist, aber wie sieht es mit den Pulslängen low/high bzw. zero/one aus ?
(Hintergrund ist auch, dass weder meine 2. Fb, noch der Bwm vom Signalduino erkannt werden)
Seht Ihr wie ich den Sinn, ein "allgemeingültiges" Protokoll für den HT12E zu implementieren ?

In der Parse Routine des 00_SIGNALduino Modul wird geprüft ob "one". "zero", "clock" und "sync" oder "start" innerhalb der Toleranz sind.
Der Toleranzfaktor ist abhängig vom Wert:

Code Auswählen Erweitern


my $tol=abs(abs($searchpattern)>3 ? abs($searchpattern)>16 ? $searchpattern*0.18 : $searchpattern*0.3 : 1);  #tol is minimum 1 or higer, depending on our searched pulselengh

Dadurch, dass dadurch die verschiedenen Sensoren eine unterschiedliche Protocol ID haben, können diese von SD_UT Modul unterschiedlich behandelt werden.

Gruß Ralf

[KölnSolar]

Edit2: Jetzt bin ich mal wieder verwirrt. Es gibt die SD_ProtocalData.pm und die signalduino_protocols.pm. Irgendwie sehen die ja grundsätzlich gleich aus. Aber in den Details dann doch ander. Speziell bei mir beim P114.  ???Ich hab mich die ganze Zeit inhaltlich auf die signalduino_protocols.pm bezogen. Wo ist denn da jetzt der Unterschied in der Verwendung ? Sidey- oder Ralf-Version ??




Danke Ralf,
durch Deinen Hinweis bin ich auf das Attribut debug gestoßen und mit whitelist=114 und debug=1 glaube ich nun die message der 2.Fb in meiner äußerst mit 433-OOK belasteten Umgebung "entdeckt" zu haben

Code Auswählen Erweitern


2022.05.24 07:27:03 1: DEBUG>Sduino: incoming message: (MU;P0=28168;P1=-1791;P2=833;P3=-895;P4=1734;P5=-29238;CP=2;R=67;D=0123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345;e;)

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 0 28168

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 1 -1791

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 2 833

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 3 -895

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 4 1734

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  pattern 5 -29238

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  clockidx 2

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted RSSI 67

2022.05.24 07:27:03 1: DEBUG>Sduino: extracted  data 0123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345

2022.05.24 07:27:03 1: DEBUG>Sduino: unknown Message part e
2022.05.24 07:27:03 1: DEBUG>Sduino: processing unsynced message

2022.05.24 07:27:03 1: DEBUG>Testing against Protocol id 114 -> Well-Light
2022.05.24 07:27:03 1: DEBUG>Searching in patternList: $VAR1 = {
          '3' => '-1.6',
          '5' => '-51.3',
          '4' => '3.0',
          '2' => '1.5',
          '1' => '-3.1',
          '0' => '49.4'
        };

2022.05.24 07:27:03 1: DEBUG>msgStartLst: $VAR1 = [
          -41,
          1
        ];

2022.05.24 07:27:03 1: DEBUG>tol: looking for (-41 +- 7.38)
Wenn ich es richtig interpretiere, scheitert die Erkennung an der Präämbel.
Vergleicht man die  Pulse

Fb1        Fb2
P0     7772    28168
P1    -1451    -1791
P2      565      833
P3     -767     -895
P4      1259     1734
P5   -23378   -29238

, fällt auf, dass Fb2 "sauberer" gem. Datenblatt funkt und ich durch Änderung der

Code Auswählen Erweitern

clockabs        => 850,
die 2. Fb erkennen könnte.
Oder wäre es "variabler"(Erkennung beider Fb's), wenn ich clockabs rausnehme ? Wird dann im Beispiel P2 als clock pulse(wegen clockpos      => ['one',1]) genommen ?
Grüße Markus

Edit: Kann ich fürs Testen einfach die SD_ProtocolData.pm anpassen und wie kriege ich die Änderung per reload lib/SD_ProtocolData.pm aktiviert ? Der 2. slash wird immer entfernt. Kann ich den irgendwie maskieren ?
(shutdown/restart ist immer so aufwändig bei mir)

[Ralf9]

Code Auswählen Erweitern


     Fb1        Fb2
P0     7772    28168
P1    -1451    -1791
P2      565      833
P3     -767     -895
P4      1259     1734
P5   -23378   -29238
Die Erkennung scheitert an der clockabs.
Bei MU-Nachrichten werden die Faktoren durch teilen durch die clockabs ermittelt, dies ergibt dann bei der Fb2:

Code Auswählen Erweitern

          '1' => '-3.6',
          '3' => '-1.8',
          '2' => '1.7',
          '0' => '56.3',
          '5' => '-58.5',
          '4' => '3.5'
Da passt dann start und evtl auch one und zero nicht.
Da ist eine neue Protocol Id mit einer clockabs von ca 850 notwendig.
Gibts bei dem SD_UT Modul bereits eine Protocol ID oder Model das zur Fb2 passt?

Die clockabs bei der Erkennung rauszunehmen ist bis jetzt nur bei MS-Nachrichten (clockabs = -1) möglich.

Edit: Kann ich fürs Testen einfach die SD_ProtocolData.pm anpassen und wie kriege ich die Änderung per reload lib/SD_ProtocolData.pm aktiviert ? Der 2. slash wird immer entfernt. Kann ich den irgendwie maskieren ?
(shutdown/restart ist immer so aufwändig bei mir)

Bei meiner Variante heißt die Datei signalduino_protocols.pm
Ein reload dieser Datei ist mir auch noch nicht gelungen, ob und wie das geht würde mich auch interessieren.

[KölnSolar]

Oh, da war ich knapp zu spät mit meinem Edit2. Kannst Du dazu was sagen ?
Und Deinen Post gelesen ist es nun beantwortet. 

Gibts bei dem SD_UT Modul bereits eine Protocol ID oder Model das zur Fb2 passt?

Nein, da passt nichts. Blöd nur, dass Fb1 und Fb2 ja beide von der Alarmanlage vernünftig empfangen werden.
So langsam scheint mir mein Gedanke EIN Protokoll für HT12E wohl nicht umsetzbar.

Ein reload dieser Datei ist mir auch noch nicht gelungen, ob und wie das geht würde mich auch interessieren.

Dann mach ich mal ne Modifikation und shutdown/restart. 

[Ralf9]

Die Datei hat bei Sidey ursprünglich auch mal signalduino_protocols.pm geheissen, sie wurde von Sidey irgendwann mal in SD_ProtocalData.pm umbenannt.
Ich habe sie bei mir als signalduino_protocols.pm gelassen.

Bei mir gibts zusätzlich noch "clockpos", per default wird dies nur bei der Log Ausgabe verwendet, z.B.

Fingerprint for MU Protocol id 114 -> Well-Light matches, trying to demodulate, msgClock=599 (one) is in tol

[KölnSolar]

Bingo.
Ich hab mal einen neuen Thread eröffnet, da hier ja zwar der HT21E genutzt wird, aber der Hersteller das Protokoll "seltsam" implementiert  hat.

Die Protokolle P30 u. P83(hier wird in der ...protocols ja auch verwiesen, dass es sich um den  HT12E-kompatiblen Chip M1EN handelt) kommen dem Standard-HT21E sehr nahe. Wie ich schon geschrieben(spekuliert) hatte aber in der Clock abweichend(durch einen anders gewählten Oszillator-Widerstand). Würde es nicht trotzdem Sinn machen dise Protokolle zu vereinheitlichen und UTClock zu nutzen ? Oder wird die nur beim Senden benutzt ?

Grüße Markus