SIGNALDuino Empfänger Firm- und Hardware

[fhem@supergut]

Die SIGNALduino_promini328.hex hat aber den Nachteil, daß sie nicht für den cc1101 ist.
Die Firmwaren für den cc1101 haben CC1101 im Namen.

Hier ist eine Testversion für den 8 MHz promini
https://forum.fhem.de/index.php/topic,58396.msg615195.html#msg615195

Gruß Ralf

Moin, tolle Arbeit. Gibt es hier etwas neues in Sachen FW für Promini und CC1101? Danke im voraus.

[Ralf9]

Da hat sich in der zwischenzeit sehr viel getan, es gibt mit dem RXB6 oder cc1101 Versionen für den Promini, nano, radino, CulV3, Maplemini, für LAN und WLAN (ESP)
hier sind meine Versionen:
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Es gibt auch offizielle Versionen von Sidey, siehe im Signalduino Wiki

Gruß Ralf

[Ralf9]

Hallo,

weiß jemand von Euch ob der Signalduino auch mit einem Level-Converter Modul problemlos funktioniert?
Z.B. mit "4 Kanal IIC I2C Logic Level-Converter Modul (bidirektionaler Levelshifter) 5 V zu 3,3 V"
Sind die Signallaufzeiten von diesen Level-Convertern vernachlässigbar?

Gruß Ralf

[elektron-bbs]

Das wird dir wahrscheinlich niemand 100%ig beantworten können, weil keiner weiß, welche Bauelemente der Chinese gerade verbaut hat.
Bei I2C mit 100 oder 400 kHz hat es bei mir mit den von Philips in der AN97055 empfohlenen BSN10 bisher immer zuverlässig funktioniert.

Mit welchem Takt läuft der SPI beim SIGNALduino eigentlich?

Hier https://electronics.stackexchange.com/questions/535445/does-level-shifter-have-a-maximum-speed berichtet jemand schon von Schwierigkeiten bei 800 kHz.
Hier ähnliche Erfahrungen:
https://electronics.stackexchange.com/questions/135767/high-frequency-logic-level-conversion
https://circuitdigest.com/tutorial/bi-directional-logic-level-controller-using-mosfet

[Ralf9]

Mit welchem Takt läuft der SPI beim SIGNALduino eigentlich?

Beim nano sinds 4 MHz (SPI speed = CLK/4)

[andies]

Ich habe eine Frage zu den Protokollen im Signalduino (ich vermute, dass das Came Protokoll nicht ganz korrekt ist und will deshalb ein wenig daran spielen). Ich sehe bisher vier Dateien, in denen Protokolle gespeichert sind:

/opt/fhem/FHEM/lib/signalduino_protocols.hash
/opt/fhem/FHEM/lib/signalduino_protocols.pm
/opt/fhem/FHEM/lib/DS_ProtocolsData.pm
/opt/fhem/FHEM/lib/SD_Protocols.pm

Muss man zum experimentieren die Protokolle in allen Dateien ändern? Nur in einer (welcher?)?

Und wenn wir schon mal soweit sind. Ich vermute die Ungenauigkeit hier (Zeile 2367 in *.pm)

Code Auswählen Erweitern

one => [-2,1],
zero => [-1,2],
start => [-44,1],
clockabs => 350,

und würde gern die Daten ändern. Mein Öffner hat stabil folgende Daten (mehrfach nachgemessen)

Code Auswählen Erweitern

2022-11-28_07:07:42 Came rawCode: MU-P0=-14716-P1=342-P2=-2224-P4=-685-P5=-328-P6=696-CP=1-R=243-D=121414141564141415641414156014141415641414156414141560141414156414141564141415601414141564141415641414156014141415641414156414141560-e-
und das hieße mE im Protokoll

Code Auswählen Erweitern

one => [-2,1],
zero => [-1,2],
start => [-43,1],
clockabs => 342,


[elektron-bbs]

Bei der aktuellen Version von Sidey (https://github.com/RFD-FHEM/RFFHEM)

Code Auswählen Erweitern

   versionProtocols 1.48
   versionmodul 3.5.4+20221126


ist dafür genau eine Datei zuständig:

Code Auswählen Erweitern

/opt/fhem/FHEM/lib/SD_ProtocolData.pm

Wie du in dieser Datei in den Kommentaren von Protokoll 86 siehst, wird die Definition für verschiedene Geräte verwendet. Die Timings passen dafür ziemlich genau.
Die geringe Abweichung davon bei deiner Fernbedienung dürfte innerhalb der Toleranzen liegen und eine Veränderung kaum zu signifikanten Verbesserungen führen.

[andies]

Wie du in dieser Datei in den Kommentaren von Protokoll 86 siehst, wird die Definition für verschiedene Geräte verwendet. Die Timings passen dafür ziemlich genau.
Die geringe Abweichung davon bei deiner Fernbedienung dürfte innerhalb der Toleranzen liegen und eine Veränderung kaum zu signifikanten Verbesserungen führen.

Ja, danke, das hatte ich gesehen und ich hatte vor Jahren ja mal selbst den Code "erforscht" (https://forum.pilight.org/showthread.php?tid=2771.) Also die Zahlen scheinen auf dem Papier sehr gut zu passen. Wenn ich aber meine Came-Fernbedienung durch SIGNALduino auslesen lasse, gibt es immer kleinere Veränderungen und manchmal öffnet das Tor erst beim dritten oder vierten Sendebefehl von FHEM, den ich aus der Fernbedienung ausgelesen habe - was bei der direkten Ansteuerung durch die Fernbedienung nie passiert, da reicht einmal drücken und das Tor reagiert sofort.

Ich habe beim SIGNALduino bereits die Antenne getauscht (inverted vee habe ich jetzt), alle anderen 433MHz-Geräte werden super empfangen. Das kann es also nicht sein. Daher dachte ich, vielleicht sind die Zahlen nicht ganz präzise? Ich habe halt keine Ideen mehr. Kurz gesagt: Wieso klappt die Fernbedienung perfekt, nicht aber der SIGNALduino?

[Ralf9]

Bei meiner Variante der 00_SIGNALDuino.pm ist es die signalduino_protocols.pm

Du kannst mal testweise die clockabs anpassen

[elektron-bbs]

Ach so, deshalb der Hickhack mit den verschiedenen Dateien
Die Rohdaten sehen auch eher nach deiner Version aus:

Code Auswählen Erweitern

2022-11-28_07:07:42 Came rawCode: MU-P0=-14716-P1=342-P2=-2224-P4=-685-P5=-328-P6=696-CP=1-R=243-D=121414141564141415641414156014141415641414156414141560141414156414141564141415601414141564141415641414156014141415641414156414141560-e-

[andies]

Du kannst mal testweise die clockabs anpassen

Danach die Datei neu einlesen? Aber wie?

Can't read ./FHEM/signalduino_protocols.pm

[Ralf9]

Danach die Datei neu einlesen? Aber wie?

mit einem fhem neustart

Mir ist es bis jetzt noch nicht gelungen ein reload durchzuführen

Code Auswählen Erweitern

reload lib/signalduino_protocols.pm
ergibt

Code Auswählen Erweitern

Can't read ./FHEM/libsignalduino_protocols.pm: No such file or directory

[Ralf9]

Du kannst auch mit "set sduino raw" senden, da kannst Du dann direkt die Pulszeiten anpassen

Code Auswählen Erweitern

set sduino raw SR;R=10;P0=-15400;P1=350;P2=-700;P3=-350;P4=700;D=01212121342121213421212134;

Den Sendebefehl findest Du im Log

Code Auswählen Erweitern

2022-11-30 07:45:50 SD_UT CAME_TOP_432EV_EE left_button
2022.11.30 07:45:50 4 : sduino SendrawFromQueue: msg=SR;R=10;P0=-15400;P1=350;P2=-700;P3=-350;P4=700;D=01212121342121213421212134;
2022.11.30 07:45:50 4 : sduino/msg READ: SR;R=10;P0=-15400;P1=350;P2=-700;P3=-350;P4=700;D=01212121342121213421212134;

[andies]

Ja, das ist ja das merkwürdige. Mein Sohn berichtet, dass er mit der Fernbedienung (ein billiger Chinaclone der originalen Came Bedienung) nie Probleme hat, das Tor zu öffnen. Also habe ich seine Sendebefehle gelogged und aufgeschrieben. Der sduino meldet immer den nahezu identischen Sendebefehle von ihm (die Zeiten sind eindeutig zuordenbar), also die raw-Zahlen sind wirklich fast identisch. Wenn ich dieselben Zahlen nun raw sende, dann öffnet sich manchmal erst beim zweiten Mal das Tor.

Ich habe ja die sduino-Antenne getauscht und verbessert, ich empfange jetzt die Temperaturen im Haus der Nachbarn
Aber an der Tor-Situation ändert sich nichts.

Mir ist aber gestern was eingefallen. Da ist eine 433-Antenne am Tor, die jetzt nicht so wirklich vertrauenswürdig aussieht. Aber der Clou war mW (ist ja alles verbaut, ich erinnere das nur dunkel) das Kabel von der Antenne zur Steuerung. Das war kein Antennenkabel, sondern irgend ein zweiadriges Kabel. Man schließt es laut Bedienungsleitung auch wirklich an eine einfache Schraubklemme an (!). Vielleicht liegt beim Empfang der Steuerung der Hund begraben?

[Harst]

Hallo,
ich hätte da 2 Ideen:

1. mit einem Empfänger mal mitchreiben, z.B. einem SDR
2. die Wiederholungen hochsetzen.

Horst