nachfolgend die Fortsetzung für den HT21E. Begonnen hat es hier (https://forum.fhem.de/index.php/topic,121103.msg1222537.html#msg1222537)
mit "120" => # HT21E standard see datashet
{
name => 'HT21E',
comment => 'standard universal',
changed => '20220525 new',
id => '120',
one => [-2,1],
zero => [-1 ,2],
start => [-38,1],
clockabs => 800,
clockpos => ['one',1],
format => 'twostate',
preamble => 'P120#',
clientmodule => 'SD_UT',
#modulematch => '',
length_min => '12',
length_max => '12',
},
wird Fb2 und der Bwm empfangen. FB1 nur selten(logisch ::))
Nun kann ich auch das Protokoll übersetzen
8-Adressbits über Dip-Schalter einstellbar, wobei on=o u. off=1(entspricht beim HT12E elektrisch: GND=0 u. open=1)
die 4 Datenbits
0000b Bwm Bewegung(Dip: on-off-off=Zone 1)
1000b Bwm Bewegung(Dip: off-off-off=Zone 2)
1100b Bwm Batterie lowOK(eigentlich müsste der Bwm regelmäßig etwas übertragen, sonst geht an der Station die Warn-LED für "Batterie prüfen" an
0100b Fb Alarm Zone1/Zone2 off
0110b Fb Alarm Zone1/Zone2 on
1110b Fb Sofortalarm
Mehr hab ich nicht.
Ich hab dann SD_UT angepasst, so dass ich ein device anlegen kann, die Signale empfangen werden und auch das Senden funktioniert. 8)
Die Anlage "kann" funktechnisch nicht viel mehr . Tür-/Fensterkontakte(die ich nicht habe, aber jetzt bauen könnte),ein "Durchgangsmodus"(DingDong bei Bewegung) einstellbar.
Die nicht vorhandenen 11 weiteren Binär-Kombinationen hab ich mal gesendet, um zu sehen, was die bewirken. Und zumindest 2 weitere Codes lösen etwas aus.
0101b Fb Alarm Zone3 on(Durchgangsmodus)wurde ausgelöst(geht also auch per Funk und nicht nur über den Eingang Klemmen 1+2(NO); Zone 3 ist daueraktiv für z.B. Rauchmelder, Sabotagekontakt und löst sofort Alarm aus
1100b Fb Löst die LED "Batterie prüfen" aus
Also nur noch 9 Codes. Morgen ist ja auch noch ein Tag zumal die Anlage im Garten steht. Über die Nacht zeichne ich mal auf, was der Bwm so aus dem Garten meldet. :)
Probiere mal mit dieser Definition:
"190" => ## Remote controls B.E.G. Alarmanlage
# https://forum.fhem.de/index.php/topic,127798.0.html
{
name => 'BEG',
comment => 'remote control for B.E.G. Alarmanlage',
id => '190',
knownFreqs => '433.92',
one => [-2,1], # -1550,775
zero => [-1,2], # -775,1550
start => [-35,1], # -27125,775
clockabs => 775,
format => 'twostate',
preamble => 'P190#',
clientmodule => 'SD_UT',
modulematch => '^P190#.{3}',
length_min => '12',
length_max => '12',
},
Damit werden zumindest diese beiden Nachrichten der 2 Fernbedienungen dekodiert:
Fb1: Format Ralf9
MU;P0=7772;P1=-1451;P2=565;P3=-767;P4=1259;P5=-23378;CP=2;R=58;D=01234341234341212341234345212343412343412123412343452123434123434121234123434521;e;0;
Format Sidey
MU;P0=7772;P1=-1451;P2=565;P3=-767;P4=1259;P5=-23378;D=01234341234341212341234345212343412343412123412343452123434123434121234123434521;CP=2;R=58;
Fb2: Format Ralf9
MU;P0=28168;P1=-1791;P2=833;P3=-895;P4=1734;P5=-29238;CP=2;R=67;D=0123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345;e;
Format Sidey
MU;P0=28168;P1=-1791;P2=833;P3=-895;P4=1734;P5=-29238;D=0123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345212343412343412123412343452123434123434121234123434521234341234341212341234345;CP=2;R=67;
Die nächste freie Protocol Id müsste die 121 sein.
Es gibt auch die Möglichkeit für die FB1 und FB2 verschiedene Protocol IDs zu nehmen.
Ein universelles Protokoll bei dem die empfangene Clock (clockabs => -1) verwendet wird, wie z.B. bei der ID 3, würde bei MU-Nachrichten nur funktionieren, wenn die Clock in one und zero enthalten ist.
Wenn die clock nur in one oder zero enthalten ist, gibt es fälle wo die von der Firmware ermittelte clock nicht passt.
"121" => ## Remote controls B.E.G. Alarmanlage
# https://forum.fhem.de/index.php/topic,127798.0.html
{
name => 'BEG',
comment => 'remote control for B.E.G. Alarmanlage, clock 800',
id => '121',
changed => '20220525 new',
one => [-2,1],
zero => [-1,2],
start => [-35,1],
clockabs => 800,
clockpos => ['one',1],
format => 'twostate',
preamble => 'P121#',
clientmodule => 'SD_UT',
#modulematch => '',
length_min => '12',
length_max => '12',
},
"121.1" => ## Remote controls B.E.G. Alarmanlage
#
{
name => 'BEG',
comment => 'remote control for B.E.G. Alarmanlage, clock 550',
id => '121.1',
changed => '20220526 new',
one => [-2,1],
zero => [-1,2],
start => [-40,1],
clockabs => 550,
clockpos => ['one',1],
format => 'twostate',
preamble => 'P121#',
clientmodule => 'SD_UT',
#modulematch => '',
length_min => '12',
length_max => '12',
},
Die Id 121 habe ich zwar auch schon gerade in Bearbeitung, aber die können wir ja immer noch anpassen.
Ralf, wie kommst du bei der zweiten Definition auf clockabs von 550?
Ich würde da besser 675 nehmen (siehe Excel-Tabelle).
die clockabs von 550 ist nur ein ungefährer Wert, zum Mittelwert bilden und berechnen benötigen wir noch von beiden Fernbedienungen mehr Nachrichten
Fb1 F b2
P0 7772 28168
P1 -1451 -1791
P2 565 833
P3 -767 -895
P4 1259 1734
P5 -23378 -29238
evtl reicht auch ein protokoll, kannst Du bitte mal schauen wie stark bei der Fb1 und Fb2 die clock (P2) und Präambel (P5) schwanken.
Ich habs mal mit einer clock von 750 grob durchgerechnet:
Die Faktoren bei one und zero sollten bei einem Toleranzfaktor von 1 unkritisch sein
Mit einem Startfaktor von -35 ergibt sich bei einem Toleranzfaktor von 0,18 ein Bereich von 28,7 bis 41,3 (21525 - 30975)
-29238 / 750 = 39
-23378 / 750 = 31
Nachtrag:
Die Toleranz bei clock ist 0,3 wird aber bei MU-Nachrichten per default nicht ausgewertet
ZitatProbiere mal mit dieser Definition:
Hab ich jetzt erst einmal nicht gemacht, weil Ralf schrieb
ZitatDie clockabs von 550 ist nur ein ungefährer Wert, zum Mittelwert bilden und berechnen benötigen wir noch von beiden Fernbedienungen mehr Nachrichten
Fb1 als unknown(P114) empfangene messages
Code4
MU;P0=-3052;P1=-748;P2=1274;P3=-1475;P4=596;P5=-23374;P7=392;CP=4;R=57;D=12123412123434123412125434121234121234341234121254341212341212343412341212570212341212343412341212543412123412123434123412125434121234121234341234121257021234121234341234121254341212341212343412341212543;p;i;
MU;P0=-17140;P1=599;P2=-1420;P3=-743;P4=1278;P5=-24361;P6=380;P7=-2984;CP=1;R=41;D=012134342134342121342134345674342134342121342134345121343421343421213421343451213434213434212134213434512134342134342121342134345121343421343421213421343451213434213434212134213434512134342134342121342134345;e;i;
Code6
MU;P0=-132;P1=-1467;P2=580;P3=-728;P4=1278;P5=-23308;P7=200;CP=2;R=71;D=1234341234341212341212345212343412343412123412123452170;e;
MU;P0=-796;P1=1244;P2=-1456;P3=597;P4=-23348;P5=406;P6=-2992;CP=3;R=57;D=010123010123230123230145610123010123230123230143230101230101232301232301456101230101232301232301456101230101232301232301452501012301012323012323014325010125;e;
Code14
MU;P0=4448;P1=-1397;P2=609;P3=-746;P4=1273;P5=-23345;CP=2;R=40;D=01234341234341212121212345212343412343412121212123452123434123434121212121234521234341234341212121212345212343412343412121212123452123434123434121212121234521234341234341212121212345212343412343412121212123452123434123434121212121234521234341234341212121;O;
MU;P0=152;P1=-1457;P2=596;P3=-748;P4=1267;P5=-23314;P6=428;P7=-2910;CP=2;R=54;D=1234341234341212121212345674341234341212121212345212343412343412121212123452123434123434121212121234521234341234341212121212345274341234341212121212345210;p;i;Fb2 - mit meiner obigen Definition P120
Code4
MU;P0=324;P1=-10340;P2=644;P3=-956;P4=1720;P5=-1776;P6=854;P7=-30448;CP=6;R=75;D=3456343456563456343476563434563434565634563434701236;e;
MU;P0=32001;P1=-1859;P2=816;P3=-907;P4=1720;P5=-30458;P6=152;CP=2;R=76;D=0123434123434121234123434521234341234341212341234345216;e;
Code6
MU;P0=4032;P1=-1777;P2=911;P3=-907;P4=1712;P5=-30486;P6=380;P7=-4108;CP=2;R=61;D=0123434123434121234121234521234341234341212341212345212343412343412123412123452123434123434121234121234521234341234341212341212345672;e;
MU;P0=-7250;P1=112;P2=838;P3=-904;P4=1722;P5=-1780;P6=-30473;P7=356;CP=2;R=45;D=234345234345252345252346252343452343452523452523462523434523434525234525234625234345234345252345252346704523434525234525234625234345234345252345252346701;p;i;
Code14
MU;P0=841;P1=-932;P2=1694;P3=-1774;P4=-30439;P5=356;P6=-2500;P7=576;CP=0;R=63;D=01230121230303030301240301212301212303030303012456712123012123030303030124;p;i;
MU;P0=30880;P1=-1794;P2=821;P3=-920;P4=1704;P5=-30427;P6=404;P7=-4204;CP=2;R=41;D=0123434123434121212121234521234341234341212121212345212343412343412121212123452123434123434121212121234567;e;Bwm-Zone1 - mit meiner obigen Definition P120
Code0
MU;P0=-1786;P1=773;P2=-913;P3=1645;P4=-29760;P5=348;P6=-6720;P7=92;CP=3;R=46;D=010123232323410123230123230101232323234567;p;
MU;P0=-272;P1=-1778;P2=777;P3=-913;P4=1633;P5=-28540;P7=160;CP=2;R=46;D=12343412343412123434343452123434123434121234343434521234341234341212343434345212343412343412123434343452123434123434121234343434570;p;ZitatEs gibt auch die Möglichkeit für die FB1 und FB2 verschiedene Protocol IDs zu nehmen.
Das wäre "too much". Es wird kaum jemand meine Anlage haben und die 1. Fb scheint irgendeine "Macke" zu haben. Da kann ich eher den Widerstand verändern, so dass die clock wieder dem Standard entspricht.
Zitat
name => 'BEG',
comment => 'remote control for B.E.G. Alarmanlage, clock 800',
Ist ja nicht nur remote. Und willst Du es wirklich nach meiner(gefühlt 25 Jahre) alten Alarmanlage benennen ? Ich fände HT21E besser, weil der HT21E-Standard benutzt wird. Daher habe ich auch in SD_UT erst einmal die settings/events Code0-Code15 genannt.(Bringts Dir was, wenn ich meine per copy&paste-Anpassungen des SD_UT poste ?)
3 Dinge sind für mich noch offen:
1. Könnte man das Protokoll(Chip MT12E) nicht universeller machen, indem man ein Attribut(z.B. UTclock) für die unterschiedlichen base clocks wg. unterschiedlichem Oszillator-Widerstand für den Empfang nutzt ?
2. Als Universalprotokoll dann auch nicht die konkrete Bedeutung/der Funkmessages für settings/events, sondern Code0-Code15. Lässt sich dann ja am device per stateFormat u. WebCmd auf das tatsächliche Modell anpassen.
3. Mich irritieren die unterschiedlichen Längen meiner Beispiel-Nachrichten und die unterschiedliche Repetition. Liegt das am nicht berücksichtigten SyncPuls nach der Präambel ? Oder ist das aus Eurer Sicht völlig ausreichend, um das Protokoll sauber zu erkennen bzw. gegen andere abzugrenzen ?
Mittlerweile glaube ich, dass es keine periodische "battery OK" message des Bwm gibt, sondern "battery low" messages(Code: 1100b bzw. hex C) versendet werden. Und Code 5(0101b) aktiviert nicht den "Durchgangsmodus", sondern zeigt die Auslösung von Zone 3 (drahtgebunden angeschlossene Melder) an. Zone3 ist immer aktiv.
Ich hab die entsprechenden Stellen im 1. Post korrigiert.
Zitatevtl reicht auch ein protokoll, kannst Du bitte mal schauen wie stark bei der Fb1 und Fb2 die clock (P2) und Präambel (P5) schwanken.
Wie gesagt, die FB1 hat wohl ne "Macke" und das löse ich(wenn überhaupt genutzt) per Hardware-Anpassung.
Grüße Markus
Edit: In so ca. 5% der Fälle wird beim BWM noch immer P114 erkannt. Das habe ich gerade im Protokoll gesehen, da ich heute Nachmittag ziemlich viel vor dem Bwm herumgehampelt bin.
Und ab und zu aber regelmäßig erhalte ich P99. Keine Ahnung was das sein soll. Wegen RSSI bei ca. 50 schließe ich ein device aus der Nachbarschaft aus. Und ich hab abgesehen von Funksteckdosen: IT-Bewegungsmelder/-Tür-Fenster, Oregon-Sensoren, K101-Rauchmelder,Revolts und nun der wieder in Betrieb genommenen Alt-Alarmanlage keine 433MHz funkenden Gerätschaften. Habt Ihr ne Idee was das sein könnte ?
730000 2022-05-27_08:59:01 unknown_please_select_model unknownMSG: 011100110000000000000000 (protocol: 99)
036B94 2022-05-27_10:38:17 unknown_please_select_model unknownMSG: 000000110110101110010100 (protocol: 99)
900043 2022-05-27_11:13:53 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
036BA4 2022-05-27_13:46:14 unknown_please_select_model unknownMSG: 000000110110101110100100 (protocol: 99)
900043 2022-05-27_14:29:54 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
900043 2022-05-27_14:35:18 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
900043 2022-05-27_14:36:41 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
900043 2022-05-27_14:57:32 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
036BA0 2022-05-27_16:00:14 unknown_please_select_model unknownMSG: 000000110110101110100000 (protocol: 99)
036BA4 2022-05-27_17:04:27 unknown_please_select_model unknownMSG: 000000110110101110100100 (protocol: 99)
90004B 2022-05-27_17:21:43 unknown_please_select_model unknownMSG: 100100000000000001001011 (protocol: 99)
900043 2022-05-27_17:21:51 unknown_please_select_model unknownMSG: 100100000000000001000011 (protocol: 99)
Weil ich das vorher schon über ein paar Tage beobachtet(aber nicht aufgezeichnet) hatte, kann ich sagen, dass der Code stabil bei diesen Werten ist. Die Revolts ?
Dann brauchen wir ja die FB1 bei der Protokolldefinition nicht zu berücksichtigen
Hier sind die clock und start von der Fb2 und Bwm-Zone1
854 30448
911 30486
838 30473
841 30439
773 29760
777 28540
Eine clockabs 710 und start -40 müsste ungefähr passen:
710 x 0,3 = 213 ergibt 497 bis 923
40 * 0,18 = 7,2 ergibt 32,8 bis 47,2 (23288 - 33512)
Nur, um es zu verstehen: Warum gehst Du so weit runter mit clockabs ? Ich hätte jetzt eher (min + max)/2 genommen. Und wie kommst Du auf die Faktoren 0,18/03 für die Toleranzen ?
ZitatWarum gehst Du so weit runter mit clockabs ? Ich hätte jetzt eher (min + max)/2 genommen
Da gibts mehrere Möglichkeiten, ich habe als obere Grenze der clock ca 920 festgelegt, dadurch kommt man mit der clock weiter runter.
Dadurch passt das Protokoll evtl auch für Fernbedienungen mit einer clock kleiner 600.
ZitatUnd wie kommst Du auf die Faktoren 0,18/03 für die Toleranzen ?
Dies steht in der sub SIGNALduino_PatternExists
my $tol=abs(abs($searchpattern)>3 ? abs($searchpattern)>16 ? $searchpattern*0.18 : $searchpattern*0.3 : 1);
Ich verstehe es auch nicht.
Wenn tatsächlich HT12E verbaut sind, müsste man start auf jeden Fall mit -35 oder lt. neuerem Datenblatt mit -36 definieren.
Da bin ich bei Dir. Ich schrieb ja schon
ZitatDie Präambel beträgt 12bits low(36 Pulse), ein Syncpuls high und dann die 12bits. Das Ganze mindestens 4 Mal.
ZitatWenn tatsächlich HT12E verbaut sind
Vom Chip abgelesen. ;)
Aus Ralfs Tabelle ergibt sich
35,65339578
33,46432492
36,36396181
36,19381688
38,49935317
36,73101673
ZitatDadurch passt das Protokoll evtl auch für Fernbedienungen mit einer clock kleiner 600
Kann ich nachvollziehen. Der 3MOhm bei mir ist ja sehr hoch gegriffen und kleiner gewählt sinkt die Pulslänge. Mit dem 1MOhm(Referenzwert im Datenblatt) sind wir schon auf 330 runter. Man erkennt im Datenblatt auch, dass bei größeren Widerständen durch deren Toleranz die Frequenz ordentlich abweichen kann. Da wäre ein 470kOhm und clock ca. 150 eigentlich die bessere Wahl gewesen.
Stimmt, ich hatte einen Denkfehler, der Bereich wird begrenzt durch Präambel
36 * 0,18 = 6,48 ergibt 29,52 bis 42,48
- bei einer clock = 800 sind das 23616 - 33984
23616 / 36 = 656 min clock
33984 / 36 = 944 max clock
- bei einer clock = 780 sind das 23025 - 33134
23025 / 36 = 639
33134 / 36 = 920
für den clock Bereich kleiner ca 640 ist dann eine weitere Protokolldefinition erforderlich
Ich habs in der aktuellen dev Version "v3.4.13-dev_ralf_29.05."
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
so eingebaut:
"121" => ## universal HT21E, e.g. B.E.G. Alarmanlage
# https://forum.fhem.de/index.php/topic,127798.0.html
# P121#93E MU;P0=30880;P1=-1794;P2=821;P3=-920;P4=1704;P5=-30427;P6=404;P7=-4204;CP=2;R=41;D=0123434123434121212121234521234341234341212121212345212343412343412121212123452123434123434121212121234567;e;
{
name => 'HT21E (BEG)',
comment => 'universal, e.g. for B.E.G. Alarmanlage',
id => '121',Zitat
2. Als Universalprotokoll dann auch nicht die konkrete Bedeutung/der Funkmessages für settings/events, sondern Code0-Code15. Lässt sich dann ja am device per stateFormat u. WebCmd auf das tatsächliche Modell anpassen.
Eine möglichkeit wäre evtl ein Attribut ähnlich wie das "userV1setCodes" beim IT-Modul
Wie soll es hier weitergehen?
Die ID 121 ist mittlerweile mit "Remote control Busch-Transcontrol HF - Handsender 6861" belegt.
Es müsste dafür eine freie ID reserviert werden.
Zitat2. Als Universalprotokoll dann auch nicht die konkrete Bedeutung/der Funkmessages für settings/events, sondern Code0-Code15. Lässt sich dann ja am device per stateFormat u. WebCmd auf das tatsächliche Modell anpassen.
Dies ist beim SD_UT Modul bis jetzt nicht vorgesehen, für die B.E.G. Alarmanlage gibt es dann im SD_UT Modul ein neues Model.
Gruß Ralf
ZitatWie soll es hier weitergehen?
GuteFrage, die ich mir auch schon die ganze Zeit stellte. ???
Ich bin halt nach wie vor der Überzeugung, dass es niemand geben wird, der genau meine Situation hat. Ich wiederum kann damit leben, es für mich individuell zu implementieren.
Ich sehe nach wie vor mehr den Sinn einer "offiziellen Implementierung" in der Implementierung des Standards des HT21E. Welche Hardware(z.B. meine Alarmanlage) auch immer diesen Standard einsetzt, wird dann wenigstens im Signalduino erkannt. Und wie Du bereits im vorherigen Post schriebst, könnte man die Bedeutung der einzelnen Befehle über ein Attribut zuordnen.
Was meint denn der Modulautor ?
Grüße Markus
Ich bin zwar nicht der Maintainer des Modules, aber habe auch schon einige Fernbedienungen hinzugefügt.
Ich kann mir nicht so richtig vorstellen, wie du ein universelles und komfortabel zu handhabendes Modul gestalten willst.
Nehmen wir als Extrembeispiel Protokoll 83:
'RH787T' => { '110111' => '1_fan_minimum_speed',
'110101' => '2_fan_low_speed',
'101111' => '3_fan_medium_low_speed',
'100111' => '4_fan_medium_speed',
'011101' => '5_fan_medium_high_speed',
'011111' => '6_fan_high_speed',
'111011' => 'fan_direction',
'111101' => 'fan_off',
'111110' => 'light_on_off',
'101101' => 'set',
hex_length => [3],
Protocol => 'P83',
Typ => 'remote'
},
Das würde dem User dann 10 Devices hinzufügen, die er irgendwie in einer Fernbedienung zusammenfassen müsste.
Nein, natürlich nur ein device.
Zitat8-Adressbits über Dip-Schalter einstellbar, wobei on=o u. off=1(entspricht beim HT12E elektrisch: GND=0 u. open=1)
die 4 Datenbits
0000b Bwm Bewegung(Dip: on-off-off=Zone 1)
1000b Bwm Bewegung(Dip: off-off-off=Zone 2)
1100b Bwm Batterie lowOK(eigentlich müsste der Bwm regelmäßig etwas übertragen, sonst geht an der Station die Warn-LED für "Batterie prüfen" an
0100b Fb Alarm Zone1/Zone2 off
0110b Fb Alarm Zone1/Zone2 on
1110b Fb Sofortalarm
Wie Ralf schon schrieb ähnlich dem IT-Modul und den userV1setcodes. Die 8 Adressbits(Standard HT21) für das device und die Datenbits sind die individuellen Codes je device.
Zitat von: KölnSolar am 15 Juli 2022, 01:15:34
Nein, natürlich nur ein device.Wie Ralf schon schrieb ähnlich dem IT-Modul und den userV1setcodes. Die 8 Adressbits(Standard HT21) für das device und die Datenbits sind die individuellen Codes je device.
Das ist das, was ich mit dem Beispiel andeuten wollte: Es gibt keinen Standard mit 8 Adressbits. Das ist zwar die übliche Beschaltung, aber was hindert einen Hersteller daran, wie im Beispiel 6 Bit für die Tastencodes zu verwenden? Diese Fernbedienung hat z.B. nur 4 Adressschalter. Ich habe hier eine in Verwendung mit 10 Adressschaltern.
Das nächste Problem dürfte die automatische Erkennung des Taktes sein. Bei diesen Nachrichten:
# 1_fan_minimum_speed MU;P0=388;P1=-112;P2=267;P3=-378;P5=585;P6=-693;P7=-11234;D=0123035353535356262623562626272353535353562626235626262723535353535626262356262627235353535356262623562626272353535353562626235626262723535353535626262356262627235353535356262623562626272353535353562626235626262723535353535626262356262627235353535356262;CP=2;R=43;O;
# 2_fan_low_speed MU;P0=-176;P1=262;P2=-11240;P3=112;P5=-367;P6=591;P7=-695;D=0123215656565656717171567156712156565656567171715671567121565656565671717156715671215656565656717171567156712156565656567171715671567121565656565671717156715671215656565656717171567156712156565656567171715671567121565656565671717171717171215656565656717;CP=1;R=19;O;
# 3_fan_medium_low_speed MU;P0=564;P1=-392;P2=-713;P3=245;P4=-11247;D=0101010101023231023232323431010101010232310232323234310101010102323102323232343101010101023231023232323431010101010232310232323234310101010102323102323232343101010101023231023232323431010101010232310232323234310101010102323102323232343101010101023231023;CP=3;R=40;O;
verweist CP auf eine Zeit von etwa 250 µS - richtig wären ca. 335.
Ich versteh Dich. Aber die Vorgabe von Holtek meine ich mit Standard.
Deine Beispiele halten sich auch nicht an die Funkprotokollstandards(zum Glück), so dass sie per Funkprotokoll abgrenzbar sind.
Bei >= 8 Adressbits würde es funktionieren. Nur bei < 8 gäbe es ein Problem. Aber das Problem haben wir doch immer, wenn das Funkprotokoll gleich ist. Wenn nun meine BEG als Protokoll implementiert wird, hat jemand mit < 8 auch mehrere devices. Das lässt sich dann nur über model bei identischem Funkprotokoll lösen.
Ich würde dann ja eher zu einem neuen Modul tendieren.
Am besten wäre es, wenn du direkt auf Github https://github.com/RFD-FHEM/RFFHEM (https://github.com/RFD-FHEM/RFFHEM) ein neues Issue eröffnest oder gleich einen Pull request.