Signalduino gelegentlich closed

Ralf9 · 28 Oktober 2018, 11:18:23

Du kannst auch die V 3.3.2.1-rc4 nehmen, diese hat damit keine Probleme. Ich habe einen sduino mit dem ich dieses Problem nachvollziehen und dafür einen workaround einbauen konnte.

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_3321rc4.hex

https://forum.fhem.de/index.php/topic,82379.msg840645.html#msg840645

Gruß Ralf

fervor · 29 Oktober 2018, 18:28:39

Hallo Ralf,

danke für die Info, habe jetzt mal die 3.3.2.1-rc4 drauf gespielt. Mal schauen, was sich die nächsten Tage so zeigt.

Verständnisfrage:
Für mich sieht es so aus, als ob der Signalduino so betrieben werden soll, dass sowohl für Empfang, als auch für den Sender grundsätzlich die gleiche Frequenz benutzt wird. Nun sieht es so aus, dass bei mir Somfy idealerweise 433,42MHz benötigt, die Steckdosen, Fenstersensoren und Wetterstation eher 433,92 MHz. Wie geht man da jetzt vor? Solange probieren, bis man eine Frequenz gefunden hat die alle beteiligten irgendwie gerecht wird?
Wäre auch ein Szenario sinnvoll einsetzbar, in dem man die Frequenzen dynamisch wechselt? Vielleicht eine Grundfrequenz / Konfiguration für IT Devices bei 433,92MHz und wenn etwas an Somfy gesendet werden soll, eine entsprechend dafür geeignete Konfiguration verwenden, um danach wieder auf die Grundkonfiguration zu wechseln?

Ich möchte das hier jetzt auch nicht unnötig aufblasen - traue mich trotzdem mal zu fragen

schon mal besten Dank für die Unterstützung

VG fervor

Sidey · 29 Oktober 2018, 19:33:54

Dein cc1101 ist auf eine Frequenz optimiert.
In der Regel 433,92 MHz oder 868 MHz.

Den cc1101 stellst Du auf die Frequenz ein, auf der Du etwas empfangen möchtest. Bei dir ist das 433,92 MHz.
Sollte jemand die Rolläden Manuell steuern empfängst Du auch das, da die Somfy Sender breit streuen.

Wenn Du dann deinen Rolladen über den SIGNALduino ein Kommando sendest, wird die Frequenz umgestellt.
Die Frequenz sollte dann wieder zurück gestellt werden auf 433.92.
Genau da ist der Fehler. Das zurück stellen funktioniert nicht.
Dann sendest und empfängt der cc1101 auf 433,42 MHz was dazu führt dass die IT Steckdosen nicht geschaltet werden.

Grüße Sidey

fervor · 29 Oktober 2018, 19:48:02

Danke, jetzt hab ich es verstanden

Wünsche noch einen schönen Abend

Ralf9 · 29 Oktober 2018, 19:49:01

Hallo fervor,

Zum Senden und Emfangen muß nicht die gleiche Frequenz benutzt werden. Ideal wäre es, wenn Du eine Frequenz zwischen 433,42MHz und 433,92MHz findest, bei der sowohl Somfy als auch die Steckdosen, Fenstersensoren und Wetterstation empfangen wird. Du kannst dazu die Bandbreite auf 650 kHz erhöhen.
Mir ist bis jetzt noch niemand bekannt dem das gelungen ist.
Vor dem Senden von Somfy wird die Frequenz auf 433,42MHz gestellt und hinterher auf die eingestellte Empfangsfrequenz wieder zurückgestellt.
Beim IT-Modul gibt es ein Attribut ITfrequency, da kannst Du die Sendefrequenz für die Steckdosen angeben, falls Du eine andere Empfangsfrequenz als 433,92MHz verwenden willst.

Gruß Ralf

fervor · 31 Oktober 2018, 20:32:27

Hallo Ralf,

die Version 3.3.2.1-rc4 hats scheinbar gebracht. Die geschilderten Probleme sind damit Geschichte. Super

Die Abstimmung der Frequenz samt Bandbreite ist noch etwas tricky. Es funktioniert zwar alles zusammen, jedoch teilweise unzuverlässig. Mal schauen, vielleicht finde ich ja noch einen besseren Aufstellort.

Besten Dank an alle beteiligten

Harst · 10 April 2020, 10:57:47

Hallo,

bei mir tauscht dieses Problem jetzt auch auf. Es ist ein nano, der bisher problemlos lief. Der 2. Nano macht das öfter auch, ist dann auch teilweise nur durch ausstecken zu retten, aber da könnte es die Hardware sein. Er hat das schon länger.

Horst

PS: woher die beiden unterschiedlichen version-readings kommen kann ich nicht sagen

Ralf9 · 10 April 2020, 11:15:31

Zitatbei mir tauscht dieses Problem jetzt auch auf. Es ist ein nano, der bisher problemlos lief. Der 2. Nano macht das öfter auch, ist dann auch teilweise nur durch ausstecken zu retten, aber da könnte es die Hardware sein. Er hat das schon länger.

Gibt es dieses Problem auch noch mit meiner 3.3.2.1-xx ?

Gruß Ralf

Harst · 10 April 2020, 11:37:07

Zitat von: Ralf9 am 10 April 2020, 11:15:31
Gibt es dieses Problem auch noch mit meiner 3.3.2.1-xx ?

Gruß Ralf

Eigentlich ist auf meinem nano doch die 3.4.0, soll ich das trotzdem testen?

Horst

Ralf9 · 10 April 2020, 20:14:09

Bitte mach mal ca 10-20 mal ein "get ccconf", wenn ab und zu falsche Werte ausgegeben werden, dann siehe hier:
https://forum.fhem.de/index.php/topic,58396.msg1040703.html#msg1040703

Gruß Ralf

Harst · 10 April 2020, 20:32:17

Hallo,

das Ding hat keinen CC1101, es ist ein Standard-RX/TX drin

Horst

Ralf9 · 10 April 2020, 20:41:19

Zitatdas Ding hat keinen CC1101, es ist ein Standard-RX/TX drin

außer eine unsaubere Stromversorgung oder ein zu langes USB Kabel fällt mir dazu nichts ein.

Gruß Ralf

Harst · 30 April 2020, 22:34:15

Zitat von: Harst am 10 April 2020, 10:57:47
Hallo,

bei mir tauscht dieses Problem jetzt auch auf. Es ist ein nano, der bisher problemlos lief. Der 2. Nano macht das öfter auch, ist dann auch teilweise nur durch ausstecken zu retten, aber da könnte es die Hardware sein. Er hat das schon länger.

Horst

PS: woher die beiden unterschiedlichen version-readings kommen kann ich nicht sagen

Ich habe das Problem isoliert. Der Pi 3 b+ war in einem Gehäuse und würde wohl zu heiß. Ohne Gehäuse ist das nicht mehr aufgetreten. Die Wärmebildkamera hat den USB-Controller als heißesten Chip gezeigt.

Horst

Harst · 09 Juli 2020, 00:37:07

Zitat von: Harst am 30 April 2020, 22:34:15
Ich habe das Problem isoliert. Der Pi 3 b+ war in einem Gehäuse und würde wohl zu heiß. Ohne Gehäuse ist das nicht mehr aufgetreten. Die Wärmebildkamera hat den USB-Controller als heißesten Chip gezeigt.

Horst

Nachtrag: Durch Kühlkörper am Pi und offenes Gehäuse war es besser, aber je nach Tagesform gab es Mal nach einigen Stunden, Mal nach wenigen Tagen Abstürze. Meist reichte es, dem abgestürzten Nano per FHEM ein Reset zu schicken. Ich habe viel versucht:
Versorgungsspannung des Pi hochgesetzt auf 5,3V
Anderer USB Hub
Einige der Nano direkt am Pi
Zusatzkondensator über die Versorgungsspannung

Jetzt hat der USB Hub eine separate Leitung direkt vom Netzteil und läuft seit Tagen ohne Probleme. Ich glaube, wenn mehrere der Nano gleichzeitig senden oder wenn in der Luft viel los ist und alle Nano arbeiten kann der Pi die 5 Nano nicht stabil betreiben.

Horst