Protokoll für Westinghouse Deckenventilator Delancey

[zwiebelxxl]

Hallo Leut,

ich habe einen Deckenventilator von Westinhouse. Der Ventilator hat einen DC Motor mit einer Funk Fernbedienung die 1-6 Stufen, Aus, Lampe an/aus und richtungswechsel hat. Die Fernbedienung hat einen "SET" Knopf und 4 dip Schalter. Dazwischen steht noch ein Runder Aufkleber auf dem steht 434. Die dip Schaler sind ab Werk auf "ON" gestellt und so habe ich die auch gelassen.

Im Anhang ist ein log mit Verbose 4.

fan.txt

Ich habe einen arduino nano ( V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 ) für die Aufzeichnung verwendet. An dem hängt ein cc1101 Transmiter.

Es wäre schön wenn mir jemand sagen kann was zu tun ist damit ich die einzelnen Stufen schalten kann.

vielen dank! Zwiebelxxl

[HomeAutoUser]

Hallo @zwiebelxxl,

Es wäre schön wenn mir jemand sagen kann was zu tun ist damit ich die einzelnen Stufen schalten kann.

Bis dahin muss man erstmal eine klare bzw. eindeutige Erkennung des Signales gewährleisten. Ich habe mir deine Signal mal angesehen und diese "springen" manchmal von der Erkennung. Bitte wiederhole mal den Versuch und stelle erneut Rohdaten zur Verfügung.

Deine Signael werden zum großen Teil als U57 erkannt was aussagt, das das Signal noch unbekannt "aufgefangen" wurde. Laut derzeitiger Beschreibung sollte das eine Türklingel

m-e doorbell

sein.

Es kann sein, das dein Signal ähnlich ist aber dazu benötigt man viel mehr Daten. Wenn du den Test mit den Aufzeichnungen machst, kannst du sicherstellen so wenig wie möglich zu sendende Geräte aktiv zu haben ;-)

Entnehme ich deinen Aussagen richtig, das du die Master Version nutzt und nicht die DEV (Entwickler) Version?

MfG

[zwiebelxxl]

Hallo HomeAutoUser,

ich versuch heute abend mehr Daten zu liefern.

Viele Grüße Zwiebelxxl

[zwiebelxxl]

Hallo HomeAutoUser,

ich habe diese SIGNALDUINO Version: V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28

So wie im WIKI beschrieben hab ich geflashed: set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC7/SIGNALDuino_nanocc1101.hex Sollte ich eine andere Version nehmen?

In FHEM hab ich mir eine funktion geschrieben die vorher ein log erzeugt mit der Taste die ich gedrückt habe. FHEM steht auf verbose 3 und der SIGNALDURINO auf verbose 5. z.B. 2018.08.22 17:41:39 1: -->> TASTE 1

Hier das fhem log: fhem.log

vielen dank schon mal! Gruß Zwiebelxxl

[sidey79]

Du hast alles richtig gemacht.

Für mich sieht das nach einem neuen Protokoll aus :)

[zwiebelxxl]

was bedeutet das jetzt? Wie kann ich helfen?

[HomeAutoUser]

@zwiebelxxl, es muss ein neues Protokoll erstellt werden mit den Zeiten. Solltest du nicht wissen wie dies funktioniert, Gedult zeigen ;-) weil die Daten hast du ja geliefert. Sobald es eingebunden ist werden wir dich in Kenntnis setzen oder du siehst es bei einem Update im ChanceLog.

Ich werde gern mal drüber schauen nachdem meine Liste abgearbeitet wurde.

[zwiebelxxl]

perfect! Dann zeige ich mal Gedult! :) Dickes Lob an euch!

[HomeAutoUser]

Hallo @zwiebelxxl

ich habe mich heute mal deinem Protokoll gewidmet. Bisher habe ich von 12 Bits - 6 Stück identifizieren können für die Tasten. Da die weiteren 6 noch unklar sind, so folgende Fragen / Dinge:

1) kann man an dem Ventilator noch Einstellungen vornehmen wie eine Adresse? 2) muss man die FB an den Ventilator lernen? 3) es wäre schön, wenn du mal die Batterien aus der FB herausnimmst und nach dem erneuten bestücken die Testreihe mit allen Tasten nochmal machst.

Sämtliche Erkenntnisse sammel ich bisher zusammen um dann bestmöglich so viel wie möglich umsetzen zu können. (testen kannst natürlich nur du ;-) am besten)

Kannst du mal bitte bei deinem Empfänger nachsehen "get Empfängername protocolIDs" ob du da ein Protokoll 30 (30 MU SD_UT unitec47031 # developModule. ) drin stehen hast? Wenn ja, kann man eventuell prüfen ob deine Tastendrücke in FHEM ankommen, da ein ähnliches Protokoll auf deine MU Nachrichten reagiert, was aber von einer Türklingel stammt.

Grüße

[zwiebelxxl]

Hallo zusammen,

wow bin überascht so schnell!

1. ja es gibt 4 dip Schalter (stehen alle auf on) und ein set Knopf.
2. ja - nachdem der Ventilator stromlos war muß der set knopf innerhalb von 60s gedrückt werden. (Ich hoffe damit ist das kein hoffnungsloser Fall...)
3. hab die Batterie raus und die Testreihe wiederholt.( mit dem attribut m30 und ohne)

Ja ich habe die protocolID 30.

fhem.log_mit_m30.log fhem.log_ohne_m30.log

vielen Dank für deine Zeit dich mit meinem Ventilator zu beschäftigen!

Gruß Zwiebelxxl

[HomeAutoUser]

Vielen Dank @zwiebelxxl! Es deckt sich mit meinen Erkenntnissen welche ich bereits habe.

1) würde es viel Arbeit machen die DIL Schalter zu verstellen? Ich vermute dahinter steckt ein Hauscode wenn ich das richtig erlesen habe im Internet. Wenn ja, würde ich diesen gern verifizieren.

@sidey79 hast du eine Idee wie wir vielleicht am besten verfahren, da wir hier wieder an den Punkt kommen wo 2 Protokolle welche wir definiert haben zugleich zutreffen?

2018.08.23 21:59:02 4: sduino_dummy: decoded matched MU Protocol id 30 dmsg u30#F81 length 12 RSSI = -51

2018.08.23 21:59:02 4: sduino_dummy: decoded matched MU Protocol id 81 dmsg F81 length 12 RSSI = -51

Als Protokoll 30 können wir es nicht durchgehen lassen weil die Türklingel anders ausgewertet wird. Dummerweise besitzen auch beide die selben Bits. Somit entfällt, das man ein Modul für beide Protokolle umschreiben könnte.

Entweder man lässt ein Protokoll auf m bzw. beide und der User muss dies manuell einstellen welches er besitzt um eine richtige Modulweiterleitung zu erzielen.

[sidey79]

Protokoll 30 Passt. Dass dieses "Unitec" Protokoll nichts geheimes oder eigen entwickeltes ist, überrascht mich jetzt nicht.

Richtig ist, dass wir vermutlich nicht anhand der Bits erkennen können, welches Gerät nun physisch das Protokoll 30 verwendet. Da bleibt nur, ein Attribut model im SD_UT Modul, mit dem der Anwender die Funktionen auswählen kann.

[HomeAutoUser]

Richtig ist, dass wir vermutlich nicht anhand der Bits erkennen können, welches Gerät nun physisch das Protokoll 30 verwendet. Da bleibt nur, ein Attribut model im SD_UT Modul, mit dem der Anwender die Funktionen auswählen kann.

Da würde ich vorschlagen, nur eine Protokolldefinition um nicht doppelt diese einzutragen und dann den Weg einzuschlagen das SD_UT Modul mit einem Attribut zu versehen.

[zwiebelxxl]

würde es viel Arbeit machen die DIL Schalter zu verstellen? Ich vermute dahinter steckt ein Hauscode wenn ich das richtig erlesen habe im Internet. Wenn ja, würde ich diesen gern verifizieren.

Nein kein Problem - soll ich dann nochmal eine Testreihe machen? Will soll ich den housecode stellen - alle auf OFF ?

[sidey79]

Am besten ist es, immer nur genau eine Änderung zu machen. Also nur einen dipschaltet und dann testen. Danach den Nächsten Dipschalter.

[HomeAutoUser]

Hallo @zwiebelxxl,

soll ich dann nochmal eine Testreihe machen? Will soll ich den housecode stellen - alle auf OFF ?

Am besten Du stellst die 4 dip Schalter welche derzeit alle auf on stehen (deiner Aussage von oben zu entnehmen) auf

• OFF / OFF / OFF / OFF ---> Testreihe
• ON / OFF / OFF / OFF ---> Testreihe
• OFF / ON / OFF / OFF ---> Testreihe
• OFF / OFF / ON / OFF ---> Testreihe
• OFF / OFF / OFF / ON ---> Testreihe

Bei der Testreihe würde es vorerst ausreichen wenn du eine Taste (immer die selbe) drückst ABER besser und SICHERER wäre es, wenn du die sämtlichen Tasten drückst.

Wichtig ist, das du bestmöglich den selbigen Ablauf immer durchführst oder dir es genau notierst. Desto mehr Kombinationen du aufnimmst, so bessere und sichere Erkenntnisse können wir daraus schließen.

An der Erarbeitung des Moduls bin ich soeben. Es fehlen "nur" die Werte mit denen ich dann das ganze mal durchtesten kann.

Zum Verständnis, wir müssen bestmöglich versuchen sämtliche Einstellungen welche veränderbar sind durchzuspielen.

MfG

[zwiebelxxl]

Ok - ich komm leider erst morgen abend dazu die Testreihen zu machen.

[zwiebelxxl]

Hallo,

ich hab jetzt mal eine Testreihe gemacht. ON / ON / ON / OFF --> Testreihe

fhem.log.mit_m30_onononoff.log

Es reicht nicht die dip Schalter einfach umzustellen der Ventilator muß stromlos gemacht werden und innerhalb von 60s muß eine SET Taste gedrückt werden. Dann macht der Ventilator einen 5 min. selbst test. Am Ventilator selber kann man nichts einstellen.

Bitte gebt bescheid wenn weitere Testreihen sinnvoll sind.

vielen Dank für eure Bemühungen. Zwiebelxxl

[HomeAutoUser]

Hallo, danke für die weitere Testreihe. Mache am besten noch weitere. On / on / off / on bis hin zu off / on / on / on. Ich sehe mir deine Daten an. Je mehr Kombinationen wir besitzen um so besser. Mfg

[zwiebelxxl]

ok,

fhem.log.mit_m30_ononoffon.log fhem.log.mit_m30_onoffonon.log

morgen kommt dann off / on / on / on :)

[zwiebelxxl]

wie versprochen...

off / on / on / on fhem.log.mit_m30_offononon.log

[HomeAutoUser]

Vielen Dank @zwiebelxxl ,

versuche mal bitte nur die Set-Taste zu drücken mehrfach und dabei Signale aufzuzeichnen. Zum jetzigen Stand gibt es 2 von 12 Bits welche noch unklar sind. Besitzt die FB noch andere Zustände vielleicht? Batterieanzeige?

EDIT: Bitte wiederhole von deinem Versuch bei OFF / ON / ON /ON die Taste 3. Du hast dich dort bestimmt verdrückt ;-) und die Taste 2 stattdessen gerückt.

[zwiebelxxl]

Hallo,

sorry das ich mich erst jetzt melde. Hier eine Testreihe mit SET und nochmal die Taste 3.

fhem.log.mit_m30_offononon_SET.log

Ich hab noch ein fhem update vorher gemacht.

EDIT: es gibt keine weitere Tasten. Aber noch eine LED sobald eine Taste gedrückt wird.

[HomeAutoUser]

Guten Abend, Danke für dein Log. Ich schaue es mir Anfang nächster Woche an weil ich auswärts bin.

Gibt es manchmal eine Meldung von dem Ventilator wenn die Batterie alle geht von der Fernbedienung? (Nur eine Idee)

Mfg

[HomeAutoUser]

Hallo @zwiebelxxl, das Ganze schaut schonmal sehr gut aus. Bitte wiederhole das mit der Set-Taste mal noch bei anderen Hauscodes. (Nur Set-Taste ist notwendig aber bitte den HC notieren).

Gern kannst du auch schonmal das Modul hinein kopieren auf eigene Gefahr und du solltest ein Device angelegt bekommen. (Senden geht definitiv noch nicht, nur der EMPFANG)

14_SD_UT.txt

Zusätzlich musst du natürlich das Modul bei den development mit

m30

eintragen. Dann könntest du schon etwas sehen ;-)

[zwiebelxxl]

Hallo HomeAutoUser,

ich habe das modul eingespielt und auch ein neues Device "SD_UT_unknown" bekommen!

Dann habe ich FHEM nochmal neu gestartet und eine neue testreihe mit SET Taste gemacht. Haus Code war OFF / OFF / ON /ON

fhem.log.mit_m30_offoffonon_SET.log

M30 hab ich als attribut - ist das was du meint mit schon etwas sehen?

Wie gesagt bin begeistert über den Vortschritt!

[elektron-bbs]

Du musst bei dem neuen Device "SD_UT_unknown" noch das Attribut "model" auf deinen Ventilator setzen. Der Hinweis steht auch im Log, kann man aber leicht übersehen: SD_UT Please define your model of Device SD_UT_unknown in Attributes!

[zwiebelxxl]

Hallo

ja nach dem setzten von dem Attribut hab ich auch die Befehle von der Fernbedienung bekommen! -> Sehr schön!

Nachdem ich das Device umbenannt habe (SD_UT_Delancey_3 -> FAN ) ist das im log gekommen, und die Befehle wurden nicht mehr erkannt... 2018.09.06 14:04:56 1: ERROR: >SD_UT_Delancey_3< returned by the SD_UT ParseFn is invalid, notify the module maintainer Was ist noch notwendig um selber Befehle vom FHEM aus zu senden? Kann ich etwas dazu beitragen?

[HomeAutoUser]

Hallo @zwiebelxxl, das ist doch schonmal eine schöne Nachricht. Bitte versuche mal diese Version des Modules. 14_SD_UT.txt Wir haben etwas umgestellt an dem Modul und da kann es sein, das der Fehler behoben wurde bereits zumal wir beim testen mit unserem Stand des Modules deinen Fehler nicht nachstellen konnten.

@sidey79, ich würde dir gern einen PR für das Modul erstellen, das die User sich die Version ggf. aus dem Dev laden können. Dazu wäre es schön wenn wir diese Änderung mit einbeziehen könnten. https://github.com/RFD-FHEM/RFFHEM/pull/259 Da wir in dem Modul auch die Protokollnummern überprüfen wäre es sehr hilfreich wenn wir Protokoll-ID´s übernehmen sobald diese bekannt werden.

Nachdem ich einen PR von dem Modul durchführte, würde ich gern den Faden hier https://github.com/RFD-FHEM/RFFHEM/issues/250 "schließen lassen" oder wenn möglich umbenennen durch Dich in SD_UT_Modul oder ähnliches weil es nach jetzigen Stand ein Universalmodul wird wo mehrere Geräte einlaufen. Wenn du dem so zustimmst, und @elektron-bbs keine "Anregung" oder Zusätze hat dann kommt der PR geflogen ;-)

[sidey79]

Ich mag pull requests :) und das meine ich ernst.

Das mit dem verbundenen PR geht klar. Kannst Du noch ergänzen, welche Geräte das je Protokoll sind? Mir fehlt da aktuell der Zusammenhang :)

[elektron-bbs]

@HomeAutoUser - Das dispatchen mit groß oder klein geschriebenen "u" hat sich jetzt nach einem Blick in den Quelltext geklärt:

Fuer $dmsg die mit U anfangen ist kein Dispatch notwendig, da es dafuer kein Modul gibt klein u wird dagegen dispatcht

@sidey79 - Ich würde eigentlich von den "u.." als Preambel bei Protokollen mit Modul gerne wegkommen. Welchen Buchstaben sollen wir verwenden? "Pxx" wäre brauchbar, da wir dann auch gleich die Protokollnummer dabei haben.

@zwiebelxxl - Das Senden sollte mit der aktuellen Version jetzt eigentlich auch funktionieren.

[zwiebelxxl]

@elektron-bbs - leider reagiert der Ventilator nicht.

hier das log: fhem.log

[HomeAutoUser]

@zwiebelxxl , das konnte nicht gehen weil wir da einen Parameter übersehen haben beim ändern.

14_SD_UT.txt

Bitte hiermit testen. Das Beste ist, du tauschst das Modul aus, löscht das alte Device in FHEM, startest neu und probierst das ganze sofort mit neu anlegen durch. Somit sehen wir auch wenn andere Fehler noch drin wären.

EDIT: es kann noch nicht klappen. schaue gerade woran es liegt. Mein kleiner Fehler hat es noch nicht behoben obwohl es auch nen Fehler war ;-)

EDIT2: sehe woran es im CODE liegt!

[zwiebelxxl]

@HomeAutoUser - ich bin so wie du beschrieben hast vorgegangen. nach Tastendruck ist das device unknown entstanden, dann nach dem setzen von dem Attribut wurde das Modul umbenannt zu "Westinghouse_Delancey_3". Empfang von Befehlen geht.

Aber leider geht das senden noch nicht. fhem.log

...ach sehe gerade dein EDIT2 :)

[HomeAutoUser]

@zwiebelxxl du warst zu flink und hattest meinen editierten Post nicht wahrgenommen :-) Ja in dem Log sieht man den Fehler der drin war aber nun bitte erneut testen. Habe mir das ganze hier mal simuliert und nun kommen die 12 bits heraus.

14_SD_UT.txt

2018.09.07 18:37:04 3: nano_433Mhz: Westinghouse_Delancey_7 sendMsg=P30#101110010000#R5

[HomeAutoUser]

@sidey79 in dem Zusammenhang sehe ich noch Dinge welche ich optimieren würde im Code. Dazu ist aber der https://github.com/RFD-FHEM/RFFHEM/pull/259 PR notwendig sonst fehlt eine Definition des Protokolles ;-)

Hinzu auch die Frage noch von @elektron-bbs

@sidey79 - Ich würde eigentlich von den "u.." als Preambel bei Protokollen mit Modul gerne wegkommen. Welchen Buchstaben sollen wir verwenden? "Pxx" wäre brauchbar, da wir dann auch gleich die Protokollnummer dabei haben. Wenn wir darauf eine Antwort erhalten können wir den Code noch vor dem PR "frisch halten" :-)

[zwiebelxxl]

@HomeAutoUser - leider reagiert der Ventilator nicht...

hier das log seit dem fhem neustart: fhem.log

[HomeAutoUser]

@zwiebelxxl Ich habe mehrere Vermutungen bzw. Ungereihmtheiten gesehen. Bitte Verrate mir mal deinen HausCode wie du Ihn eingestellt hast in der bzw. den Fernbedienungen. Bei manchen Nachrichten fehlt ein Bit was nicht gesendet wird. Um das nachzustellen benötige ich mal den exakten HausCode bitte (DIL-Schalter).

[zwiebelxxl]

@HomeAutoUser - den hab ich nicht mehr geändert: OFF / OFF / ON / ON

Es kommt auch manchmal nur der 2. Tastendruck im FHEM an...vielleicht hängt das damit zusammen...

[HomeAutoUser]

@zwiebelxxl, im Code stimmt etwas noch nicht richtig. Gerade bei deinem HausCode fehlt ein Bit ;-)

Es kommt auch manchmal nur der 2. Tastendruck im FHEM an...vielleicht hängt das damit zusammen...

Das kann passieren wenn der SIGNALduino den Tastendruck nicht richtig interprätiert.

[HomeAutoUser]

@zwiebelxxl

bitte hiermit testen. Nun erhalte ich auch den Wert heraus welchen du definiert hast. 14_SD_UT.txt

[zwiebelxxl]

@HomeAutoUser - leider reagiert der Ventilator auch mit der neuen Version noch nicht.

hier das log nach FHEM restart: fhem.log

Bin mir nicht sicher was hilfreich... ich habe jetzt 2x die Licht an/aus taste gedrückt und dann versucht von FHEM aus etwas zu senden....

[sidey79]

@sidey79 - Ich würde eigentlich von den "u.." als Preambel bei Protokollen mit Modul gerne wegkommen. Welchen Buchstaben sollen wir verwenden? "Pxx" wäre brauchbar, da wir dann auch gleich die Protokollnummer dabei haben.

Mit u war als Abkürzung zu unknown gedacht, damit mal alle unknown einfach an das unknown modul senden kann :)

Aber sobald es nicht mehr unbekannt ist, sollte das U durch ein P ersetzt werden. Das kann leider Auswirkungen auf Anwender haben.

[HomeAutoUser]

@zwiebelxxl

bitte fahren mal folgenden Test. Drücke NUR eine TASTE einmal und danach den selben Befehl via FHEM !

Entweder dort sind noch differenzen oder das Device ist falsch (schließe ich aber mal aus - bitte kontrollieren) ODER es müssen mehr bzw weniger Wiederholungen werden.

[zwiebelxxl]

@HomeAutoUser

hier der Test: fhem.log

ich hab jetzt gerade gesehen das ich noch ein Device "unknown" habe in den raum SD_UT...aber ich vermute das bleibt übrig nach dem Attribut setzen des Models.

[HomeAutoUser]

@zwiebelxxl mit diesem o.g. Test haben wir erstmal sichergestellt, das das selbige rein und raus geht!

2018.09.07 21:16:07 4: SIGNALduino: decoded matched MU Protocol id 30 dmsg u30#990 length 12 RSSI = -62 2018.09.07 21:16:07 5: SIGNALduino Dispatch: u30#990, test ungleich: disabled 2018.09.07 21:16:07 5: SIGNALduino Dispatch: u30#990, -62 dB, dispatch 2018.09.07 21:16:07 5: SIGNALduino: dispatch u30#990 2018.09.07 21:16:07 3: SIGNALduino: SD_UT protocol 30, bitData 100110010000

2018.09.07 21:16:28 1: -->> TASTE 3 per FHEM 2018.09.07 21:16:34 3: SIGNALduino: Westinghouse_Delancey_3 set 3_fan_medium_low_speed 2018.09.07 21:16:34 5: SIGNALduino/write: adding to queue sendMsg P30#100110010000#R5 2018.09.07 21:16:34 5: SIGNALduino: sendmsg msg=P30#100110010000#R5

100110010000 100110010000

sind erstmal identisch. Hier hast du mal 3 Varianten wo die Wiederholung beim senden Variiert. Bitte mal testen. Es kann sein das dein Ventilator das ganze nicht versteht weil es zu kurz oder lang ist .... Leider können wir da nur von der Ferne "raten" oder du musst mal die FB hersenden ;-)

14_SD_UT_R3.txt 14_SD_UT_R7.txt 14_SD_UT-R9.txt

[zwiebelxxl]

Jetzt hat der Ventilator zum teil die Komandos verstanden. Die besten Ergebnisse waren mit "#R7". R3,R4,R5 und R6 waren zu wenig. Wobei der erste Empfang hat dann mit R6 geklappt. R8 und R9 brachte kein besseres Empfangs Ergebniss.

Aber zu 100 % wird kein Signal vom Ventilator interpretiert.

Ich hab gestern abend ausversehen "#R356" gesendet....dann ging gestern nichts mehr und heute hab ich dann den SIGNALduino stromlos gemacht.... :)

[Ralf9]

Aber sobald es nicht mehr unbekannt ist, sollte das U durch ein P ersetzt werden. Das kann leider Auswirkungen auf Anwender haben.

Das U79# (VTX-BELL_Funkklingel) sollte vorerst so bleiben, mindestens bis das 14_SD_UT fertig ist. Auf das U79# haben wahrscheinlich einige ein notify / DOIF getriggert das dann nicht mehr funktionieren wird.

Bei den ID 30 + 81 ist es sinnvoll diese auf P30 + P81 zu ändern. Es sollte dann ein "developId => 'm'," zugefügt werden.

in die matchListSIGNALduino müsste dann "17:SD_UT" => '^P(30|81)#.*',

[HomeAutoUser]

@zwiebelxxl Danke für deine Informationen. Ich werde es nun anpassen! :-)

@Ralf9

Bei den ID 30 + 81 ist es sinnvoll diese auf P30 + P81 zu ändern. Es sollte dann ein "developId => 'm'," zugefügt werden.

So war es auch unsere Vermutung bzw. so haben wir es im Kopf gehabt.

Das U79# (VTX-BELL_Funkklingel) sollte vorerst so bleiben, mindestens bis das 14_SD_UT fertig ist. Auf das U79# haben wahrscheinlich einige ein notify / DOIF getriggert das dann nicht mehr funktionieren wird.

Die U79 wäre in dem Modul SD_UT mit drin schon. Wir haben es soweit umgesetzt, das jeder sich selber anklingeln kann mit dem Set Befehl :-D Spricht was dagegen, wenn wir das U79 abändern in P79 und dort das "developId => 'm'," hinzufügen wenn wir den PR hochladen. Die User welche es als U79 auswerten würden dann den Hinweis im Log erhalten "developId => 'm'," zu aktivieren. ODER wie denkt IHR?

in die matchListSIGNALduino müsste dann "17:SD_UT" => '^P(30|81)#.*',

Das würde ich so für den PR nutzen wollen.

[Ralf9]

Spricht was dagegen, wenn wir das U79 abändern in P79 und dort das "developId => 'm'," hinzufügen wenn wir den PR hochladen. Die User welche es als U79 auswerten würden dann den Hinweis im Log

Ein Hinweis im log ist zu wenig, es sollte rechtzeitig vorher ein deutlicher (rot) Hinweis im forum und evtl auch im issue gemacht werden.

[HomeAutoUser]

@Ralf9 Der Eintrag im Forum sollte kein Problem sein im SIGNALduino Faden. Welchen issue meinst du? Hier wäre es ebenso kein Problem.