SIGNALDuino Empfänger Firm- und Hardware

[dela2017]

Hallo,

mein nanoCul funktioniert mit SIGNALDuino sehr gut !!
Aktuell in Benutzung:
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38

Unsere Somfy Rollläden lassen sich prima damit steuern.

Jetzt wollte ich auch mal schauen, ob ich nicht unsere Markise ansteuern kann.
- WAREMA EWFS -
Habe einige Beiträge hier im Forum dazu gefunden, aber noch nichts wirkliches mit sduino.

Die Signale werden nicht als Manchester Signal erkannt.
Im Coding steht die setMinBitLen wohl auf 17.

Sidey hatte damals dazu geschrieben:

Hi, der Grund liegt daran, dass immer da wo die Pulslänge #4 gemessen wird, das Manchester Signal unterbrochen wird. Die Anzahl der Bits zwischen diesen Abschnitten sind zu gering und fallen durch die Toleranz. Derzeit müssen mindestens 17 Bits zusammenhängend erkannt werden, sonst wird davon ausgegangen, dass es nichts brauchbares ist. Wenn ich es richtig verstanden habe, werden erst mal 14 Bit und dann 9 Bit übertragen.
Weisst Du ob die alle brauchst oder nur die 14 ?

Die Toleranzwerte zu reduzieren bringt halt immer einher, dass ggf. auch fehlerhafte Übertragungen als Manchester erkannt werden.

Ist vielleicht hier im Bereich noch etwas passiert?
Ich würde mich auch sehr gerne als Testkaninchen bereitstellen.

Viele Grüße,
Ingo

[elektron-bbs]

Hallo,
der RSSI wird ja jetzt als Internal vom SIGNALduino angezeigt. Ich habe aber noch keine Lösung gefunden, wie dieser Wert auch geloggt und weiterverarbeitet werden kann. Beim CUL muss man ja das Attribut "addvaltrigger" setzen. Das finde ich aber bei sduino nicht. Habe ich da etwas übersehen?
MfG

[Ralf9]

wenn das Attribut "addvaltrigger" dafür ausreichend ist, kann ich es in die dev-Version einbauen.
Ich habe es mal getestet. Mit "addvaltrigger 1" werden 3 zusätzliche events erzeugt.
z.B.

Code Auswählen Erweitern

2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 DMSG: s6C00A96788EE
2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 RAWMSG: MS;P3=-2101;P4=574;P5=-4150;P6=-9058;D=4643454543454543434343434343434343454345434543434543454543434545454543434345;CP=4;SP=6;R=238;
2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 RSSI: -83

Gruß Ralf

[elektron-bbs]

Ja, laut commandref von FHEM:
"Generiert Trigger für zusätzliche Werte. Momentan sind dies RSSI und RAWMSG für die CUL Familie und RAWMSG für FHZ. "

Wenn einem die Logs zu groß werden, kann man das in den Einstellungen für die Logs ja wieder einschränken.

Andere Frage:
Wie kann ich in der 00_SIGNALduino.pm in einer SUB, die über "postDemodulation" aufgerufen wurde, dem Programm anschließend mitteilen, das ein Fehler aufgetreten ist und die Dekodierung abgebrochen werden soll? Bin gerade bei der Einarbeitung der Fehlerermittlung für den WS7000 und FS10.

MfG

[Sidey]

Hallo Elektrom-bbs,

Erst mal danke, dass Du dich an der Entwicklung beteiligst.

Du bist im falschen Thread für diese Frage. Hier geht es nur um die Hardware und die Firmware.

Nun zur Antwort auf deine Frage.
Die postdemodulation Funktion gibt mehrere Parameter zurück.
Der erste zurückgegebene Wert ist der returncode. Ist dieser 0, wird die weitere Verarbeitung abgebrochen.

[HomeAuto_User]

Guten Abend,

wenn das Attribut "addvaltrigger" dafür ausreichend ist, kann ich es in die dev-Version einbauen.

das ganze würde ich bevorzugen.
Wäre klasse von schön von Nutzen wenn dies implementiert wird.

MfG

[stefanru]

Hi,

ich hätte auch ne Frage. Ist es möglich ein SIGNALDuino mit ESP8266 ins WLAN zu hängen?
Meine Frage kommt daher dass ich zu ein paar Außenlampen eine nicht so gute funkverbindung habe und ich würde sehr gerne einen Sduino in die nähe bringen damit das Schalten zuverlässig funktioniert.
Wlan ist bis dort ausreichend.

Gibts dafür eine Anleitung, Schaltplan?

Gruß,
Stefan

[pejonp]

Hi,
Schau  mal hier https://forum.fhem.de/index.php/topic,58396.msg521044.html#msg521044.
Pejonp

[Ralf9]

Mit einem Wemos D1 mini ist die Schaltung recht einfach. Anstatt dem pro mini kann auch der nano verwendet werden
https://forum.fhem.de/index.php/topic,58396.msg512645.html#msg512645

Gruß Ralf

[stefanru]

Ok danke.
Das von Ralf sieht einfacher aus. Würde ich mit nem Nano probieren.
Wie wird das dann ans FHEM angebunden?
Muss man dann die IP angeben?

Geht der D1 mini?
http://www.ebay.de/itm/ESP8266-ESP-12-ESP12-WeMos-D1-Mini-WIFI-Dev-Kit-Entwicklung-Tafel-NodeMCU-Lua-/172385704368?hash=item2822fd19b0:g:fVIAAOSwA3dYCtTp

Vielen Dank,
Stefan

[HomeAuto_User]

Hallo,

wenn das Attribut "addvaltrigger" dafür ausreichend ist, kann ich es in die dev-Version einbauen.
Ich habe es mal getestet. Mit "addvaltrigger 1" werden 3 zusätzliche events erzeugt.
z.B.

Code Auswählen Erweitern

2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 DMSG: s6C00A96788EE
2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 RAWMSG: MS;P3=-2101;P4=574;P5=-4150;P6=-9058;D=4643454543454543434343434343434343454345434543434543454543434545454543434345;CP=4;SP=6;R=238;
2017-02-25 18:25:13.902 CUL_TCM97001 GT_WT02_108 RSSI: -83

Gruß Ralf

INFO:
ich habe das ganze mal soeben getestet.
Vorgehensweise

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

danach FHEM neu gestartet. Es tat sich wieder das Phänomen auf, das die Empfänger als "offen = open" angezeigt werden und erst nach einem get ccconf des jeweiligen Empfänger erst wieder Signale empfangen.
Das Ganze lässt sich reproduzieren, sobald ich nun FHEM neu starte, bin ich gezwungen das erneut zu machen.

2017-02-27_18:35:58 Hideki_30_5 T: 21 H: 47
2017-02-27_18:35:58 Hideki_30_5 temperature: 21
2017-02-27_18:35:58 Hideki_30_5 RSSI: -110.25
2017-02-27_18:35:58 Hideki_30_5 DMSG: P12#75B7BACAF0BE3D55E15701
2017-02-27_18:35:58 Hideki_30_5 RAWMSG: MC;LL=-1006;LH=945;SL=-514;SH=466;D=A8C4B45ACF860A8755BC454;C=488;L=90;R=3;
2017-02-27_18:35:58 Hideki_30_5 DMSG: P12#75B7BA8AF0BE3D55A16D01
2017-02-27_18:35:58 Hideki_30_5 RAWMSG: MC;LL=-999;LH=946;SL=-518;SH=465;D=A8C4B45AEF860A8755BD524;C=487;L=90;R=3;
2017-02-27_18:35:58 Hideki_30_5 RSSI: -110.25
2017-02-27_18:35:59 Hideki_30_5 RSSI: -110.25
2017-02-27_18:35:59 Hideki_30_5 DMSG: P12#75B7BA4AF0BE3D55617B03
2017-02-27_18:35:59 Hideki_30_5 RAWMSG: MC;LL=-988;LH=955;SL=-527;SH=467;D=518968B5BF0C150EAB79908;C=489;L=89;R=3;
2017-02-27_18:36:49 Hideki_30_5 DMSG: P12#75B7BA8AF0BE3D55A16D03
2017-02-27_18:36:49 Hideki_30_5 RAWMSG: MC;LL=-1005;LH=949;SL=-519;SH=455;D=518968B5DF0C150EAB7AA48;C=487;L=89;R=253;
2017-02-27_18:36:49 Hideki_30_5 RSSI: -111.75

War es gewollt, das neben dem RSSI auch die Meldungen DMSG + RAWMSG auch im Log des jeweiligen Sensor erscheinen?
Ich kenne es, das neben den normalen Werten, nichts anderes mitgeloggt wurde. (BSP: T: H: RSSI )
Wenn ja, könnte man das ganze etwas einschränken, in etwa so

2017-02-27_18:35:58 Hideki_30_5 T: 21 H: 47
2017-02-27_18:35:58 Hideki_30_5 temperature: 21
2017-02-27_18:35:58 Hideki_30_5 RSSI: -110.25
2017-02-27_18:35:58 Hideki_30_5 DMSG: P12#75B7BACAF0BE3D55E15701
2017-02-27_18:35:58 Hideki_30_5 RAWMSG: MC;LL=-1006;LH=945;SL=-514;SH=466;D=A8C4B45ACF860A8755BC454;C=488;L=90;R=3;

Grund zum Test, Funktion addvaltrigger 1 testen.

MfG

EDIT: Sobald ich das Backup zurück schiebe geht wieder "alles". Es muss also Unterschiede geben welche beim Update ggf. noch fehlerbehaftet sind.

[Ralf9]

danach FHEM neu gestartet. Es tat sich wieder das Phänomen auf, das die Empfänger als "offen = open" angezeigt werden und erst nach einem get ccconf des jeweiligen Empfänger erst wieder Signale empfangen.
Das Ganze lässt sich reproduzieren, sobald ich nun FHEM neu starte, bin ich gezwungen das erneut zu machen.

Ich kann dies bei mir nicht nachvollziehen, wenn ich fhem neu starte, funktioniert der Empfang automatsch wieder.

War es gewollt, das neben dem RSSI auch die Meldungen DMSG + RAWMSG auch im Log des jeweiligen Sensor erscheinen?

Beim Attribut "addvaltrigger" besteht kein Einfluss bei welchen zusätzlichen Werten events erzeugt werden. Es wird von allen Werten, die beim dispatch ans jeweilige Modul übergeben werden events erzeugt.

Gruß Ralf 

[HomeAuto_User]

Hallo und danke Ralf,

Ich kann dies bei mir nicht nachvollziehen, wenn ich fhem neu starte, funktioniert der Empfang automatsch wieder.
Beim Attribut "addvaltrigger" besteht kein Einfluss bei welchen zusätzlichen Werten events erzeugt werden. Es wird von allen Werten, die beim dispatch ans jeweilige Modul übergeben werden events erzeugt.

Gruß Ralf

das Problem RasPi, keine Initialisierung bzw. PING habe ich einen neuen Faden "geschoben". Hier wird nun alles diesbezüglich gesammelt und weiter darüber berichtet.
Hoffentlich mit einem Erfolg  .

LG

[stefanru]

ich habe nun auch den ESP erfolgreich an den Signalduino angebunden.
Ich habe dazu den "WeMos D1 mini" und "Arduino pro mini" verwendet, Schaltung siehe Anlage.
Da ich den ESP Link nicht zum funktionieren gebracht habe, habe ich den Beispiel sketch
ESP8266WIFI - WiFiTelnetToSerial
von der Arduino IDE mit einigen Anpassungen verwendet.

Nachtrag:
Die Schaltung gilt für UART pins swapped.

Nachtrag2:
Inzwischen habe ich es auch mit ESP Link getestet.

Gruß Ralf

Hi, bekomme demnächst meinen D1 möchte nach dieser Schaltung vorgehen, aber mit einem Nano.
Warum sind die Wiederstände Nötig?
Laufen nicht beide auf den Datenleitungen auf 3,3V?

Gruß,
Stefan

[sash.sc]

Der Pro Mini läuft mit 3,3v, meistens jedenfalls.
Der nano mit USB Anschluss 5v. Der cc1101 mit 3,3v. Deswegen eigentlich die Pegelanpassung.
Die meisten haben aber keine Pegelanpassung. Funktioniert auch....
Kann aber den cc1101 irgendwann evtl grillen....

Gesendet von meinem E6653 mit Tapatalk