Signalduino Entwicklung

[Sidey]

@Sidey
kannst Du zukünftig eine neue Firmware auch in CHANGED eintragen?
Kann es sein, daß mit der b18 auch die Erkennung von MS-Nachrichten besser geworden ist?

Hi Ralf,

ja sollte ich mal eintragen
Da ich in der b18 zwei generelle Fehler bzw. Anpassungen vorgenommen habe, wirkt sich das auch auf MS Nachrichten aus.
Die b18 läuft bei mir schon ganz gut, aber was Manchester angeht nicht perfekt.
Da passiert zumindest bei mir doch teilweise etwas seltsames.

Grüße Sidey

[Sidey]

Die Bit Pulsfolge (0/1) ist so aufgebaut wie die halbe Pulsfolge in pt2262 (IT) Protokoll. Daher kommen die "unknown tristate" bei meinen Sensoren. Nun das Problem, wie kann man diese Protokolle auseinanderhalten?

Damit meinst Du bestimmt, beim PT2262 werden vier Zustände für ein Bit übertragen und beim ev1527 nur zwei.
Ich hatte da mal eine Seite gefunden,  leider finde ich diese jetzt nicht mehr, da wurde ganz gut beschrieben welche Chips es alles gibt (es sind noch mehr als diese beiden) und wie man alle sehr gut auswerten kann.
Der SIGNALduino kümmert sich nur um das Signal selbst und demoduliert es. Für ihr existieren auch nur bits mit zwei Zuständen.
Was ich damit sagen will ist, dass der SIGNALduino egal ob EV1527 oder PT2262 sendet, immer zwei Pulsfolgen in ein Bit umwandelt.
Das klappt für alle chips gleichermaßen.

Die meisten Kombinationen passen nicht zum IT Protokoll und wären daher eindeutig zu erkennen, es gibt jedoch einige Kombinationen die sehen exact wie das IT Protokoll aus.
Ich kenne mich mit dem Fhem Konzept nicht aus, wer wie die empfangenen Daten auswertet. Sollte dieses im Signalduino.pm gemacht werden oder wo anders. Bitte um Vorschläge, damit ich mein Problem evtl. in ein anderen Thread posten kann.

Ja, also im SIGNALduino ist da nichts sinnvoll zu machen.
Das einfachste wäre, wenn man das IT Modul dafür erweitern würde. Es müsste eigentlich ausreichen, wenn man anstatt der Fehlermeldung unknown Tristate einfach annimmt, dass man die tatsächlichen Bits erhalten hat. Im Endeffekt könnte man sich diese Tristate Geschichte im Modul meiner Meinung auch vollständig sparen.


Grüße Sidey

[Sidey]

kann ich mit dem Signalduino den Maverick 732 auslesen?

Hi,


Das wurde schon mal begonnen.
Also Empfangen geht, sollte auch bei dir der Fall sein, dass etwa alle 12 Sekunden etwas im Log auftaucht.

Bislang hat aber noch niemand ein Modul erstellt, in dem die Umrechnung der Werte erfolgt.

Details zu dem, was bislang passiert ist findest Du hier:
https://github.com/RFD-FHEM/RFFHEM/issues/61

[Sidey]

Mit der aktuellen Version in der stable gehen meine Funkuhren wieder mal nicht.

Was für Funkuhrem und mit stable meinst Du die 3.2.0b12 korrekt?

Grüße Sidey

[Sidey]

Hallo, habe mir im Baumarkt Unitec Funksteckdosen gekauft...so wie hier http://www.amazon.de/uniTEC-48111-Funkfernschalterset-Micro-silber/dp/B003BIERWU. Die Steckdosen haben keinen DIP Schalter, waren aber mit 12€ recht günstig, so daß ich nicht denke, daß sie selbstlernend sind...
Hätte mich vielleicht vorher informieren sollen, ob die funktionieren. Gibt es eine Möglichkeit das Protokoll mit dem Signalduino auszulesen ? Wie gehe ich da am besten vor ? Signalduino habe ich schon mal in verbose 5 gesetzt...

Hi,

verbose 5 war schon mal gut.
Dann einfach mal die Tasten auf der FB drücken.
Wenn Du es genau im Abstand von 10 Sekunden immer machst, kannst Du es im Log leichter finden. Wenn Du da nichts findest, dann mach das mal 1 Minute lang und post dein Log (von dieser Minute) hier. Ich denke so lässt es sich finden.

Grüße Sidey

[Ralf9]

Dann die Clock doch lieber als Range angeben, so wie es für Manchster Protokolle bereits implementiert ist.

Ja, als Clockrange wäre es flexibler. Als optionales Feld wäre es ausreichend, damit nicht alle Protokolle angepasst werden müssen.

Beim MS_Parse könnte es so aussehen:

Code Auswählen Erweitern

# Check Clock if is it in range
if (defined($ProtocolListSIGNALduino{$id}{clockrange})) {
$valid=($clockabs >= $ProtocolListSIGNALduino{$id}{clockrange}[0] and $clockabs <= $ProtocolListSIGNALduino{$id}{clockrange}[1]);
} else {
$valid=SIGNALduino_inTol($ProtocolListSIGNALduino{$id}{clockabs},$clockabs,$clockabs*0.30) if ($ProtocolListSIGNALduino{$id}{clockabs} > 0);
}



Dies ist momentan aber nicht so wichtig.
Das verbessern der Firmware dürfte momentan wichtiger sein.

Gruß Ralf

[Hauswart]

Was für Funkuhrem und mit stable meinst Du die 3.2.0b12 korrekt?

Grüße Sidey

Genau. Ich meine meinen Radio Wecker und meine Badezimmer Uhr welche beide via Funk die aktuelle Uhrzeit erhalten. DCF77.

[Hauswart]

Was für Funkuhrem und mit stable meinst Du die 3.2.0b12 korrekt?

Grüße Sidey

Genau. Ich meine meinen Radio Wecker und meine Badezimmer Uhr welche beide via Funk die aktuelle Uhrzeit erhalten. DCF77

[Hauswart]

Was für Funkuhrem und mit stable meinst Du die 3.2.0b12 korrekt

Genau. Ich meine meinen Radio Wecker und meine Badezimmer Uhr welche beide via Funk die aktuelle Uhrzeit erhalten. DCF77

[Ralf9]

Ja, also im SIGNALduino ist da nichts sinnvoll zu machen.
Das einfachste wäre, wenn man das IT Modul dafür erweitern würde. Es müsste eigentlich ausreichen, wenn man anstatt der Fehlermeldung unknown Tristate einfach annimmt, dass man die tatsächlichen Bits erhalten hat.

Ich sehe dafür momentan nur eine saubere Lösung.
Da das  IT Modul vorwiegend für Steckdosen ist, dürfte der ev1527 nicht so richtig dazupassen.
Eine Möglichkeit wäre für den ev1527 eine neue Protokoll ID anzulegen mit einer Clockrange bis ca 200
und für die Protokoll ID 3 eine Clockrange ab 200 festzulegen.
Falls irgendwann mal eine IT v1 Steckdose mit einen Clock kleiner 200 auftrauchen sollte, könnten wir dann dafür eine extra Protokoll ID anlegen.

Gruß Ralf

[Sidey]

Wieso soll das nun helfen?
Das Resultat wäre vermutlich, dass meine und viele anderen Steckdosen nicht mehr erkannt werden würden.

Grüße Sidey

[Ralf9]

Wieso soll das nun helfen?
Das Resultat wäre vermutlich, dass meine und viele anderen Steckdosen nicht mehr erkannt werden würden.

Ich ging davon aus, daß die IT v1 Steckdosen mit der ID 3 einen Clock größer 200 haben. Mein Intertechno v1 Sender hat einen Clock größer 300.
Falls es auch IT v1 ID 3 Steckdosen mit einem Clock kleiner 200 gibt, vergiss meinen Vorschlag.

Gruß Ralf

[Sidey]

Ich ging davon aus, daß die IT v1 Steckdosen mit der ID 3 einen Clock größer 200 haben. Mein Intertechno v1 Sender hat einen Clock größer 300.
Falls es auch IT v1 ID 3 Steckdosen mit einem Clock kleiner 200 gibt, vergiss meinen Vorschlag.

Naja, Intertechno ist eine Firma die solche Steckdosen herstellt.
Das IT Modul funktioniert auch gut mit vielen Steckdosen anderer Hersteller (nicht alle). Im Grunde nutzen die alle die gleiche Modulation, aber andere Chips und andere Quarze.

Hier ist das mal ganz gut beschrieben:
https://github.com/agent4788/rc-switch/wiki/Line-Coding

Ich habe hier Steckdosen mit irgend einem sehr seltsamen Chip und einem Takt von 180 us. Die funktionieren so wie es derzeit ist recht gut.

Grüße Sidey

[Ralf9]

Hier ist das mal ganz gut beschrieben:
https://github.com/agent4788/rc-switch/wiki/Line-Coding

Ok, damit ist es klar geworden.
Der EV1527 hat demnach eine 20 Bit ID die sich bei jedem Batteriewechsel ändert.

Da fallen mir 2 Möglicheiten ein.

Vorschlag 1:
Das IT-Modul um den EV1527 erweitern.

Vorschlag 1:
Für den EV1527 eine neue Protokoll ID:
Dann beim Parse der ID 3 eine postDemodulation Routine aufrufen, die prüft ob im Signal kein Tristate "10" enthalten ist.
Und beim parse der neuen Protokoll ID eine postDemodulation Routine aufrufen, die prüft ob im Signal in den ersten 20 Bit "10" enthalten ist.

Gruß Ralf

[Horst12345]

Hallo,

wäre jmd. mal so nett mir eine Version für einen Arduino Nano und 8MHZ hochzuladen? Ich hab mich am selbst Kompilieren versucht, bin aber kläglich gescheitert...

Würde über Signalduino gern versuchen die Funkcodes für meine Motorleinwand zu ermitteln.

Besten Dank!