Support Novy kitchen hood #331

Garfonso · 2018-10-24T20:09:04Z

Specifications for new sensor / switch / or other device ...

manufacturer: Novy
model name: Pureline 6830
pictures of the device: Picture of the board in the RF remote:

Specifications Receiver

Microcontroller: radino CC1101 (this one http://wiki.in-circuit.de/index.php5?title=SIGNALduino_Stick_(deutsch) )
Versionmodul (Firmware): v3.3.3-dev_15.09.
Version (SIGNALduino): V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29

I have a Novy Pureline 6830 kitchen hood, which is controlled by a RF remote. I can not open the hood, but I opened the remote and took a picture. I got the radino CC1101 from in-circuit (I really can't solder anything). I hope that I can use it to emulate the remote using FHEM. I use FHEM for some time now, but still do not get most of the more complicated stuff. Also I am really a noob when it comes to RF.

In the file is what I got from the log for the five buttons of the remote (did a long press and multiple short ones. Also I have some weather stations in the neighbour hood which interfere).
NovyLog.txt

I tried to emulate some of the button presses using raw commands. But I really don't know how to do that. I tried to adapt the samples in the module to what I see in the log... but I did not understand most of what I did there... :-/
I hope someone can help me and maybe support for Novy in the module would be a nice idea? I'm willing to test. :-)

HomeAutoUser · 2018-10-24T20:28:16Z

Hello, please flash your radino to the new version.

set < name of sduino > flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC8/SIGNALDuino_radinocc11013.3.1-RC8.hex

HomeAutoUser · 2018-10-24T21:28:33Z

"87" => # Novy Pureline 6830 kitchen hood
	# https://github.com/RFD-FHEM/RFFHEM/issues/331
	# MC;LL=-752;LH=711;SL=-396;SH=366;D=DB6D5B54;C=370;L=30;R=28; light on/off button 
	# MC;LL=-751;LH=711;SL=-397;SH=363;D=DB6DA;C=370;L=19;R=30; + button
	# MC;LL=-755;LH=726;SL=-392;SH=353;D=DB6D6;C=370;L=19;R=29; - button
	# MC;LL=-767;LH=715;SL=-401;SH=345;D=DB6D5B54;C=371;L=30;R=36; power button
	# MC;LL=-757;LH=703;SL=-401;SH=362;D=FF6ADB6D;C=371;L=432;R=31; Novy button
{   
	name 		=> 'Novy',
	comment         => 'Pureline_6830',
	id 		=> '87',
	clockrange  	=> [360,390],
	format		=> 'manchester', 
	preamble 	=> 'u87#',
	#clientmodule	=> '',
	#modulematch => '',
	length_min 	=> '20',
	length_max 	=> '32',
	method          => \&SIGNALduino_MCRAW, # Call to process this message
},

2018.10.24 23:25:03 4: sduino_dummy/msg get raw: �MC;LL=-762;LH=712;SL=-403;SH=353;D=DB6D6;C=371;L=19;R=26;�
2018.10.24 23:25:03 4: sduino_dummy: Found manchester Protocol id 87 clock 371 RSSI -61 -> Novy
2018.10.24 23:25:03 4: SIGNALduino_unknown incomming msg: u87#DB6D6
2018.10.24 23:25:03 4: SIGNALduino_unknown rawData: DB6D6
2018.10.24 23:25:03 4: SIGNALduino_unknown Protocol: 87
2018.10.24 23:25:03 4: SIGNALduino_unknown converted to bits: 11011011011011010110

für das Protokoll müsste noch u57 angepasst werden auf

clockrange => [310,350], # min , max

sonst gelangen manche u87er in u57 rein. Mit allen Nachrichten von u57 habe ich getestet und mitbekommen das der Bereich auch sehr großzügig eingestellt war.

@Ralf9 @sidey79 bitte gegenprüfen und ob ihr auch meiner Meinung seit.

Garfonso · 2018-10-25T12:46:12Z

Hi,

danke für die ultra schnelle Reaktion. :-)
Ich habe die Firmware nun erfolgreich aktualisiert (irgendwie hab ich das am PI nicht hinbekommen bzw. es hat sich aufgehängt oder ich war zu ungeduldig. Am größeren Linux Rechner ging es dann von der Kommandozeile aus). Soll ich neue Logs aufnehmen oder sowas? Oder war das nur ein grundsätzlicher Hinweis?

VG, Garfonso

HomeAutoUser · 2018-10-25T14:46:38Z

Hallo,

Wenn du nun die Firmware aktualisiert hast, mache bitte mal nochLogs von den Tasten Power Button und Novy Button. Bei den beiden Tasten fällt auf, das der Code kürzer ist bzw. allgemein variiert Fleißarbeit wäre, das du das bitte bei allen Tasten nochmal machst.

Wenn wir sehen das jede Taste richtig und gleich erkannt wird von der Länge, so können wir dann uns an die andere Umsetzung machen.

- added ID 87 RFD-FHEM#331 - mod ID 57 clockrange

Garfonso · 2018-10-25T21:53:29Z

Hm... irgendwas ist kaputt gegangen...? Mit der aktualisierten Firmware erkennt er jetzt MU-Nachrichten und ich erkenne in den Data-Parts überhaupt keine Muster mehr... :-( Was kann da schief gelaufen sein?

Habe mal ein Log angehängt. Es gab da eine Reaktion auf die Tastendrücke... aber irgendwie erscheint mir das viel erratischer als alles, was ich gestern hatte.
NovyLog2.txt

Ralf9 · 2018-10-25T22:28:17Z

Das passt so. Das Protokoll ist fast gleich wie die ID 86 CAME Drehtor Antrieb
#151
mit dem Unterschied, daß manche Tasten ein Länge von 18 Bit haben.
Wenn Du hier die length_max auf 18 erhöhst, müsste es passen

	"86" => ## CAME Drehtor Antrieb
	{
		name		  => 'CAME Drehtor Antrieb',
		#comment	   => '',
		id            => '86',
		zero		  => [-2,1],
		one           => [-1,2],
		start         => [-44,1],
		clockabs      => 345,
		format        => 'twostate',
		preamble      => 'u86#',	  # prepend to converted message	
		#clientmodule  => 'SD_UT',    # not used now
		#modulematch   => '^u86#.{3}',# not used now
		length_min    => '12',
		length_max    => '18',
},

HomeAutoUser · 2018-10-26T07:36:54Z

Hallo,
da @Ralf9 dir schon sagte, was du machen kannst mit der Längenänderung um die Tasten zu erkennen, so wäre mein Frage, kannst du irgendwelche DIL-Schalter verstellen an der Remote? Ich suche bzw überlege nach einem Grund um diese von dem anderen Protokoll eindeutig zu unterscheiden.

Könntest du bitte nur die Novy Taste und die -Taste mal aufzeichnen.
Die beiden Tasten haben nur eine länge von 12 und die anderen von 18.

- added ID 87, not same ID 86 RFD-FHEM#331

Garfonso · 2018-10-26T23:40:29Z

Witzig, dass das so zeitgleich ist... ;-)

Also, ich hab es heute ausprobieren können. u86 (habe das von oben kopiert und eingefügt, allerdings "Novy" genannt). Wird zuverlässig erkannt, würde ich sagen. Ich habe nochmal ein Log aufgenommen. Beim "Novy"-Knopf gab es einmal ein mismatch als ich den länger festgehalten habe (habe bei allen Knöpfen zuerst kurz gedrückt, meistens mehrfach und dann mal >1 Sekunde festgehalten).
NovyLog3.txt

Zur Frage:
An der FB kann man gar nichts einstellen. Auf dem Bild sieht man eigentlich das ganze Board, da ist sonst nichts viel. Auf der Rückseite ist gar nichts.
Ich habe die Logs für +/-/Novy noch einmal etwas verlängert. Wenn ich das log richtig lese ist doch die + Taste auch "nur" AAA, oder nicht? (- ist AA9, Novy AAB)
Licht (AA8B8) und Power (AA8B0) sind die längeren. Was vielleicht auch einer gewissen inneren Logik folgt, da die Licht und Power Tasten jeweils etwas schalten (Licht geht unabhängig vom Gebläse an/aus).

Nachtrag:
Habe gerade erst gesehen/verstanden, dass ihr da schon eine neue signalduino_protocols.hash gebaut habe. Habe die runtergeladen und nochmal ein neues Log gemacht. Alle Tasten wurden richtig als u87 erkannt und nicht als u86. Das wolltet ihr bestimmt auch noch wissen, oder? Sieht jedenfalls gut aus, finde ich.
NovyLog4.log

HomeAutoUser · 2018-10-27T07:04:02Z

Vielen Dank für die Nachrichten. Ich werde sie mir ansehen und mal schauen ob man diese schon irgendwo weiterverarbeiten kann. LG

PS: man könnte vielleicht mal testen, mit dem RAW Befehl eine Dose zu schalten um ein wenig mit den Wiedderholungen testen. Diese Erkenntnis wäre noch notwenig wenn man es in ein Modul integriert.

HomeAutoUser · 2018-10-27T08:11:19Z

Ich habe mir mal die Mühe gemacht und nach dem Schaltkreis geschaut, dieser sollte es sein.

Da können wir ggf. die Definition verifizieren oder schauen was dieser wirklich herausgibt.

HomeAutoUser · 2018-10-27T08:57:27Z

@Ralf9
was denkst du bzw zu welcher Erkenntnis kommst du? Es ist eine sehr gleiche Definition wie schon imPlementiert, die 31 aber die Zeiten von der Remote schwanken bei dem Pulse davor. Laut Github wären hier die langen Pulse vor den Daten gleich. Wenn wir diese definieren, so käme dann eine 2. Def zum tragen weil bei dieser remote der Pulse nicht konstant ist.

elektron-bbs · 2018-10-27T09:47:36Z

Der Schaltkreis ist ein Microcontroller, da kann sonstwas programmiert sein. Das nutzt uns leider nichts.

Garfonso · 2018-10-31T11:23:53Z

Frage zu meinem Verständnis: Wäre es denn mit dem aktuellen Stand möglich
a) auf die Nachrichten zu reagieren (i.e. Message zu empfangen und in fhem zu verarbeiten). Nachdem, was ich gelesen habe, müsste das gehen, oder? Zur not mit DOIFs.
b) die Nachrichten zu verschicken (i.e. die Dunstabzugshaube fernzusteuern)? Habe etwas probiert, es aber nicht hinbekommen.

Kann ich sonst noch irgendwie helfen?

HomeAutoUser · 2018-10-31T12:00:11Z

Hallo,
ja man könnte mit DOIFs die Nachrichten verarbeiten in FHEM.

Ohne DOIFs geht es nur über ein Device welches von einem Modul verarbeitet wird. In der Realisierung sind wir dran.

Wenn du nicht warten kannst / möchtest, so musst du den Weg zur Verarbeitung über DOIFs gehen. Sobald das Modul dann fertig ist, erhältst du zusätzlich zur Steuerung ein Device und die DOIFs sind überflüssig.

Das senden bzw fernsteuern kann man auch jetzt schon realisieren. Das könntest du mal testen um eventuell die optimale repeat-Anzahl zu ermitteln.

Gern sind wir dir da behilflich und das Modul ist in Arbeit.

Garfonso · 2018-10-31T12:10:27Z

Hi,

nein, eilig habe ich es nicht. Dann warte ich auf das Modul. Yeah. :-)

Wie sende ich denn? Kann ich sendMsg nehmen? Da habe ich mal versucht z.B. mal "u87#AA9" einzutippen, hatte aber keinen Effekt (ins Log hab ich da leider nicht geschaut, muss ich zugeben).
Oder muss ich eine rawMsg versenden? Da habe ich bisher noch nicht richtig verstanden, wie man die zusammen baut.

+ added device QUIGG GT-7000 (ONLY RECEIVE) RFD-FHEM#145 RFD-FHEM#195 , Novy Pureline 6830 kitchen hood (ONLY RECEIVE) RFD-FHEM#331 , CAME Drehtor Antrieb (ONLY RECEIVE) RFD-FHEM#151 + added doc + module device models in hash

* 14_SD_UT.pm - more devices - added device QUIGG GT-7000 (ONLY RECEIVE) #145 #195 , Novy Pureline 6830 kitchen hood (ONLY RECEIVE) #331 , CAME Drehtor Antrieb (ONLY RECEIVE) #151 - added doc + doc CHANGED - module device models in hash - modified module - fix PEARL WARNING (reading model Unitec_47031) * Update FHEM/00_SIGNALduino.pm - update comments & regex * update signalduino_protocols.hash - user explanation added

HomeAutoUser · 2018-11-12T22:51:57Z

Guten Abend @Garfonso
deine Remote wurde in das Modul eingearbeitet.

Bitte mache eine update

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

starte FHEM neu und trage bei development im Empfänger m86 ein.
Ab sofort solltest du bei einem Tastendruck deiner remote ein Device angelegt bekommen.

Das senden via Set kannst du gern mal testen aber das ist noch nicht verbindlich, weil wir da die Wiederholungen ggf anpassen müssen.

Garfonso · 2018-11-13T22:31:02Z

Hi,
vielen Dank.
Habe es jetzt mal geschafft zu testen. Das Gerät wird angelegt (musste noch Novy als model auswählen). Es erkennt auch die Tastendrücke der Fernbedienung.
+/- Knopf senden geht auch recht zuverlässig. Licht und Power reagieren allerdings noch nicht. (Bei Novy weiß ich es nicht, da mir, wie gesagt, unklar ist, was der an der FB tun soll).

Zum Erkennen noch, ggf. hilft das ja auch beim Senden: Wenn ich den Knopf auf der Fernbedienung drücke steht bei +/-/Novy hinter dem Device der Knopfname.
Bei Power steht dort: 011101001100
Bei Licht steht dort: 011101000100

HomeAutoUser · 2018-11-13T22:44:33Z

Guten Abend, danke für deine erste Rückmeldung.
Es ist richtig, das du das Model noch auswählen musstest weil das Modul für mehrere Geräte ist.

Licht und Power reagieren allerdings noch nicht

Das war uns schon fast klar, weil für den Befehl licht gibt es ja angeblich 3 verschiedene Nachrichten.

P86#10101010011101000111#R9
für light_on/off_1

P86#1010101011010001#R9
für light_on/off_2

P86#1010101001110111#R9
für light_on/off_3

Teste mal bitte die 3 Befehle bei deinem Empfänger mit set sendMsg und der o.g. 3 Varianten.
Dort kannst du mal mit R "spielen" Bsp:

P86#10101010011101000111#R12

ob sich da was tut. Vielleicht kannst du mal vermerken welche Tests du vollzogen hast und wo sich etwas tat oder es auch nicht klappte. Den optimalen Wert für R müssen wir ggf. anpassen, das kannst du aber nur vor Ort bei dir testen.

Wir müssen herausbekommen welches für deine Ansteuerung benötigt wird.

HomeAutoUser · 2018-11-13T22:52:17Z

Ich muss nochmal nachfragen

Zum Erkennen noch, ggf. hilft das ja auch beim Senden: Wenn ich den Knopf auf der Fernbedienung drücke steht bei +/-/Novy hinter dem Device der Knopfname.
Bei Power steht dort: 011101001100
Bei Licht steht dort: 011101000100

Wo dahinter steht das? Auf der Fernbedienung ? In FHEM?

Garfonso · 2018-11-13T22:57:23Z

Hi,
sorry. Etwas unklar ausgedrückt. Also ich drücke auf der Fernbedienung, dann erscheint in FHEM der Knopf den ich gedrückt habe als "state" des Device.
Wie geschrieben: Bei den +/-/Novy Knöpfen steht da dann der Name von der zuletzt gedrückten Taste. Wenn ich auf der Fernbedienung Power oder Licht an/aus drücke, dann kommt dort dieser Bit-String und nicht der Name.
Ich hoffe das hilft jetzt weiter. Ich kann auch nochmal ein Log aufnehmen.

Dass mit den Repeats werde ich ebenfalls testen, aber vermutlich nicht mehr heute.

HomeAutoUser · 2018-11-13T23:03:14Z

Das was du bei State siehst bzw. die Aktion vom drücken haben wir ja definiert.
Weil es bei + und - eindeutige Nachrichtenpakete gab, so ist das eindeutig.

Weil LEIDER bei den anderen Knöpfen immer was verschieden ist, so haben wir erstmal alle eingebunden.

Ich habe soeben mal auf dei schnelle verglichen nochmal und teste mal bitte folgendes

Mich würde mal interessieren wenn du sendMsg manuell machst mit

+_button
P86#101010100101#R9
-_button
P86#101010100110#R9

ob das klappt. WENN JA, teste mal hier weiter bitte

power_button
P86#101010100111#R9
novy_button
P86#101010100100#R9
light_on/off
P86#101010101101#R9

Ich habe hier nichts anderes gemacht alle Zustände auf eine Länge zu "schneiden" und diese mit deinem Devicecode zusammengefügt.

Garfonso · 2018-11-13T23:13:26Z

Hi,
nein, damit gehen die +/- Knöpfe leider nicht.

Ausfürhlichere Tests von Licht/Power mit verschiedenen Repeats mache ich morgen oder Freitag.

Danke schonmal für alles, was jetzt schon da ist. :-)

HomeAutoUser · 2018-11-18T22:29:12Z

Gibt es neue Erkenntnisse bei den Tests?

Garfonso · 2018-11-21T06:58:00Z

Hi,
sorry mir kam ein Kindergeburtstag etwas in die queere... :-/

Heute morgen hab ich aber getestet. Irgendwie komme ich da nicht richtig weiter...
Ich habe ganz viel rumgetestet, aber es kam nie eine Reaktion. Dann kam ich mal auf die Idee die Knöpfe zu testen, die ja eigentlich gehen müssten und auch da kam nichts. Also irgendetwas mache ich falsch.

set Novy_Pureline_6830_55 +_button
und
set Novy_Pureline_6830_55 -_button
geht.

Aber
set radinoCC1101 sendMsg P86#0101#R9
und
set radinoCC1101 sendMsg P86#0110#R9
gehen nicht -> keine Reaktion.

Was mache ich falsch?

elektron-bbs · 2018-11-21T11:00:46Z

Im Sendebefehl fehlt die Adresse des Sensors. Du müsstest z.B. statt
set radinoCC1101 sendMsg P86#0101#R9
folgenden Befehl ausführen:
set radinoCC1101 sendMsg P86#010101010101#R9
Die ersten 8 Bit sind die Adresse und die letzten 4 Bit der Tastencode.

Wir haben aus den bisherigen Logs von dir folgende Tastencodes ermittelt:

011101000111 "light_on_off_1"
11010001 "light_on_off_2"
01110111 "light_on_off_3"
0101 "+_button"
0110 "-_button"
011101001111 "power_button"
0100 "novy_button"

Die Plus- und Minustaste scheint ja zu funktionieren.
Das die anderen Codes verschiedene Längen haben, scheint uns unwahrscheinlich. Für "light_on_off" waren sogar 3 verschiedene Codes in den Logs.
Du müsstest also bitte nochmal versuchen, für die restlichen 3 Tasten, die korrekten Codes zu ermitteln.

elektron-bbs · 2018-11-21T15:35:34Z

Probier mal bitte diese 14_SD_UT.pm:
14_SD_UT.zip

Garfonso · 2018-11-21T22:12:00Z

Hi,

cool. Mit der SD_UT im zip funktioniert es direkt. Also alle set-Einträge, die das Device anlegt machen jetzt, was sie sollen. 👍 Vielen Dank. Und sorry, wenn ich schwer von Begriff war. Mit Funk-Protokellen kenne ich mich echt nicht aus.

Achja, ich muss noch etwas beichten: Heute morgen habe ich herausgefunden, dass man den Code der Fernbedienung doch ändern kann. Es gibt 10 verschiedene Codes. Soll ich mir die Mühe machen und mit jedem ein Log aufnehmen? Oder was wird sich da vermutlich ändern?

HomeAutoUser · 2018-11-22T09:25:27Z

Hallo @Garfonso
das ist Schonmal gut das es alles macht wie es soll ;)

Bitte mache die Codeänderung und stelle sie hier online um die richtige Position der Ident (Code vom Device zu verifizieren)

Garfonso · 2018-11-23T11:43:03Z

Hi,

also habe die Codes jetzt durch probiert und er hat für jeden Code ein neues Gerät angelegt und da gehen dann auch die Knöpfe (also state wird geändert). Im Anhang noch ein Log von den jeweiligen Nachrichten, ich hoffe das reicht so.
In Klammern habe ich immer zu dem jeweiligen Code (1-10) den Code, den FHEM angibt. Macht es Sinn das ggf. anzugleichen?
novyCodeTest.log

Vielen Dank auf jeden Fall nochmal für die schnelle Umsetzung. 👍

Die Typnummer der Fernbedienung ist übrigens 840029 und wird anscheinend auch für andere Produkte des Herstellers genutzt.

elektron-bbs · 2018-11-23T16:30:04Z

Vielen Dank für die Mühe. Da sich immer nur das erste Nibble ändert, können wir die Definition erst mal so lassen.

Die Codes 1-10 würde ich lieber nicht verwenden, da wir nicht wissen, ob eine andere Fernbedienung die gleichen verwendet.

Die Bezeichnung des Modells der Fernbedienung in FHEM würde ich dann allerdings lieber nochmal ändern. "Novy_Pureline_6830" bezeichnet ja die Abzugshaube und nicht die Fernbedienung. Ich würde dann besser "Novy_ 840029" verwenden.

HomeAutoUser · 2018-11-29T18:12:52Z

@Garfonso
funktioniert dein Gerät immer noch einwandfrei auch nach der Anpassung der Bezeichnung?
Wenn ja können wir ja hier einen Haken dran machen und ggf. den Faden schließen oder gibt es noch Beanstandungen?

Garfonso · 2018-11-29T20:37:28Z

Habe gerade getestet und das Gerät neu angelegt. Geht auch nach dem umbenennen alles noch. Keine Beanstandungen.
Vielen Dank für die schnelle Umsetzung. Von meiner Seite aus kann das Ticket geschlossen werden. 👍

HomeAutoUser · 2018-11-29T20:44:04Z

Vielen Dank für deine Rückmeldung.
Ich werde das Ticket schließen und sobald sich ein Fehler oder was einschleicht bitte umgehend einfach ein neues eröffnen oder solltest du neue Geräte zur Implementierung haben :-)

pvh0 · 2023-09-01T07:34:01Z

Good day, I'm searching for help on using this Novy hood with an esp32 and ESPHome. Currently ESPHome does not seem to correctly transmit codes to my hood, see also esphome/issues#4311.
I saw that you guys got this working with RFFHEM, is there anyway you could help with using the solution and protocol information you are using in

RFFHEM/FHEM/lib/SD_ProtocolData.pm

Line 2379 in 491b4b3

# https://github.com/RFD-FHEM/RFFHEM/issues/331 @Garfonso

to get this also working in ESPHOME? In ESPHome we can configure transmission of 433 signals by either using build-in protocols (this one is recognized as protocol 6), or configuring your own values with the following options:

pulse_length: XXX sync: [X, XX] zero: [X, X] one: [X, X] inverted: false

e.g.:

pulse_length: 250 sync: [1, 10] zero: [1, 5] one: [1, 1] inverted: false

Any idea what we can use as proper values to get this working..?

sidey79 · 2023-09-01T08:14:19Z

@pvh0

I'am not familiar with esphome, but the novy device seems to use a clock of 350 uS.

The signal starts with a low signal of 44 * 350 uS followed by a high signal of 1*350 uS, zero is 1x350 low, followed by 2x350 high. One is 2x350 low with 1x350 high:

I am not aware of the esphome configuration and how low and high is represented but may this will bring you shorter to a solution:
pulse_length: 350 sync: [44, 1] zero: [1, 2] one: [2, 1] inverted: false

pvh0 · 2023-09-01T12:05:33Z

@sidey79 Thanks for your quick reply. Unfortunately no luck yet. Please find below a description on the possible values:

pulse_length (Required, int): The pulse length of the protocol - how many microseconds one pulse should last for.
sync (Optional): The number of high/low pulses for the sync header, defaults to [1, 31]
zero (Optional): The number of high/low pulses for a zero bit, defaults to [1, 3]
one (Optional): The number of high/low pulses for a one bit, defaults to [3, 1]
inverted (Optional, boolean): If this protocol is inverted. Defaults to false.

Edit:
Options are described here:
https://esphome.io/components/remote_transmitter.html#rc-switch-protocol

And esphome code here:
https://github.com/esphome/esphome/blob/dev/esphome/components/remote_base/rc_switch_protocol.cpp

sidey79 · 2023-09-01T22:09:19Z

I don't think that this is a "RCSwitch" compatible protocol

pvh0 · 2023-09-04T07:31:03Z

I don't think that this is a "RCSwitch" compatible protocol

Thanks, it gets detected as (probably wrong then) RCSwitch and CanalSatLD protocol. When listening to RCSwitch protocol I receive "010101010111010001" for the light which looks similar to what I found in this thread. But sending that signal to the hood does not do anything.

ESPHome can also send raw data, but I have no idea what to send then, any idea?
[sdsd](https://esphome.io/components/remote_transmitter.html#remote-transmitter-transmit-raw-action)

sidey79 · 2023-09-04T10:56:38Z

You can recalculate the values.
May you use a SIGNALDuino to capture the Signal or enable the raw values withhin ESPHome

bart1 · 2023-11-08T22:24:53Z

A quick comment for the people looking for information here. With this issue I got a ATAG hood working using esphome for more details see the esp home topic

pvh0 · 2023-11-09T07:23:11Z

A quick comment for the people looking for information here. With this issue I got a ATAG hood working using esphome for more details see the esp home topic

Good stuff, solution detaied here by Bart:
esphome/issues#4311

HomeAutoUser added a commit to HomeAutoUser/RFFHEM that referenced this issue Oct 25, 2018

signalduino_protocols.hash

0089fd7

- added ID 87 RFD-FHEM#331 - mod ID 57 clockrange

HomeAutoUser added a commit to HomeAutoUser/RFFHEM that referenced this issue Oct 26, 2018

signalduino_protocols.hash

fc3b931

- added ID 87, not same ID 86 RFD-FHEM#331

HomeAutoUser mentioned this issue Oct 26, 2018

signalduino_protocols.hash - ID 87 #333

Merged

2 tasks

HomeAutoUser mentioned this issue Oct 27, 2018

signalduino_protocols.hash - ID34 #334

Merged

2 tasks

HomeAutoUser added the modul needed or unknown no existing module or existing needs to be extended label Oct 29, 2018

HomeAutoUser added SD_UT and removed modul needed or unknown no existing module or existing needs to be extended labels Oct 31, 2018

HomeAutoUser mentioned this issue Nov 1, 2018

14_SD_UT.pm - more devices #340

Merged

2 tasks

HomeAutoUser added the userquery - answer open label Nov 18, 2018

HomeAutoUser closed this as completed Nov 29, 2018

HomeAutoUser removed the userquery - answer open label Nov 29, 2018

sidey79 mentioned this issue Jan 10, 2019

SD_RSL support set extensions #483

Closed

elektron-bbs mentioned this issue Feb 1, 2020

Support Novy Cloud 230 kitchen hood #792

Closed

Bjoern3003 mentioned this issue Mar 16, 2023

Trying to use rf_bridge to control my novy hood esphome/issues#4311

Open

Support Novy kitchen hood #331

Support Novy kitchen hood #331

Comments

Garfonso commented Oct 24, 2018

Specifications for new sensor / switch / or other device ...

Specifications Receiver

HomeAutoUser commented Oct 24, 2018

HomeAutoUser commented Oct 24, 2018 • edited Loading

Garfonso commented Oct 25, 2018 • edited Loading

HomeAutoUser commented Oct 25, 2018

Garfonso commented Oct 25, 2018

Ralf9 commented Oct 25, 2018 • edited Loading

HomeAutoUser commented Oct 26, 2018 • edited Loading

Garfonso commented Oct 26, 2018 • edited Loading

HomeAutoUser commented Oct 27, 2018 • edited Loading

HomeAutoUser commented Oct 27, 2018

HomeAutoUser commented Oct 27, 2018

elektron-bbs commented Oct 27, 2018

Garfonso commented Oct 31, 2018

HomeAutoUser commented Oct 31, 2018

Garfonso commented Oct 31, 2018

HomeAutoUser commented Nov 12, 2018

Garfonso commented Nov 13, 2018 • edited Loading

HomeAutoUser commented Nov 13, 2018

HomeAutoUser commented Nov 13, 2018

Garfonso commented Nov 13, 2018

HomeAutoUser commented Nov 13, 2018

Garfonso commented Nov 13, 2018

HomeAutoUser commented Nov 18, 2018

Garfonso commented Nov 21, 2018

elektron-bbs commented Nov 21, 2018

elektron-bbs commented Nov 21, 2018

Garfonso commented Nov 21, 2018 • edited Loading

HomeAutoUser commented Nov 22, 2018

Garfonso commented Nov 23, 2018

elektron-bbs commented Nov 23, 2018

HomeAutoUser commented Nov 29, 2018

Garfonso commented Nov 29, 2018

HomeAutoUser commented Nov 29, 2018

pvh0 commented Sep 1, 2023

sidey79 commented Sep 1, 2023

pvh0 commented Sep 1, 2023 • edited Loading

sidey79 commented Sep 1, 2023

pvh0 commented Sep 4, 2023 • edited Loading

sidey79 commented Sep 4, 2023

bart1 commented Nov 8, 2023

pvh0 commented Nov 9, 2023

HomeAutoUser commented Oct 24, 2018 •

edited

Loading

Garfonso commented Oct 25, 2018 •

edited

Loading

Ralf9 commented Oct 25, 2018 •

edited

Loading

HomeAutoUser commented Oct 26, 2018 •

edited

Loading

Garfonso commented Oct 26, 2018 •

edited

Loading

HomeAutoUser commented Oct 27, 2018 •

edited

Loading

Garfonso commented Nov 13, 2018 •

edited

Loading

Garfonso commented Nov 21, 2018 •

edited

Loading

pvh0 commented Sep 1, 2023 •

edited

Loading

pvh0 commented Sep 4, 2023 •

edited

Loading