Well-Light (433 MHz) Funksteckdosen und Signalduino

[Ralf9]

Hallo Ralf9,

zuerst mal guten Tag hier im Forum.

Meine Funksteckdosen vom Typ Well-Light (433 MHz) werden vom Maple_Signalduino leider nicht erkannt.
Der Versuch des Sendens des Befehls schlägt fehl:

Code Auswählen Erweitern

set maple_sduino raw MC;;LL=-1048;;LH=908;;SL=-562;;SH=418;;D=A8CA345ACB860A916AFB7;;C=489;;L=84;;R=221;;s1;;b1;;


Warum sendet der Maple_Sduino den Raw Befehl nicht?

Bist Du sicher, daß diese MC-Nachricht von der Funksteckdose ist, dies sieht eher wie eine Nachricht von einem Temperatursensor aus

Bitte stelle das sduino Attribut verbose auf 4 und drücke ein paar mal eine Taste und poste dann den log Auszug

Gruß Ralf

[Jake]

Hallo Ralf9,

es ist extrem schwierig die FB-Tastendrücke zuzuordnen.
Anbei der Logauszug mit verbose 4:

Gruß, jake

[Ralf9]

Hallo jake,

Danke für das Log, dies ist ein bis jetzt noch unbekanntes Protokoll.
Dafür ist eine neue Protokolldefinition notwendig.

Code Auswählen Erweitern

"201" => # Well-Light
# https://forum.fhem.de/index.php/topic,121103.0.html
# MU;P0=1264;P1=-782;P3=-1561;P4=566;P5=-23639;P7=-425;CP=4;R=239;D=701010103434343434543410343410101034343434345434103434101010343434343454341034341010103434343434543410343410101034343434345434103434101010343434343454341034341010103434343434543;e;
{
name            => 'Well-Light',
changed         => '20210516 new',
id              => '201',
one             => [-2.6,1],
zero            => [-1.4 ,2.2],
start           => [-41,1],
clockabs        => 570,
clockpos        => ['one',1],
format          => 'twostate',
preamble        => 'u201#',
#clientmodule    => '',
#modulematch     => '',
length_min      => '12',
length_max      => '12',
}

Bitte kopiere die "00_SIGNALduino.pm" in der Anlage ins Verzeichnis /FHEM
und die "signalduino_protocols.pm" ins Verzeichnis /FHEM/lib
und mache danach einen restart von FHEM.

danach müsste so was ähniches im log auftauchen:

Code Auswählen Erweitern

maple_sduino: decoded matched MU Protocol id 201 dmsg u201#B1F length 12
maple_sduino Dispatch: u201#B1F
SIGNALduino_unknown incomming msg: u201#B1F
SIGNALduino_unknown converted to bits: 101100011111

Bitte drücke dann nacheinander alle Tasten und schreibe dann für jede Taste die emfangene msg auf
z.B.
Steckdose A on:
u201#31F
001100011111

Hat die Fernbedienung DIP-Schalter?

Gruß Ralf

[Jake]

Hallo Ralf,

vielen Dank für deine schnelle Hilfe.
Hier die gewünschten Daten:

Code Auswählen Erweitern


# Schalter Nr.1 an
SIGNALduino_unknown incomming msg: u201#11F
SIGNALduino_unknown rawData: 11F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 000100011111

# Schalter Nr.1 aus
SIGNALduino_unknown incomming msg: u201#91F
SIGNALduino_unknown rawData: 91F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 100100011111

# Schalter Nr.2 an
SIGNALduino_unknown incomming msg: u201#F1F
SIGNALduino_unknown rawData: F1F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 111100011111

# Schalter Nr.2 aus
SIGNALduino_unknown incomming msg: u201#31F
SIGNALduino_unknown rawData: 31F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 001100011111

# Schalter Nr.3 an
SIGNALduino_unknown incomming msg: u201#B1F
SIGNALduino_unknown rawData: B1F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 101100011111

# Schalter Nr.3 aus
SIGNALduino_unknown incomming msg: u201#F1F
SIGNALduino_unknown rawData: F1F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 111100011111

# Schalter Nr.4 an
SIGNALduino_unknown incomming msg: u201#51F
SIGNALduino_unknown rawData: 51F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 010100011111

# Schalter Nr.4 aus
SIGNALduino_unknown incomming msg: u201#D1F
SIGNALduino_unknown rawData: D1F
SIGNALduino_unknown Protocol: 201
SIGNALduino_unknown converted to bits: 110100011111



Der Sender hat 8 Taster ein/aus für 4 Steckdosen und 3 DIP-Schalter-Schalter für den Hauscode.
Jede Steckdose hat sechs DIP-Schalter. 3 für den Hauscode und 3 für die Codierung der maximal 4 Steckdosen.
Steckdose Nr.1=011 2=001 3=010 4=100


Gruß, Jake

[Ralf9]

für die Steckdosen 1 und 4 ist ein Schema erkennbar

Code Auswählen Erweitern

# Schalter Nr.1 an
u201#11F   0 001 00011111

# Schalter Nr.1 aus
u201#91F   1 001 00011111

# Schalter Nr.4 an
u201#51F  0 101 00011111

# Schalter Nr.4 aus
u201#D1F  1 101 00011111

s ccc hhh 11111

s :  0 an, 1 aus
ccc : Code für Steckdose 1 - 4
hhh : Hauscode


Bei den Steckdosen 2 und 3 passt es nicht, ist da evtl beim auslesen aus dem log was verrutscht?

Bitte teste mal,  ob bei den 3 DIP-Schalter für den Hauscode sich die 3 h-Bits ändern.

Du kannst auch mal testen ob sich damit eine Steckdose schalten lässt

Code Auswählen Erweitern

set maple_sduino sendMsg P201#0x11F#R6
oder
set maple_sduino sendMsg P201#0x91F#R6

Gruß Ralf

[Jake]

Hallo Ralf,

habe die Steckdosen-Codes nochmal nachgeprüft:

Code Auswählen Erweitern


Nr    an     aus
1     11F    91F   
2     31F    B1F
3     51F    D1F
4     61F    E1F


Das sollte jetzt ok sein, ab und zu tauchen auch F1F auf (siehe Logauszug).

Nach Ändern des Hauscodes von 111 auf 101 wurde statt der mittleren 1 eine 5 ausgegeben, also z.B. statt 31F => 35F.
Damit dürfte auch der Hauscode stimmen.

Senden hat nicht funktioniert. Das dürfte aber daran liegen, dass ich nur zwei 868 MHz Module habe, von denen eines auf 433 MHz betrieben wird. Evtl. ist dadurch die Sendeleistung zu schwach bzw. liegt neben der Frequenz. Der SDR ist bestellt, der 433 MHz Signalduino auch.

Danke, Jake

[Ralf9]

Hallo Jake

ab und zu tauchen auch F1F auf

Gibt es bei der Fernbedienung auch eine Taste mit der alle Steckdosen gemeinsam ein- oder ausgeschaltet werden können?

Senden hat nicht funktioniert.

Du kannst mal testen ob es funktioniert, wenn Du die repeat erhöhst, z.B. auf 15 oder 20

#R15 ist repeat 15

set maple_sduino sendMsg P201#0x11F#R15

Evtl. ist dadurch die Sendeleistung zu schwach bzw. liegt neben der Frequenz.

Wenn Du eine 433 MHz Antenne verwendest und sduino und Steckdosen im selben Raum sind, sollte es nicht so viel ausmachen.

[juergs]

Hallo Ralf,

Du kannst mal testen ob es funktioniert, wenn Du die repeat erhöhst, z.B. auf 15 oder 20

#R15 ist repeat 15

Mit #R20 hat das >Einschalten der Steckdose funktioniert!

Das Ausschalten leider noch nicht, die FB ist wesentlich stärker als der CC1101 und liegt auf 434.052 MHz.
Der Signalduino sitzt fest auf 433.920 MHz. Wäre evtl. es gut, das ITFrequency-Attribut setzen zu können. 

In audacity sieht man noch am Ende ein separates Telegramm. Evtl. mit der "Bedeutung" Taste losgelassen ...
Interessant: 12  Bit z.B. 0x39F-Code für EIN, aber Audacity zeigt: 13 Bit. Sowohl über FB, als auch über Signalduino. 

Grüße,
Jürgen

[Jake]

Hallo Ralf,

Funkschalterset Well-Light TR401
FB-Signal analysiert mit Gqrx und Audicity

Code Auswählen Erweitern


                Dip
Steckdose Nr. 1=011 2=001 3=010 4=100
              c 001   011   101   110
              s 0=ein 1=aus

         Dip    hhh
Hauscode 110 -> 100

                  0 sccc hhh
FB S1 ein:        0 1110 0110 0000 x-mal, dann 0 0000 0110 0000
FB S1 ein (inv):  1 0001 1001 1111 x-mal, dann 1 1111 1001 1111
FB S1 ein (hex):    1    9    F                  F    9    F

FB S1 aus:        0 0110 0110 0000 x-mal, dann 0 0000 0110 0000
FB S1 aus (inv):  1 1001 1001 1111 x-mal, dann 1 1111 1001 1111
FB S1 aus (hex):    9    9    F                  F    9    F 


                  0 sccc hhh
FB S2 ein:        0 1100 0110 0000 x-mal, dann 0 0000 0110 0000
FB S2 ein (inv):  1 0011 1001 1111 x-mal, dann 1 1111 1001 1111
FB S1 ein (hex):    3    9    F                  F    9    F

FB S2 aus:        0 0100 0110 0000 x-mal, dann 0 0000 0110 0000
FB S2 aus (inv):  1 1011 1001 1111 x-mal, dann 1 1111 1001 1111
FB S1 aus (hex):    B    9    F                  F    9    F

Diese beiden Steckdosen habe ich ausprobiert. R6 hat ausgereicht.

Die Codes sind (mit Hauscode 110 -> 100)

Code Auswählen Erweitern


Nr    an     aus
1     19F    99F   
2     39F    B9F
3     59F    D9F
4     69F    E9F

wie gehabt.

Funktioniert mit 868 MHz Signalduino über kurze Entfernung bestens. Wahrscheinlich hatte ich beim letzten Mal den falschen Hauscode eingestellt.

Was das Paket F9F am Ende zu bedeuten hat, konnte ich nicht klären.
Eine Alle-an-aus-Funktion gibt es nicht. 


Gruß, Jake

[Ralf9]

Danke ich schaus mirs mal an.

Funktioniert das Schalten auch ohne das F9F am Ende problemlos?

[Jake]

Ja, habe je nur einen Code (6x) gesendet.

Gruß, Jake

[Ralf9]

Ich habe mal den Well-Light TR401 ins 14_SD_UT.pm Modul eingebaut (siehe Anlage). versionModule 2021-06-26

Es ist dazu auch meine aktuelle dev Version des  00_SIGNALduino.pm Moduls notwendig
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/RFFHEM/dev/controls_dev_ralf9_signalduino.txt
versionmodul  v3.4.7-dev_ralf_24.06.
versionprotoL v3.4.7-dev_ralf_24.06.

z.B. damit
P201#B1F
wird das device "WellLight_TR401_0_2" (housecode 0 und Kanal 2) angelegt.

damit
P201#59F
wird das device "WellLight_TR401_4_3" (housecode 4 und Kanal 3) angelegt.

Das Senden müsste auch funktionieren

Gruß Ralf

[Jake]

Hallo Ralf,

funktioniert. Mit device WellLight_TR401_4_1 und WellLight_TR401_4_2 getestet.

Danke, Jake

[HomeAuto_User]

Hallo, (gelbe Karte) 

Ich bitte als Maintainer des SD_UT Modules nicht noch mehr Verwirrung zu stiften indem man einfach ein Modul erweitert ohne dies bekannt zu geben und anschließend hier im Forum hochläd.
Die Kontaktdaten hier im Forum und auf Github sind bekannt und so kann man mich kontaktieren. Mit einer eigenwilligen Erweiterungen bringt man noch mehr Verwirrung ein und irgendwann ist das Geschrei der User groß weil im SVN nichts angekommen ist. BITTE diesen Weg nicht wählen weil man so die gewillten Maintainer übergeht.

MfG

[Ralf9]

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.

Gruß Ralf

[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