SIGNALDuino Empfänger Firm- und Hardware

[andies]

Danke - beides schon gemacht. Derzeit ist R=243 (!!!) und das mitschneiden hatte ich schon, dieser pilight-link oben: https://forum.pilight.org/showthread.php?tid=2771

[Harst]

Beim Mitschneiden ging es mir nicht ums Timing, sondern um die Pegel.

[andies]

Das stimmt, das ist eine gute Idee. Wie kann ich denn Pegel messen, welches Gerät müsste ich dazu nehmen?

[Harst]

Stichwort SDR, z.B. ein logilink vg0002a

Da gibt es Software aus dem Amateurradio-Bereich zu.

[x86]

Mir ist folgender Fehler im "offiziellen" SIGNALduino-Modul aufgefallen:

Bei Verwendung von Intertechno Funksteckdosen mit dem offiziellen "IT"-Modul greift das dortige Attribut "IOfrequency" leider nicht.

Das IT-Modul gibt die Frequenz korrekt über den #F-Parameter im String an das SIGNALduino-Modul weiter, das SIGNALduino-Modul hängt aber die Werte leider nur hinten an die RawMsg an, ohne das nötige "F=".

Fix: in der 00_SIGNALduino.pm muss die Zeile 838 (bezieht sich auf die neueste Version 3.5.5 und auch die aktuell in FHEM verteilte 3.5.4) wie folgt angepasst werden:

Code Auswählen Erweitern

        elsif ($c eq 'F' && InternalVal($hash->{NAME},'cc1101_available',0)) { $frequency = "F=".substr($s,1).";";  }

Das "F=" und das ";" am Ende fehlen nämlich im Original-Code.
Vielleicht ist das dem Entwickler nicht aufgefallen, weil ein paar Zeilen später die Frequenz aus der Protokolliste ausgelesen wird und da wird es korrekt verkettet.

Der Fehler tritt NUR auf, wenn die Frequenz explizit im Befehl übergeben wird (bei mir ist das bei ein paar Funksteckdosen nötig, deren Empfängerkreise scheinbar minimal gegenüber der 433,92 MHz "verstimmt" sind, bei denen muss ich dann die experimentell rausgefundene Empfangsfrequenz angeben).

Wäre schön, wenn diese Änderung ins Modul einfließen könnte, momentan muss ich sie nach jedem Update manuell vornehmen.

Liebe Grüße!

[Sidey]

Danke für die Info, ich schau mir das an

[Sidey]

Wäre schön, wenn diese Änderung ins Modul einfließen könnte, momentan muss ich sie nach jedem Update manuell vornehmen.

Hi x86,

Kannst Du bitte ein Update auf folgende angepasste Version machen:

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_fixFrequency/controls_signalduino.txt

Ich habe es leicht abweichend, als wie von dir vorgeschlagenen, umgesetzt bin aber guter Dinge einen weiteren Fehler behoben zu haben und keinen eingebaut zu haben.

Grüße Sidey

[x86]

Hi Sidey,

Ich habe es leicht abweichend, als wie von dir vorgeschlagenen, umgesetzt bin aber guter Dinge einen weiteren Fehler behoben zu haben und keinen eingebaut zu haben.

habe es soeben getestet und es funktioniert bestens! Danke! Dann bleibe ich erstmal bei deinem neuen Branch (aktuell hab ichs mit exclude_from_update festgenagelt) und hoffe, dass diese Version demnächst auch ins offizielle FHEM-Distribution einfließt (da ich versuche, mit möglichst vielen Modulen in der "stabilen FHEM Standard-Distribution" zu bleiben und wenige zusätzliche Paketquellen anzugeben), aber selbst wenn nicht, läuft es mit dieser Version erstmal 100% zufriedenstellend, und zuvor hatte ich mit meinem "quick-and-dirty"-Fix ja auch eine vom Standard abweichende Datei, die ich "festnageln" musste.

Also: top, super, danke!!! 

Liebe Grüße
x86

[Rainer1]

Hallo, was ist denn z.Z. die Empfehlung zur Hardware ? Nano mit CUL1101 ?
Gibt es eine HARDWARESeite mit aktuellen Infos ?

[Sidey]

Hallo, was ist denn z.Z. die Empfehlung zur Hardware ? Nano mit CUL1101 ?
Gibt es eine HARDWARESeite mit aktuellen Infos ?

Ich würde einen ESP32 und Cc1101 empfehlen

[Ralf9]

Eine Empfehlung ist schwierig, dies hängt von einigen Faktoren ab.
Die Art der Anbindung, USB oder über lan oder WLAN.
Bei WLAN ist der esp32 zu empfehlen.

Möchstet du eine fertige Hardware kaufen oder selber bauen?
Bei fertiger hardware ist mir momentan nur der nanocul bekannt.

Gruss Ralf

[beaune]

Gibt es eigentlich eine Möglichkeit, zur besseren Gebietsabdeckung zwei Signalduinos zu installieren, die dieselben Nachrichten senden? Mir geht es konkret um IT-Steckdosen, die zwar sehr zuverlässig einschalten, aber (manchmal) nicht abschalten. Beim CUL gibt es glaube ich für so etwas das Attribut sendpool. Gibt's hier was ähnliches? Oder kann man sich über das dummy-Attribut einen Vervielfacher basteln? Hat das schon mal jemand gelöst?

[andies]

Ja,interessant, das ich exakt dasselbe Problem hatte. Bei mir ist es blöderweise eine reicht laute Klingel, die nach zwei Sekunden ausgehen sollte. Klappte manchmal nicht und jetzt kannst du dir vorstellen, welchen Ärger es zu Hause deswegen gab.

Ich habe Empfänger getauscht, X verschiedene notifys, mehrfach abschalten gesendet und ähnliche Dinge in FHEM ausprobiert, die die Ausschaltung veranlassen sollten. An der Empfangslage kann es nicht gelegen haben, ich vermute eher eine Abnutzung bei den Geräten (Elkos?). Am Ende habe ich gewechselt, von IT auf Sonoff bzw Shelly, das ist berechenbarer. In einem Sonoff zB (geflasht mit Tasmota) kann man so genannte rules einbauen, die nach jedem Anschalten automatisch zwei Sekunden später ,,off" senden.

[beaune]

Ich glaube nicht, dass es etwas mit Alterung zu tun hat. Die Geräte sind noch nicht alt, und mit der mitgelieferten Fernbedienung schalten die Steckdosen auch. Da passt wahrscheinlich die Frequenz nicht richtig. Hab aber jetzt auch gelernt, dass man bei IT-Steckdosen über den Parameter ITclock nachjustieren kann, indem man sich den richtigen Wert aus der RAW-Message abschaut. Momentan funktioniert das, mal sehen wie lange/zuverlässig das ist. Vielleicht ist das also gar kein Thema für die Empfänger Firm- und Hardware, sondern ein reines Konfigurationsthema.

Jetzt wollte ich das für ne andere Steckdose auch gleich so machen, das ist aber eine vom Typ SD_GT. Da gibt es dieses Attribut aber gar nicht. Die von der Fernbedienung aufgezeichnete RAW-Message sieht so aus:

Code Auswählen Erweitern

MU;P0=460;P1=-1068;P2=967;P3=-563;P4=3013;P5=-7203;CP=0;R=26;D=012301230123232323012323230101012323232323010145230123012301232323230123232301010123232323230101452301230123012323232301232323010101232323232301014523012301230123232323012323230101012323232323010;e;i;@Ralf9: kann man für SD_GT vielleicht etwas ähnliches wie ITclock bei IT einbauen?

[andies]

Also mit ITClock habe ich auch (vergeblich) herumgespielt, das hat auch nichts genutzt. Es ergibt auch keinen Sinn, dass die Rate beim einschalten stimmt und beim ausschalten nicht.

Egal: probiere alles aus, mir machte das ja auch Spaß. Mir ist nur irgendwann de Geduldsfaden gerissen...