FHEM Forum

Verschiedenes => Bastelecke => Thema gestartet von: Ralf9 am 02 Oktober 2016, 22:59:51

Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 Oktober 2016, 22:59:51
Hallo,

ich habe hier mal die Infos zur SIGNALDuino Empfänger Firm- und Hardware zusammengefaßt:

Falls mit dem SIGNALDuino auch Sensoren empfangen werden, die Manchester (MC) Nachrichten senden, dann sollte ein Firmware Update auf die Version 3.3. durchgeführt werden.
Bei der V 3.3. wurde die Dekodierung von Manchester Nachrichten deutlich verbessert.

Es sollte ein Superhet oder Superheterodyne Empfänger verwendet werden.
Ein Superregeneration Empfänger ist nicht zu empfehlen.

Als 868 MHz Empfänger ist dieser zu empfehlen:
http://www.elv.de/elv-empfangsmodul-rx868sh-dv.html


Mit einem USRIOT Serial Ethernet Converter Modul
USR-TCP232-T2 oder
USR-TCP232-T oder
usr-k1
ist es auch möglich den SIGNALDuino über Ethernet anzubinden. Ich habe es mit dem USR-TCP232-T2 und einem Pro Mini getestet.
Zwischem dem TX vom Pro Mini und dem RX vom USR-TCP232.. ist ein Level Shifter notwendig,da der USR mit 3,3 V arbeitet.

Eine Remoteanbindung ist auch mit socat oder ser2net (noch ungetestet) möglich:
https://forum.fhem.de/index.php/topic,59473.msg508448.html#msg508448

Hier ist eine Anleitung von @hjgode um einen Arduino Nano mit der SignalDuino Software und einem ESP-01 über WLAN anzubinden:
http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/

Sidey versucht ob es auch nur mit dem ESP funktioniert:
Zitat von: Sidey am 24 September 2016, 09:59:55
Ich habe den ESP mal SIGNALESP genannt und mit aktuellen Bibliotheken neu compiliert.

Die Funktion (Empfang getestet) ist gegeben. (Serielle Ausgabe)
Wie schon vor einiger Zeit, resettet sich der ESP Recht häufig. In FHEM sieht man das nur, wenn man die Uptime anruft.

Übrigens mag es der ESP nicht, wenn er sich den Empfänger mit einem Arduino teilt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 03 Oktober 2016, 01:20:00
Inzwischen gibt es für den Signalduino eine Firmware die den CC1101 unterstützt. Es wird die Verkabelung des nanoCUL verwendet.
Hier sind Schaltungsvarianten mit dem 3,3V 8MHz promini bei denen man sich keine Gedanken über Levelshifter machen muß, da keine benötigt werden.
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241

Die Firmware ist noch in Entwicklung.
Ich habe die folgenden Befehle eingebaut. Gesendet werden sie mit
get sduino raw

Alle Werte sind in hex:
C<reg>
    <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
    Example: C35 -> C35 = 0D

e
    EEPROM / factory reset.  resets all eeprom values without reboot

r<AA>
    Read eeprom  (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
r<AA>n
    Read 16 byte from eeprom (z.B. r00n)

W<AA><DD>
    Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

WS<AA>
   Strobe commands z.B:
   34   Enable RX
   36   Exit RX / TX  (idle state)

x<pp> Change the (EEPROM) PA tables (power amplification for RF sending)



MIt C35 wird das MARCSTATE Register ausgelesen:
01 - IDLE
02 - XOFF
0D - RX
12 - ENDCAL
13 - TX



Mit dem WS Befehl kann der state des CC11001 gewechselt werden. Hier ist sind einige strobe commands:
31  SFSTXON  Enable and calibrate frequency synthesizer (if MCSM0.FS_AUTOCAL=1). If in RX (with CCA): Go to a wait state where only the synthesizer is running (for quick RX / TX turnaround).
34  Enable RX
35  Enable TX
36  Exit RX / TX  (idle state)
3D  No operation. May be used to get access to the chip status byte.


Beim WS Befehl wird der chip status zurück gegeben:
0  IDLE       IDLE state  (Also reported for some transitional states instead of SETTLING or CALIBRATE)
1  RX         Receive mode
2  TX         Transmit mode
3  FSTXON     Fast TX ready
4  CALIBRATE  Frequency synthesizer calibration is running
5  SETTLING   PLL is settling
6  RXFIFO_OVERFLOW
7  TXFIFO_UNDERFLOW



Mit dem x Befehl kann die Sendeleistung geändert werden. Hier sind die Werte für 433 MHz:
34 -10_dBm
68  -5_dBm
60   0_dBm
84   5_dBm
C8   7_dBm
C0  10_dBm


Mit C3E kann die PATABLE ausgelesen werden
Mit r30n kann die im EEPROM gespeicherte PATABLE ausgelesen werden

Die PATABLE besteht aus 8 Werten. Da das PA ramping nicht verwendet wird, wird nur der zweite Wert verwendet.




Hier sind die allgmeinen Befehle:
? -> help
V -> Version
R -> freeRam
t -> uptime
XE -> enableReceiver
XQ -> disableReceiver
P -> Ping
CG -> getConfig
enableMessagetype
  CES -> MS
  CEC -> MC
  CEU -> MU
disableMessagetype
  CDS -> MS
  CDC -> MC
  CDU -> MU
CER -> Einschalten der Datenkomprimierung (config: Mred=1)
CDR -> Abschalten der Datenkomprimierung (config: Mred=0)


S -> send
SR;R=3;...   sendet die Daten im Raw-Modus dreimal wiederholt
SM;R=3;...   sendet die Daten Manchester codiert dreimal wiederholt
SC;R=3;...   sendet eine kombinierte Nachricht dreimal wiederholt (das SC am Anfang wird benötigt um bei einer kombinierten Nachricht ein repeat anzugeben)

In meiner Firmware V 3.3.2 gibt es zusätzlich noch:
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
CED -> Debugausgaben ein
CDD -> Debugausgaben aus
CDL -> Message-LED aus
CEL -> Message-LED ein
CEO -> Einschalten der sehr langen MU-Nachrichten (config: MuNoOverflow=1)
CDO -> Abschalten der sehr langen MU-Nachrichten
CSmscnt=[Wert]     -> Wiederholungszähler für den split von MS Nachrichten (default=4)
CSmuthresh=[Wert]  -> Schwellwert in us für den split von MU Nachrichten (0=aus)
CSmcmbl=[Wert]     -> minbitlen für MC-Nachrichten
CSfifolimit=[Wert] -> Schwellwert für debug Ausgabe der Pulsanzahl im FIFO Puffer

?S -  show configSet commands (z.Zt.:  fifolimit mcmbl mscnt muthresh)

eC - initEEPROMconfig
     Damit werden die config Daten im EEPROM auf default zurückgesetzt

In den FIFO Empfangspuffer gehen z.Zt. 100 Pulse, dh. eine Ausgabe von MD=100 bedeutet ein Pufferüberlauf

Ab meiner Firmware V 3.3.2.2-rc10 gibt es

CSmaxnumpat=[Wert]  -> Mit maxnumpat kann man dann die max Anzahl Pattern bis auf 16 erhöhen (P0-PF Hex), default ist 8.
CSmaxpulse=[Wert]   -> Mit maxpulse kann man die max Pulslänge (default -32001) verkleinern, ab der ein Ende erkannt wird. Z.B. mit maxpulse 17000 wird -18532 als Ende erkannt.


Ab meiner Firmware V 3.3.4 gibt es
https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643

rN<adr16> -> read 64 Byte from EEPROM
b         -> Info über die gerade aktive Bank
bs        -> banksummary
b<0-9>    -> damit können die cc1101 Register zwischen 10 verschiedenen EEPROM Bänken (0000, 0100, 0140, 0180, 01C0,..) umgeschaltet werden.
CW<reg><val>, <reg><val>...  -> damit kann eine folge von cc1101 Registern gesetzt und in die aktuelle EEPROM Speicherbank geschrieben werden

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 03 Oktober 2016, 09:31:50
Hallo Ralf9,

danke für die hilfreiche Übersicht! Ich hab mir hier schon einen 433MHz Signalduino zusammengebaut und würde das gerne auch für 868MHz tun. Dass RX Modul von ELV hatte ich auch schon im großen Thread "entdeckt", aber was nehme ich für TX? Ich hab hier noch 433 TX Module liegen, die sind aber sicherlich nicht geeignet oder?
Ich hab hier noch einen CC1101 (RF1100SE), der wird aber nicht dafür geeignet sein oder?

prodigy7
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ellert am 03 Oktober 2016, 10:12:30
Zitat von: Ralf9 am 03 Oktober 2016, 01:20:00
Liest hier auch jemand mit der sich mit den CC1101 Empfänger auskennt oder ist es besser, wenn ich diese Frage  in CUL Hard- und Firmware stelle?

Der beim SIGNALDuino verwendete RXB6 Superheterodyne Empfänger hat recht gute Empfangseigenschaften.

Weiß zufällig jemand, wie dies im Vergleich dazu bei einem Empfänger mit einem CC1101 aussieht?
Hat ein Empfänger mit dem CC1101 bessere Empfangseigenschaften als der RXB6 Superheterodyne?

Bei ebay habe ich 2 Typen gefunden:

D-Sun CC1101 Wireless Transceiver Module
- Adopt FSK modulation,support OOK/ASK/MSK modulation;

CC1101 Wireless Kabellos RF Transceiver Modul mit SMA Antenna
- Support 2-FSK, GFSK and MSK modulation;
Ist dieser für OOK/ASK weniger geeignet, da dies hier nicht dabeisteht?

Gruß Ralf

Die verwendbaren Transceiver sind im Wiki gut beschrieben Die_unterschiedlichen_Ausführungen_des_Funkmoduls (http://www.fhemwiki.de/wiki/Selbstbau_CUL#Die_unterschiedlichen_Ausf.C3.BChrungen_des_Funkmoduls)
Es wäre schon interessant wenn die SD-Firmware auf der nanoCUL Hardware laufen würde.

Ich nutze den nanoCUL433 und den SD 433 und habe bei der Nutzung keine Unterschiede in der Sende und Empfangsleistung festgestellt. Meine Sensoren befinden sich alle innerhalb eines Umkreises von 7 m.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 03 Oktober 2016, 11:31:31
Zitat von: prodigy7 am 03 Oktober 2016, 09:31:50
aber was nehme ich für TX? Ich hab hier noch 433 TX Module liegen, die sind aber sicherlich nicht geeignet oder?
Ich hab hier noch einen CC1101 (RF1100SE), der wird aber nicht dafür geeignet sein oder?

Wenn ich das richtig überblicke verwendet bis jetzt noch niemand beim SIGNALDuino einen 868MHz sender.
Bei 868MHz gibt es beim Senden auch die 1% Regel zu beachten.

Bei elv gibt es diesen Sender:
http://www.elv.de/hf-sendemodul-tx868-75-868-mhz.html

Der CC1101 ist für den SIGNALDuino nicht geeignet.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 24 Oktober 2016, 19:44:10
Zitat von: Sidey am 24 September 2016, 09:59:55
Ich habe den ESP mal SIGNALESP genannt und mit aktuellen Bibliotheken neu compiliert.

Die Funktion (Empfang getestet) ist gegeben. (Serielle Ausgabe)
Wie schon vor einiger Zeit, resettet sich der ESP Recht häufig. In FHEM sieht man das nur, wenn man die Uptime anruft.

Übrigens mag es der ESP nicht, wenn er sich den Empfänger mit einem Arduino teilt.

Kann dies mit dem Wlan überhaupt funktionieren? Dem ESP muß doch regelmässig etwas Zeit gegeben werden, damit er sich ums Wlan kümmern kann.
Wie sieht es aus, wenn während der ESP sich ums Wlan kümmert, vom 433/868 MHz Empfänger eine Signalflanke kommt, kann der Interrupt dann die interne Wlan Routine unterbrechen?

@hjgode
weißt Du zufällig was darüber?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 Oktober 2016, 20:34:44
Der Interrupt unterbricht das WLAN. Damit das WLAN läuft, muss man immer mal delay oder yield aufrufen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 24 Oktober 2016, 21:28:47
Wenn ich die Doku richtig in Erinnerung habe, dann gibt es "nur" Software-Interrups auf dem ESP8266. Ob die das WLAN unterbrechen wage ich zu bezweifeln.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Oktober 2016, 21:07:53
ZitatWie schon vor einiger Zeit, resettet sich der ESP Recht häufig. In FHEM sieht man das nur, wenn man die Uptime anruft.

Sind die häufigen resets inzwischen weg?
Ein Grund dafür könnte der watchdog sein der einen Reset durchführt, falls die internen Routinen (u.a. wlan und tcp-Stack) nicht mindestens einmal pro Sekunde ausgeführt werden.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Oktober 2016, 21:26:57
Ich möchte auch mit dem ESP Link den ESP an den Signalduino anbinden.
Ich möchte dazu den "WeMos D1 mini" und "Arduino pro mini" verwenden.

Das hier irretiert mich etwas
http://www.ebay.de/itm/ABVERKAUF-WeMos-kompatibel-D1-Mini-NodeMcu-ESP8266-i2c-Arduino-/182320253021?hash=item2a7322485d:g:6XIAAOSwzJ5Xcj2u (http://www.ebay.de/itm/ABVERKAUF-WeMos-kompatibel-D1-Mini-NodeMcu-ESP8266-i2c-Arduino-/182320253021?hash=item2a7322485d:g:6XIAAOSwzJ5Xcj2u)
ZitatBei diesem Angebot handelt es sich um den Abverkauf unseres Bestandes an kompatiblen WeMos Modulen. Da wir unseren Kunden preisgünstige aber 100% zuverlässige Module und Sensoren anbieten möchten, fallen die WeMos kompatiblen Module aufgrund hoher Fehleranfälligkeit aus unserem Sortiment.

Spricht was gegen diesen hier?
http://www.ebay.de/itm/WeMos-D1-mini-IOT-ESP8266-DIY-ESP12-WLAN-WiFi-NodeMcu-Arduino-Raspberry-Pi-E23P-/172357074201?hash=item2821483d19:g:Jb4AAOSwCGVX67lw

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Oktober 2016, 21:34:46
Zitat von: Ralf9 am 25 Oktober 2016, 21:07:53
Sind die häufigen resets inzwischen weg?

Bei mir schon. Er lief einige Tage ganz gut. Dann hat er sich aufgehangen.. keine Ahnung was passiert ist. Es.könnten auch äußere Einflüsse verantwortlich gewesen sein.

Der  Watchdog will regelmäßig resettet werden, das ist richtig. Mit WLAN oder tcp Stack hat das allerdings wenig zu tun. Der Watchdog operiert unabhängig davon.

Die WLAN Anbindung ist noch nicht eingebaut. Das muss noch finalisiert werden.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Oktober 2016, 18:59:47
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 13 November 2016, 18:50:38
Hallo,

ich habe für meine WS-0101 und WH1080 Wetterstationen die Anbindung an den FHEM mit Signalduino über esp8266 realisiert.
Der 868 MHz Empfänger von elv (http://www.elv.de/elv-empfangsmodul-rx868sh-dv.html) ist am Signalduino angeschlossen und RX/TX sind an einem esp8266 nach dieser Schaltung von @hjgode (http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden ) angeschlossen.

Beim ESP8266-01 ist die Version esp-link v2.2.3 - 2016-06-21 21:58:48 im Einsatz (https://github.com/jeelabs/esp-link).
Der Signalduino hat die Version (V 3.2.0-b21 SIGNALduino - compiled at Apr 16 2016 01:44:24).

Diese Anbindung läuft schon seit 2015, nach einem Hinweis von @hjgode (https://forum.fhem.de/index.php/topic,38831.msg365598.html#msg365598). Grund war auch, das der Nano sich nicht mehr per USB ansprechen ließ und auch die Anschlüsse am Banana Pi zu Ende gingen. Geflasht wird über ISP (mySmartUSB light), bei mir geht es nicht über den esp8266. Die Schaltung ist immer noch auf einem Steckbrett.

pejonp

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andreasnol am 28 November 2016, 11:50:38
Hallo
Ich hab mir schon einen 433MHz Signalduino zusammengebaut. Er funktioniert wuderbar jetzt auch mit Rollläden.
Tolle Arteit danke.
Aus platzgründen würde mich interesieren, ob schon jemand den Signalduino mit einem RFM-Funlmodul bestückt hat oder
einen Jeelink mit der Signalduino Software geflasht hat?

Andreas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 Dezember 2016, 18:02:36
Hallo,

ich bin gerade dabei die set- und get-Befehle des CC1101 vom "00_CUL.pm" in die "00_SIGNALduino.pm" einzubauen.
Das "goto GOTBW" vom set bWidth gefällt mir nicht so richtig, dies müsste auch eleganter gehen

  } elsif($type eq "bWidth") {
    my ($err, $ob);
    if(!IsDummy($hash->{NAME})) {
      CUL_SimpleWrite($hash, "C10");
      ($err, $ob) = CUL_ReadAnswer($hash, $type, 0, "^C10 = .*");
      return "Can't get old MDMCFG4 value" if($err || $ob !~ m,/ (.*)\r,);
      $ob = $1 & 0x0f;
    }

    my ($bits, $bw) = (0,0);
    for (my $e = 0; $e < 4; $e++) {
      for (my $m = 0; $m < 4; $m++) {
        $bits = ($e<<6)+($m<<4);
        $bw  = int(26000/(8 * (4+$m) * (1 << $e))); # KHz
        goto GOTBW if($arg >= $bw);
      }
    }

GOTBW:
    $ob = sprintf("%02x", $ob+$bits);
    Log3 $name, 3, "Setting MDMCFG4 (10) to $ob = $bw KHz";
    CUL_SimpleWrite($hash, "W12$ob");
    CUL_WriteInit($hash);


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 06 Dezember 2016, 20:43:03
Hmm, das ist ja sehr spannend.
Was gibt der cc1101 denn am GDO02 aus?  Ist das eine Serielle Übertragung, die Manchester Codiert ist?
Was das Setzen der Register angeht, könnte man die ja durchaus aus der CULfw übernehmen. Um die Register zu verstehen und zu verändern gibt es von TI ein tool.

Der Abschnitt ab goto könnte in eine eigene Funktion oder direkt inline an dieser Stelle aufgeführt werden.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 Dezember 2016, 21:24:53
Zitat von: Sidey am 06 Dezember 2016, 20:43:03
Was das Setzen der Register angeht, könnte man die ja durchaus aus der CULfw übernehmen. Um die Register zu verstehen und zu verändern gibt es von TI ein tool.
Das Lesen und Setzen der Register habe ich in meinem sketch vom AskSin und der a-culw übernommen.
Bis auf das set bWidth habe ich die Routinen des CC1101 vom "00_CUL.pm" in die "00_SIGNALduino.pm" eingebaut.
Die konfiguration für das Senden fehlt noch.

Zitat
Der Abschnitt ab goto könnte in eine eigene Funktion oder direkt inline an dieser Stelle aufgeführt werden.

Ist das mit dem goto so sauber programmiert oder würdest Du es umschreiben.
Ich verstehe nicht so richtig wie dies funktioniert. Werden mit dem goto beide for Schleifen sauber verlassen?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 06 Dezember 2016, 21:36:17
Zitat von: Ralf9 am 06 Dezember 2016, 21:24:53
Das Lesen und Setzen der Register habe ich in meinem sketch vom AskSin und der a-culw übernommen.
Bis auf das set bWidth habe ich die Routinen des CC1101 vom "00_CUL.pm" in die "00_SIGNALduino.pm" eingebaut.
Die konfiguration für das Senden fehlt noch.
Kannst Du den quellcode mal in einem neuen branch einchecken? Interessiert mich jetzt :)


Zitat von: Ralf9 am 06 Dezember 2016, 21:24:53
Ist das mit dem goto so sauber programmiert oder würdest Du es umschreiben.
Ich verstehe nicht so richtig wie dies funktioniert. Werden mit dem goto beide for Schleifen sauber verlassen?

GOTO = gehe zu... Es ist ein Sprungbefehl. Er verlässt das Programm und setzt es an dem angegebenen Label vor. Es wird auch nicht zurück gesprungen.
Ob goto sauber oder nicht ist, darüber kann man viel streiten. Ich habe es auch schon angewendet, es gibt Situationen, da ist es ein angebrachtes Mittel der Wahl.
Oft führt es aber zu dem sogenannten "Spagetti Code".
In dem unten angegebenen Fall, sollen damit wohl zwei FOR schleifen beendet werden. Man kann das auch mit LAST <label> sauber erreichen oder $e und $m verändern (unsauber). Oder ein Flag setzen und das in der FOR schleife zusätzlich auswerten.

Wenn es um sauber geht, dann würde mir das vermutlich am besten gefallen.  (Sofern ich den Zweck der goto Funktion richtig verstanden habe)

    OUTERLOOP:
    for (my $e = 0; $e < 4; $e++) {
      for (my $m = 0; $m < 4; $m++) {
        $bits = ($e<<6)+($m<<4);
        $bw  = int(26000/(8 * (4+$m) * (1 << $e))); # KHz
        last OUTERLOOP if($arg >= $bw);
      }
   
    $ob = sprintf("%02x", $ob+$bits);
    Log3 $name, 3, "Setting MDMCFG4 (10) to $ob = $bw KHz";
    CUL_SimpleWrite($hash, "W12$ob");
    CUL_WriteInit($hash);

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 Dezember 2016, 23:09:32
Zitat von: Sidey am 06 Dezember 2016, 21:36:17
Kannst Du den quellcode mal in einem neuen branch einchecken? Interessiert mich jetzt :)

In der Anlage ist der sketch. Es gibt noch viel zu optimieren.

Es gibt noch viele todos:
- Es fehlt noch die Initialsierung der PATABLE
- die cc1101 Routinen solten noch in eine library ausgelagert werden
- beim Init sollte geprüft werden ob sich der cc1101 meldet und dann ein flag gesetzt werden. Bei gesetztem flag wird dann bei der Versionsabfrage cc11001 eingefügt und für die externe led wird dann Pin 9 verwendet.

Ist die Interruptroutine, die die Flankenzeiten in den FIFO schreibt in der Lage den Anfang oder Ende einer Nachricht zu erkennen, damit nur einmal pro Nachricht der RSSI abgefragt und gespeichert werden muss?
Oder hast Du schon eine Idee wie man das mit dem speichern der RSSI Werte machen könnte?   

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 07 Dezember 2016, 22:48:26
Hallo Ralf9,
so ganz habe ich Deine eigentliche Absicht noch nicht verstanden.
Die 868-Variante mit dem Signalduino und damit den CUL868 zu ersetzen ?

Deine Settings in der cc1101.ino beziehen sich auf 433 MHz? -> SmartRF.

Warum benutzt Du nicht die Panstamp-Lib als CC1101 Grundlage und für die PA-Settings?

Hier noch eine printf-Implementierung über Seriell, oder hier better-arduino-debugging-printf/ (http://www.eduardtiron.com/2015/06/better-arduino-debugging-printf/):

// Function that printf and related will use to print
int serial_putchar(char c, FILE* f) {
    if (c == '\n') serial_putchar('\r', f);
    return Serial.write(c) == 1? 0 : 1;
}

FILE serial_stdout;

void setup(){
    Serial.begin(9600);

    // Set up stdout
    fdev_setup_stream(&serial_stdout, serial_putchar, NULL, _FDEV_SETUP_WRITE);
    stdout = &serial_stdout;

    printf("My favorite number is %6d!\n", 12);
}

void loop() {
  static long counter = 0;
  if (millis()%300==0){
    printf("millis(): %ld\tcounter: %ld (%02X)\n", millis(), counter, counter++);
    delay(1);   
  }
}




// Rf settings for CC1101
RF_SETTINGS code rfSettings = {
    0x0B,  // IOCFG2        GDO2 Output Pin Configuration
    0x0C,  // IOCFG0        GDO0 Output Pin Configuration
    0x3D,  // PKTLEN        Packet Length
    0x32,  // PKTCTRL0      Packet Automation Control
    0x06,  // FSCTRL1       Frequency Synthesizer Control
    0x10,  // FREQ2         Frequency Control Word, High Byte
    0xB0,  // FREQ1         Frequency Control Word, Middle Byte
    0x71,  // FREQ0         Frequency Control Word, Low Byte
    0x57,  // MDMCFG4       Modem Configuration
    0xC4,  // MDMCFG3       Modem Configuration
    0x30,  // MDMCFG2       Modem Configuration
    0x23,  // MDMCFG1       Modem Configuration
    0xB9,  // MDMCFG0       Modem Configuration
    0x00,  // DEVIATN       Modem Deviation Setting
    0x00,  // MCSM1         Main Radio Control State Machine Configuration
    0x18,  // MCSM0         Main Radio Control State Machine Configuration
    0x14,  // FOCCFG        Frequency Offset Compensation Configuration
    0x07,  // AGCCTRL2      AGC Control
    0x00,  // AGCCTRL1      AGC Control
    0x90,  // AGCCTRL0      AGC Control
    0xFB,  // WORCTRL       Wake On Radio Control
    0x11,  // FREND0        Front End TX Configuration
    0xE9,  // FSCAL3        Frequency Synthesizer Calibration
    0x2A,  // FSCAL2        Frequency Synthesizer Calibration
    0x00,  // FSCAL1        Frequency Synthesizer Calibration
    0x1F,  // FSCAL0        Frequency Synthesizer Calibration
    0x2A,  // PTEST         Production Test
    0x09,  // TEST0         Various Test Settings
};
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Dezember 2016, 23:05:36
Zitat von: juergs am 07 Dezember 2016, 22:48:26
Deine Settings in der cc1101.ino beziehen sich auf 433 MHz? -> SmartRF.

Meine Settings beziehen sich auf 433 MHz SlowRF von der a-culfw.
Die cc1101 konfig der a-culfw lässt sich auch einfach mit get raw C99 anzeigen.

Es ist damit die nanocul Hardeware und Platine verwendbar.
Es besteht die Möglichkeit die RSSI auszulesen
Nur eine Antenne
Evtl besser Empfang?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Dezember 2016, 23:54:59
Ich habe mir mal die http://culfw.de/commandref.html  (http://culfw.de/commandref.html) und die a-culfw libs angeschaut. Nun ist mir das Prinzip der a-culfw klarer geworden.

Bei meiner jetztigen cc1101.ino gehen die Einstellungen beim reset verloren.
Bei W - Befehl muß noch der Offset von +2 berücksichtigt werden:
if (reg > 1 && reg < 0x3e) {
...
writeReg(reg-2, var);


In der a-culfw wird mit dem W-Befehl in das EEPROM geschrieben. Mit X21 wird es dann in die CC1101 Register geschrieben
Note: 00 disables radio reception, any other value initializes the radio chip and enables reception. Default is 00: do not report anything, radio chip is uninitialized.



Beim W-Befehl gibt es einen Offset +2 da die ersten beiden byte im EEPROM die magic bytes sind.
Wenn beim cc1101 init die magic bytes ungültig sind, dann wird das EEPROM und die cc1101 Register mit den default Werten initialisiert.
Sind die magic bytes gültig, dann werden die cc1101 Register mit den Werten vom EEPROM initialisiert.

Ich würde vorschlagen, daß wir beim W-Befehl (EEPROM write) den Wert auch gleich ins cc1101 Register schreiben.

Es ist sind noch die folgenden Befehle notwendig:
e - Befehl (EEPROM / factory reset)
x - Befehl (Change the PA tables (power amplification for sending))

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 08 Dezember 2016, 08:09:22
Klingt irgendwie logisch, dass ein Write Befehl auch die Register gleich setzt. Warum sollte man das nicht machen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 Dezember 2016, 20:32:00
Zitat von: Ralf9 am 12 Dezember 2016, 20:11:43
Das Problem habe ich auch wenn ich die a-culfw flashe, dann wird der  EAS800z und NC-7345 gar nicht empfangen.
Ich denke ein Grund könnte sein, daß ich hier im Haus Funkstörungen habe und der RXB6 Superheterodyne empfängt bei Funkstörungen besser als der CC1101.

Ich werde mal eine bessere Antenne versuchen.
Evtl bringt auch eine Abschirmung des CC1101 was. Ich kann Tipps brauchen was für ein Blech ich dafür am besten nehme, es sollte lötbar sein.

Kann ein Grund für die Probleme auch sein, daß die "blauen" CC1101 Module bzgl. der Frequenz extrem ungenau sind oder spielt das keine so große Rolle?
Dieses Modul ist anscheindend besser:
http://www.ebay.de/itm/433M-CC1101-10mW-Wireless-Sender-Receiver-Module-NRF905-SX1212-si4432-SC-/141924675760?hash=item210b5eb0b0:g:tuUAAOSwu1VW3~SY

Zitat von: RaspII am 09 Dezember 2016, 17:53:03
Ich hatte in der Vergangenheit immer wieder Probleme mir den "blauen" CC1101 Modulen. Diese sind bzgl. Frequenz extrem ungenau, deshalb verwende ich diese Module nicht mehr in meinen Projekten.

Zitat von: RaspII am 09 März 2016, 21:12:41
ich hab noch etwas mit dem blauen 433 Mhz Modul geforscht.
Dazu hab ich es bei 433 Mhz in Betrieb genommen, meine 433 Mhz Funksteckdosen kann ich damit auch steuern.
Allerding sehe ich auch hier eine Frequenzabweichung von ca. 120khz, d.h. etwa die hälfte der Abweichung die wir bei 868 Mhz sehen (Soll Frequenz ist 433.920Mhz). Der Handsender (Bild Mitte) sendet auf der korrekten Frequenz)

Ich vermute mal das ist der Quarz, mal schaun ob ich das auch noch messtechnisch klären kann (mal sehen was der China Oszi taugt)
Klar ist nur, dass ich keine weiteren "blauen" Module mehr kaufen werde.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 Dezember 2016, 20:39:17
Hallo Sidey,

da jetzt bald Weihnachten ist, habe ich einen "kleinen" Wunsch. Kannst Du die Routinen für den CC1101 in die Signalduino Firmware einbauen?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Dezember 2016, 07:09:23
Hallo und guten morgen

ja das wäre toll, wenn man den CC1101 in den Signalduino implementieren könne.. und am tollsten wäre es, wenn noch irgendwie ein kleines HowTo fürs Erstellen bzw. Flachen für den Nano mit CC1101 zustande käme... für die wie mich, die sich mit dem Programmieren nicht wirklich auskennen und eine "Ich nahm dich an der Hand und führe dich Schritt für Schritt weiter" Unterstützung brauchen... ;-)

Ich danke euch schon mal...

Ps. der CC1101 ist mit dem nano so zu verkabeln wie mit dem Selbstbaucul oder gibts da unterschiede?

lg
michl
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 14 Dezember 2016, 21:29:44
@ralf

Was mir nicht klar ist, wie das mit dem cc1101 und dem Pegel.

Die IOs vom Arduino arbeiten mit 5V.
Der cc1101 verträgt nur 3,9 V

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 14 Dezember 2016, 21:36:43
Es werden levelshifter benötigt:
https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 18 Dezember 2016, 13:40:22
Hier ist eine erste Version der SIGNALDuino Firmware mit CC1101 unterstützung. Die Verkabelung des CC1101 ist wie beim Selbstbau cul
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101
Es fehlt noch das hex-File zum flashen und das Senden wird auch noch nicht unterstützt.
Ich habe die folgenden Befehle eingebaut. Alle Werte sind in hex
C<reg>
    <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
    Example: C35 -> C35 = 0D

e
    EEPROM / factory reset.  resets all eeprom values without reboot

r<AA>
    Read eeprom  (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
r<AA>n
    Read 16 byte from eeprom (z.B. r00n)

W<AA><DD>
    Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

WS<AA>
   Strobe commands z.B:
   34   Enable RX
   36   Exit RX / TX  (idle state)


Nach dem Schreiben eines Wertes in ein Register, müssen die Änderungen noch aktiviert werden.
Ich hab noch nicht rausgefunden ob dazu die  Strobe commands 36 (idle) und 34 (Enable RX) ausreichen oder ob ein reset notwendig ist.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 18 Dezember 2016, 18:51:50
So generell sollten wir uns vielleicht mal überlegen ob wir die Kommandos in gewisser Weise Standardisieren.

So in der Art:
G für Get
S für Set
Und darunter dann weitere Kommandos

Z.B. G Ram oder G C Reg für Get cc1101 Reg...

Oder wir vergeben hexadezimal Steuerkommandos:

Get 0x00
Bis
Get 0xFF

Uns ebenso Set 0x00 bis 0xFF.

Was meinst Du Ralf?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 18 Dezember 2016, 19:05:23
Bei den Befehlen für den CC1101 habe ich mich an die cul raw Befehle gehalten, dies ist für mich der quasi Standard
http://culfw.de/commandref.html
Ich würde die bestehenden Befehle nicht mehr ändern, dies ergibt nur eine Inkompatibilität zu älteren Versionen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 Dezember 2016, 19:11:20
Hallo Sidey,

Im CC1101 Datenblatt steht, daß der CC1101 im asynchronous serial mode jitter und glitches hat. Sind in der Signalduino Firmware bereits Routinen enthalten die dies berücksichtigen?

ZitatWhen using asynchronous serial mode make sure the interfacing MCU does proper oversampling and that it can handle the jitter on the data output line.
The MCU should tolerate a jitter of ±1/8 of a bit period as the data stream is time-discrete using 8 samples per bit.

In asynchronous serial mode there will be glitches of 37 - 38.5 ns duration (1/XOSC) occurring infrequently and with random periods.
A simple RC filter can be added to the data output line between CC1101 and the MCU to get rid of the 37 - 38.5 ns ns glitches if considered a problem.
The filter 3 dB cut-off frequency needs to be high enough so that the data is not filtered and at the same time low enough to remove the glitch.
As an example, for 2.4 kBaud data rate a 1 kohm resistor and 2.7 nF capacitor can be used. This gives a 3 dB cut-off frequency of 59 kHz.

Gruß Ralf

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Dezember 2016, 19:24:28
Jitter und glitches in der beschrieben Größenordnung sind kein Problem
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 21 Dezember 2016, 23:52:41
Zitat von: Ralf9 am 18 Dezember 2016, 19:05:23
Bei den Befehlen für den CC1101 habe ich mich an die cul raw Befehle gehalten, dies ist für mich der quasi Standard
http://culfw.de/commandref.html
Ich würde die bestehenden Befehle nicht mehr ändern, dies ergibt nur eine Inkompatibilität zu älteren Versionen.

Ich habe noch mal darüber nachgedacht. Man müsste sich an die Befehle ja nur halten, wenn man eine Kompatibilität zur cul Hardware anstrebt.
Das machen wir aber nicht.
Es gibt auch bereits Überschneidungen der Befehle, da ich diese ja mal vom FHEMduino übernommen hatte.

Um das Kompatibilitätsproblem Firmware / Modul zu entschärfen, könnte man die alten Befehle erst dann entfernen, wenn die neuen etwas verbreitet sind.
Für mich ist das aber aktuell nichts dringendes und eher etwas für demnächst mal. Vielleicht fällt uns ja das ein oder andere auch noch dazu ein.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 00:55:40
Zitat von: Ralf9 am 18 Dezember 2016, 13:40:22
Hier ist eine erste Version der SIGNALDuino Firmware mit CC1101 unterstützung. Die Verkabelung des CC1101 ist wie beim Selbstbau cul

C<reg>
    <reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
    Example: C35 -> C35 = 0D
[/quote]

Hi Ralf, der C Befehl ist im Code nicht enthalten.

Ich habe mir jetzt auch einen Nano + cc1101 aufgebaut.
Die Pull-Up Wiederstände habe ich erst mal weggelassen.

Das mit den Registern versehe ich nicht. Keine Idee, was welches Register ist und bedeutet:
[code]
EEPROM 00 : 33 1D 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 1


Auf jeden Fall habe ich zwei Dinge festgestellt

1. Sende ich 2x hintereinander z.B. WS34 dann hängt sich der Arduino auf. Ich nehme an er hängt an dem Aufruf wait_Miso(), welches leider unendlich läuft.

2. Ich habe keine Ahnung, ob was empfangen wird. Zu sehen ist jedenfalls noch nichts der Interrupt auf d2 reagiert also nicht.

3. In Setup musste ich das SPI Init etwas vorverlegen. Sonst hängt sich das System schon beim starten auf.

Was funktioniert denn bei dir aktuell schon?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 02:25:16
Bei mir funktionieren alle Befehle die ich eingebaut habe. z.B.
C99
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71  ccreg 10: 57 C4 30 23 B9 00 07 00 18 14 6C 07 00 90 87 6B  ccreg 20: F8 56 11 EF 2A 19 1F 41 00 59 7F 3F 88 31 0B
C35
C35 = 01
WS34
cmdStrobeReg 34
C35
C35 = 0D
MS;P1=547;P2=-9047;P3=-2097;P4=-4120;D=1213141414131313141313131413131313141314131314131313141414131313131414141413;CP=1;SP=2;O;


MIt C35 wird das MARCSTATE Register ausgelesen:
0x35 (0xF5): MARCSTATE – Main Radio Control State Machine State
01 - IDLE
0D - RX


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 09:28:25
Zitat von: Sidey am 23 Dezember 2016, 00:55:40
1. Sende ich 2x hintereinander z.B. WS34 dann hängt sich der Arduino auf. Ich nehme an er hängt an dem Aufruf wait_Miso(), welches leider unendlich läuft.

Wenn bei Dir der MISO nicht auf low geht, dann stimmt was nicht
ZitatA command strobe may be followed byother SPI access without pulling CSn high.
However, if an SRES strobe is being issued, one will have to wait for SO to go low again
before the next header byte can be issuedshown in Figure 16. The command strobesexecuted immediately, with the exceptionthe SPWD, SWOR, and the SXOFF strobes, which are executed when CSn goes high.

Nachtrag:
10 4-wire Serial Configuration and Data Interface
ZitatWhen CSn is pulled low, the MCU must wait
until CC1101 SO pin goes low before starting transfer the header byte. This indicates the crystal is running. Unless the chip wasthe SLEEP or XOFF states, the SO pinalways go low immediately after taking CSn low.


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 09:50:45


Zitat von: Ralf9 am 23 Dezember 2016, 09:28:25
Wenn bei Dir der MISO nicht auf low geht, dann stimmt was nicht
Nachtrag:
10 4-wire Serial Configuration and Data Interface

Gruß Ralf

Ja, prinzipiell habe ich mir das auch gedacht, aber keine Idee was es sein könnte. Beim Initialisieren scheint es ja auch zu klappen.

Die Endlosschleife ist halt nicht so gut.
Es gibt ja auch eine SPI Lib von Arduino. Ob die auch unendlich wartet weiss ich nicht.

Was die C Kommandos angeht, habe ich im Quellcode die Stelle nicht gefunden, an der die behandelt werden.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 10:19:00
Zitat von: Sidey am 23 Dezember 2016, 09:50:45
Was die C Kommandos angeht, habe ich im Quellcode die Stelle nicht gefunden, an der die behandelt werden.

https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/RF_Receiver/RF_Receiver.ino
Zeile 617

Mit den beiden Dateien in der Anlage funktioniert es bei mir
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 11:29:55
Zitat von: Sidey am 23 Dezember 2016, 09:50:45
Ja, prinzipiell habe ich mir das auch gedacht, aber keine Idee was es sein könnte. Beim Initialisieren scheint es ja auch zu klappen.
Die Endlosschleife ist halt nicht so gut.

Es funktioniert wahrscheinlich auch ohne das wait_Miso
Das wait_Miso() habe ich aus der AskSin Library. In der a-culfw habe ich das wait_Miso nicht gefunden.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 11:56:21
Ich hab da gestern noch eine Lib gefunden für den cc1101.  Irgendwie asksin auf Github suchen... Vielleicht nimmt man einfach die und gut ist?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 12:31:09
Die cc1101 Routinen habe ich größtenteils aus der askin lib.
Du kannst mal die a-culfw flashen um zu testen ob Deine Hardware funktioniert. Der Empfang wird mit X21 aktiviert.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 22:53:05
Hi Ralf,

ich habe das mit dem hängen Bleiben jetzt im Griff.
War doch eher ein Problem in der Reihenfolge der Pin Initialisierung...

Auf C99 kommt Folgendesm nachdem ich meinen Versuchsaufbau wieder repariert habe. Meine Tochter war da wohl dran und hat diesen optimiert:

ccreg 00: 29 2E 3F 07 D3 91 FF 04 45 00 00 0F 00 1E C4 EC  ccreg 10: 8C 22 02 22 F8 47 07 30 04 76 6C 03 40 91 87 6B  ccreg 20: F8 56 10 A9 0A 20 0D 41 00 59 7F 3F 88 31 0B




Wie setze ich jetzt aber die richtigen Werte und woher kenne ich die?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 23:04:47
Es könnte auch ein Hardwareproblem sein. Hast Du die Verkabelung nochmals überprüft, insbesondere des Miso?
Funktioniert das wait_Miso jetzt?

Was ergibt ein C35?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 23:06:28
Hi Ralf,

ja hab die Verkabelung korrigiert, jetzt geht es.
Nur wie setze ich jetzt die richtigen Register?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 23:14:34
Die register sollten normalerweise automatisch richtig gesetzt werden.

initEEPROM() macht beim ersten starten einen Factory reset. Der Factory reset kopiert die richtigen registerwerte ins EEPROM.
Mit CCinit wird dann der CC1101 mit den Werten vom EEPROM initialisiert

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2016, 23:44:09
Okay,  bei mir wird aber nicht das identische wie bei dir ausgegeben...

An Folgendem Beispiel kann ich den Unterschied erklären:

0x0D, // 00 IOCFG2    29     GDO2 as serial output


Bei dir wurde 0d bei mir 29 ausgegeben.
Muss ich das jetzt verstehen?

Was das Problem mit der Ausgabe von Signalen angeht habe ich den Fehler ausfindig gemacht.
Da mir der Kram dauernd abgeschmiert ist, habe ich doch CCinit auskommentiert.

Seit dem stimmen auch die Ausgaben der Register mit deinen überein und es werden fleissig Daten empfangen.
Ich denke ich habe auch eine Idee, wann wir den RSSI Wert abrufen. Mich würde aber interessieren, wie das geht...

Grüße Sidey

Jetzt gehts.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Dezember 2016, 23:54:32
Mit C34 kannst Du den RSSI auslesen. Du müsstest also während die Nachricht in den FIFO eingelesen wird, das Register 0x34 auslesen.

Mach mal ein "r00n" und "C99"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 Dezember 2016, 00:43:33
gut, ich habe RSSI Auslesen eingebaut und es in dbm umgerechnet.

Man müsste den RSSI Wert alternativ wohl auch am Ende der Übertragung im RX Buffer anhängen und auslesen können.
Wie wir den RSSI Wert nun weiter verarbeiten weiss ich noch nicht.
Mit der aktuellen Implementierung wird er auch sehr oft vom cc1101 abgefragt. Ob da so gut ist.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 24 Dezember 2016, 00:57:35
Ja, der RSSI Wert müsste dann am Ende der raw Nachricht angehängt werden z.B.
..CP=1;SP=2;R=-73;
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Dezember 2016, 16:15:46
Hi Ralf,

Weisst Du, ob die Data rate, auch im asynchron Modus eine Auswirkung hat?

Vielleicht ich die ja für den einen Temp Sensor zu niedrig eingestellt?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Dezember 2016, 19:38:02
Zitat von: Sidey am 25 Dezember 2016, 16:15:46
Weisst Du, ob die Data rate, auch im asynchron Modus eine Auswirkung hat?

Vielleicht ich die ja für den einen Temp Sensor zu niedrig eingestellt?

Ich habe das hier gefunden, kannst Du damit was anfangen?
https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/t/67311

weihnachtliche Grüße von Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Dezember 2016, 21:51:45
Hi Ralf,

Ich werte das mal als klares Ja.

Wenn ich mich jetzt nicht total verrechnet habe ist der cc1101 auf 56kbaud eingestellt.

Nicht schlecht, aber vielleicht nicht hoch genug?

mdmcfg3 ist auf 196 (0xc4) gesetzt. Du kannst es ja mal zum Testen etwas höher setzen.

Frohe Weihnachten und Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Dezember 2016, 22:06:55
nach dieser Rechnung ist er momentan auf 5,6 kbaud eingestellt, ist dies evtl zu wenig?
0xC4, // 11 MDMCFG3 (x)   DataRate: 5603,79 Baud ((256+196)*2^7)*26000000/(2^28)

Macht es Sinn, das get ccconf zu erweitern, daß auch die DataRate angezeigt wird?
z.B.
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  DataRate: 5603,79 Baud
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Dezember 2016, 22:14:27
Ich tippe mal auf ja, das ist wenig
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Dezember 2016, 23:48:11
ich habe die DataRate mal auf 25341.03Baud erhöht, hat keine Verbesserung gebracht. Bei einer DataRate größer 100kbaud wurden keine Nachrichten mehr empfangen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 26 Dezember 2016, 01:17:16
Seltsam, das wundert mich, dass das Empfangen bei einer zu hohen Abtastrate nicht geht.


Ich habe die cc1101 Firmware inklusive ein paar Debug Meldungen beim Initialisieren mit in das FHEM Repo gepackt

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


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 Dezember 2016, 01:16:58
Zitat von: Ralf9 am 25 Dezember 2016, 22:06:55
nach dieser Rechnung ist er momentan auf 5,6 kbaud eingestellt, ist dies evtl zu wenig?
0xC4, // 11 MDMCFG3 (x)   DataRate: 5603,79 Baud ((256+196)*2^7)*26000000/(2^28)

Ich habe mal auf 76 KBaud gestellt, ich empfange noch gut, und die Werte stimmen meiner Meinung nach nun besser mit denen des RXB6 überein:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71  ccreg 10: 58 34 30 23 B9 00 07 00 18 14 6C 07 00 90 87 6B  ccreg 20: F8 56 11 EF 2C 15 1F 41 00 59 7F 3F 88 31 0B


Ich habe Datarate_M  auf 0x34 / 52 gesetzt und Datarate_E  auf 8

WS1334
WS1258


Gehe ich auf 115Kbaud, dann wird mein RSSI Wert sehr niedrig.

Zitat von: Ralf9 am 25 Dezember 2016, 22:06:55
Macht es Sinn, das get ccconf zu erweitern, daß auch die DataRate angezeigt wird?
z.B.
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  DataRate: 5603,79 Baud
Ja, warum nicht get config erweitern und einfach nach dem Key=Value Prinzip wie schon MS=X;MU=Y; usw erweitern.
FRE=433,920Mhz;BW=328KHz;AMP=42;ses=4;DR=56K; 

Was auch sein könnte, ist dass der EAS800 nicht auf 433,920 Mhz sendet und er deshalb nicht empfangen wird.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Dezember 2016, 10:59:16
mit Deiner letzten Änderung funktioniert nun auch das RSSI

ca 1-2m Entfernung:
2016.12.27 10:21:13.426 4 : sduinoE/msg READ: MS;P2=477;P4=-1959;P5=-3916;P6=-9198;D=26242524252425242424252425242524252424242425252425242524242424252424252524;CP=2;SP=6;R=48;O;
2016.12.27 10:21:13.427 4 : sduinoE: Decoded MS Protocol id 0 dmsg s54550D426000 length 40 RSSI = -50


ca 5-10m Entfernung
2016.12.27 10:21:39.784 4 : sduinoE/msg READ: MS;P0=-1956;P3=492;P6=-3894;P7=-9204;D=37303630363636303030303630303630363030303036363036303636363030363036303030;CP=3;SP=7;R=27;O;
2016.12.27 10:21:39.785 4 : sduinoE: Decoded MS Protocol id 0 dmsg s5C250D728000 length 40 RSSI = -60.5


ein Stockwerk drüber
2016.12.27 10:33:32.734 4 : sduinoE/msg READ: MS;P0=541;P1=-9034;P2=-2102;P3=-4140;D=0102030303020202030202020302020202030203020302020202030303020202030202020302;CP=0;SP=1;R=4;O;
2016.12.27 10:33:32.734 4 : sduinoE: Decoded MS Protocol id 0 dmsg s7110A8711000 length 40 RSSI = -72

2016.12.27 10:35:42.744 4 : sduinoE/msg READ: MS;P2=592;P3=-2088;P4=-8928;P5=-4119;D=2423252523252523232323232323232323252325232523252525232323232525252523252325;CP=2;SP=4;R=244;
2016.12.27 10:35:42.744 4 : sduinoE: Decoded MS Protocol id 0 dmsg s6C00AB87A800 length 40 RSSI = -80


ich habe die DataRate mit in das get ccconf eingebaut
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

Nachtrag:
nachdem ich in der signaldecoder.cpp bei einigen "#endif" das ; entfernt und die 31 durch 15 ersetzt hatte, konnte ich es mit der Arduino IDE fehlerfrei compielieren.

Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Dezember 2016, 19:14:51
Zitat von: Sidey am 27 Dezember 2016, 01:16:58
Was auch sein könnte, ist dass der EAS800 nicht auf 433,920 Mhz sendet und er deshalb nicht empfangen wird.

Ich habe mal die bWidth erhöht, nun empfange ich einen von meinen zwei EAS800
ccconf: freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Aber gegen den RXB6 mit einer selbstgebastelten Groundantenne hat der CC1101 keine Change, damit empfange ich auch einen Sensor vom Nachbar.

Weiß zufällig jemand was der RXB6 für eine Bandbreite hat?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 27 Dezember 2016, 20:49:02
Hallo Ralf,
kann Dir den Sachverhalt mit einem Screenshot des SDR# vielleicht verdeutlichen.
Der markierte Bereich um die SollFrequenz ist eine 32KHz Bandbreite (+/- 16 KHz),
also Faktor 10 kleiner als der CC1101!
Es zeigt zwar den Sendebetrieb bei IT,
Gleiches gilt aber mit Sicherheit übertragbar auch für den Empfang.

Die 433MHz-Sensoren liegen nicht immer auf der aufgedruckten Frequenz.
Die Fernbedienungs-Sender streuen deshalb in einem weiten Bereich, um auch jeden Abweichling zu erwischen,
also über eine "riesen" Bandbreite.

Ganz im Gegenteil der CC1101, er sendet je nach Abweichung des Quarzes und der Anpassung
mehr oder weniger eng um die Frequenzvorgabe. Liegen die Empfänger/Sender  "daneben"
funktioniert es nicht oder nur schlecht.

Deshalb muss man meist "nachhelfen". Die Power nach oben "drehen",
da sie standardmäßig im Mittelbereich angesiedelt  ist (was Störungstechnisch gesehen auch Sinn macht)
oder besser die "richtige" Mittenfrequenz suchen (SDR#).

ZitatHier nochmal der Hinweis, wo man mit solchen Modulen senden darf:
433.05 bis 434.79MHz.
Quelle (https://www.mikrocontroller.net/topic/65984?page=single#539679)

Grüße + Lob für das tolle Projekt!
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 Dezember 2016, 21:27:51
Ich habe zur Bandbreite folgendes gefunden:

Frequency tolerance of output: ±75KHz


Ob es stimmt, weiss ich nicht.


Grüße Sidsy
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 27 Dezember 2016, 21:46:50
Oder 433mhz-superheterodyne-3400-rf-link-kit (https://www.geeetech.com/433mhz-superheterodyne-3400-rf-link-kits-p-167.html):
oder hier https://forum.fhem.de/index.php/topic,17196.msg198580.html#msg198580 (https://forum.fhem.de/index.php/topic,17196.msg198580.html#msg198580)

TX Technical Specifications:
1.Working voltage: 3V~12V
2.Working current: max40mA (12V), min9mA(3V)
3.Resonance mode: sound wave resonance (SAW)
4.Modulation mode: ASK /OOK
5.Working frequency: 315MHz-433.92MHz, customized frequency is available.
6.Transmission power: 25mW (315MHz at 12V)
7.Frequency error: +150kHz (max)
8.Velocity: 10Kbps
9.Self-owned codes: negative
10.Aerial Length: 24cm (315MHz), 18cm(433.92MHz)




RX Technical Specifications:
1.Working voltage: 5.0VDC +0.5V
2.Working current:2.5mA (5.0VDC)
3.Working principle: superheterodyne
4.Working method: OOK/ASK
5.Operating frequency: 315MHz, 433.92MHz, customized frequency is available;
6.Bandwidth: 2MHz (315MHz, having result from testing at lowing the sensitivity 3dBm)
7.Sensitivity: excel -105dBm (50)
8.Velocity:
9.Output signal: TTL electric level signal entire transmit
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Dezember 2016, 23:14:35
ich finde es etwas seltsam, warum nur ich mit dem CC1101 Probleme mit dem empfangen der EAS800z Temperatursensoren habe. Da es die EAS800z damals recht günstig im Ausverkauf gab, müssten eigentlich recht viel mit dem cul als Empfänger inbetrieb sein. Mir sind keine Fälle bekannt wo zum Empfangen die Bandbreite hochgesetzt werden musste.
Habe ich evtl ein CC1101 Modul mit einem ungenauen Quarz erwischt?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 28 Dezember 2016, 11:12:18
Hallo Ralf,
scheint mir eher kein Bandbreitenproblem zu sein.

Wie sieht es mit dem RSSI aus > 100?
Batteriezustand? Platzierung? Antenne (Unterschiede ASK + FSK) (https://www.mikrocontroller.net/articles/433_MHz_Funk%C3%BCbertragung)?

ZitatQuarter-wave or monopole antennas require an associated ground plane
counterpoise for proper operation. The size and location of the ground
plane relative to the antenna will affect the overall performance of the
antenna in the final design. When used in conjunction with a ground
plane smaller than that used to tune the antenna, the center frequency
typically will shift higher in frequency and the bandwidth will decrease. 
The proximity of other circuit elements and packaging near the antenna
will also affect the final performance.
Quelle (https://www.linxtechnologies.com/resources/data-guides/ant-433-sp.pdf) (Splatch Planar Antenne)

Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 28 Dezember 2016, 16:27:45
Hallo Ralf,

um mein Verständnis der Signalduino SW und des CC1101 aufzufrischen,
habe ich mir erlaubt, Deinen Code etwas "aufzuräumen" und minimal erweitert.

Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:
RF_Receiver:165: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&cc1101::getRSSI); // Provide the RSSI Callback
                 ^
RF_Receiver:167: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&rssiCallback);        // Provide the RSSI Callback

RF_Receiver:973: error: 'stackptr' was not declared in this scope
  stackptr = (uint8_t *)malloc(4);          // use stackptr temporarily
  ^
RF_Receiver:974: error: 'heapptr' was not declared in this scope
  heapptr = stackptr;                     // save value of heap pointer
  ^
RF_Receiver:985: error: '__brkval' was not declared in this scope

  if((int)__brkval == 0)

          ^
RF_Receiver:986: error: '__bss_end' was not declared in this scope
     free_memory = ((int)&free_memory) - ((int)&__bss_end);

                                                ^


<edit>
Zitat#else
    extern int __heap_start, *__brkval;
*__brkval; ist extern void, nicht int.
</edit>

und dieser hier :
Zitat'class SignalDetectorClass' has no member named 'setRSSICallback'

und komme deshalb nicht weiter.

2. Frage:
#ifdef CMP_FIFO
  #include "SimpleFIFO.h"
  SimpleFIFO<int,FIFO_LENGTH> FiFo; //store FIFO_LENGTH # ints
#else
  // TODO klaeren!
  #include <filtering.h> //for FiFo Buffer
  RingBuffer FiFo(FIFO_LENGTH, 0); // FiFo Puffer
#endif


Weiß jemand woher die "filtering.h" kommt?

Gibt es noch Änderungen?

Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 28 Dezember 2016, 18:10:28
Zitat von: juergs am 28 Dezember 2016, 16:27:45
Hallo Ralf,

um mein Verständnis der Signalduino SW und des CC1101 aufzufrischen,
habe ich mir erlaubt, Deinen Code etwas "aufzuräumen" und minimal erweitert.

Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:

Der Signalduino Code ist von Sidey ich habe nur den CC1101 Code ergänzt.
Sidey hat auch das FastDelegate.h für das rssi callback eingebaut. Wenn ich das richtig sehe, verwendest Du noch eine ältere signalDecoder.h und signalDecoder.cpp wo das FastDelegate fehlt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 28 Dezember 2016, 18:23:56
Zitat von: juergs am 28 Dezember 2016, 11:12:18
scheint mir eher kein Bandbreitenproblem zu sein.

Wie sieht es mit dem RSSI aus > 100?
Batteriezustand? Platzierung?

Als Antenne habe ich die 5cm Antenn die dabei war verwendet. Ich habe es auch mit der
"Delock ISM 433 MHz Antenne SMA 2,5 dBi omnidirektional # 88914" versucht.
Mit der Default Bandbreite hat es auch nicht funktioniert, wenn der CC1101 und die EAS800z im selben Raum waren. Ein EAS800z hat volle Batterien und der andere low Bat

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 Dezember 2016, 23:32:01
Zitat von: juergs am 28 Dezember 2016, 16:27:45
Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Ich denke, in der Arduino IDE gibt es leider auch keine Alternative dazu.

Zitat von: juergs am 28 Dezember 2016, 16:27:45

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:
RF_Receiver:165: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&cc1101::getRSSI); // Provide the RSSI Callback
 


Du hast nicht die aktuelle Lib aus github. Ich habe setrssiCallback vor 2 Tagen eingebaut.

Zitat von: juergs am 28 Dezember 2016, 16:27:45
<edit>  *__brkval; ist extern void, nicht int.</edit>

Das muss ich mir noch mal ansehen, bei mir compiliert der Teil für freememory .

Zitat von: juergs am 28 Dezember 2016, 16:27:45
Weiß jemand woher die "filtering.h" kommt?

Ja, das habe ich mit meinem Bruder vor einiger Zeit mal erstellt. In den Ersten Versionen des SIGNALduino habe ich die Lib für den FIFO verwendet. Die Lib war aber zu mächtig, deshalb bin ich dann irgendwann mal auf SimpleFifo umgestiegen.
filterhing.h ist wird in der aktuellen Version aber nicht mehr eingebunden. Welche Version von RF_Receiver hast Du?

Grüße Sidey
[/code]
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 29 Dezember 2016, 16:16:59
Hallo Sidey,
merci für die Infos.

habe beide repositories heruntergeladen:
1.)  https://github.com/RFD-FHEM/RFFHEM (https://github.com/RFD-FHEM/RFFHEM)
2.)  https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101 (https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101) (Branch von Ralf9)

Das sollten die aktuellen sein?

Hintergrund, wollte die Problematik mit dem CC1101 und Ralf Problem bei mir mal begutachten.
Nebenbei fällt dann noch etwas Verständnis für die Implementierung für FHEM dabei ab.  :)

Da ich diese Sensoren https://forum.fhem.de/index.php/topic,36104.msg543191.html#msg543191 (https://forum.fhem.de/index.php/topic,36104.msg543191.html#msg543191)
hier gerne integrieren möchte.

Die oben erwähnten Probleme konnte ich bis auf die fehlende RSSI-Implementierung selbst lösen.
Allerdings mach noch der Signaldecoder Warnings, Compile geht aber durch:
Zitat
signalDecoder.cpp:366:7: warning: extra tokens at end of #endif directive  -> beseitigt.
signalDecoder.cpp: In member function 'int8_t SignalDetectorClass::findpatt(int)':signalDecoder.cpp:165:62
signalDecoder.cpp: In member function 'int8_t SignalDetectorClass::findpatt(int)' :signalDecoder.cpp:576:31
signalDecoder.cpp: In member function 'void SignalDetectorClass::compress_pattern()' ::signalDecoder.cpp:165:62: warning: right shift count >= width of type

C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_602412\sketch\signalDecoder.cpp:576:31: warning: right shift count >= width of type

   if ((val ^ pattern[idx]) >> 31)

                               ^

Die Hilfsfunktionen habe ich so gelöst:


///-----------------------------------------------------------------------
*** extern int __bss_end;   ***
*** extern int *__brkval;    ***

//--- diese Deklaration hatte define-abhängig gefehlt:
uint8_t * heapptr, * stackptr;

void check_mem() {
  stackptr = (uint8_t *)malloc(4);          // use stackptr temporarily
  heapptr = stackptr;                     // save value of heap pointer
  free(stackptr);      // free up the memory again (sets stackptr to 0)
  stackptr =  (uint8_t *)(SP);           // save value of stack pointer
}

Gilt für nicht gesetztes "CMP_MEMDBG"-Define.

Die FastIO-Makros habe ich gefunden und eingebunden.

Sorry, muss mich in Git noch etwas einarbeiten ...  :'(

Hättest Du mir bitte ein Hinweis auf die neueren Versionen?

Hier https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101 (https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101) ?

Grüße,
Jürgen

/EDIT:
Geht schon mal:
ZitatUsing sFIFO
Reading values fom eeprom
CCInit
CCVersion=20
CCPartnum=0
Starting timerjob
receiver enabled
V 3.3.1-dev SIGNALduino cc1101 - compiled at Dec 29 2016 17:11:22


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 Dezember 2016, 21:57:54
Ich habe mir mal Gedanken gemacht was alles beim CC1101 noch benötigt wird.
Wenn ein 868 MHz CC1101 verwendet wird, sollte er etwas anders (Frequenz und PATABLE) initialisiert werden.
Ich habe irgendwo gelesen, daß es beim CUL einen Jumper für (433/868 MHz) gibt.
Oder gibt es noch eine andere Möglichkeit damit die Firmware beim Factory Reset weiß ob sie die Werte für 433 oder 868 verwenden soll.

Ich hab mir auch mal überlegt wie man das mit dem senden machen könnte.
Ich denke es wäre sinnvoll, wenn man beim Senden die Frequenz ändern könnte, dazu müsste man "set sduino raw" (z.B. mit F=<F1><F2><F3>)
und "set sduino sendMsg" (z.B. mit #F<F1><F2><F3>) erweitern. Wobei F1-F3 die Werte für Register 0D-0F sind.

Ein senden könnte dann z.B. so aussehen:

- command strobe 0x36 SIDLE
- Register  0D-0F auslesen und merken
- Register  0D-0F mit den übergebenen Werten beschreiben
- command strobe 0x35 STX
- senden
- command strobe 0x36 SIDLE
- Register  0D-0F mit den vorher gemerkten Werten beschreiben
- command strobe 0x34 SRX


Es dürfte auch sinnvoll sein beim Befehl C3E (CC1100_PATABLE) alle 8 Werte zurückzugeben.

Mit ist noch nicht klar was beim Befehl x (set PATABLE) der Defaultwert ist

Zitatx<pp> Change the (EEPROM) PA tables (power amplification for RF sending)

    <pp> is a one-byte hex value, valid values are 00 to 09, with following values: the first 5 is -10/-5/0/5/10 dBm with PA ramping, the next 5 is the same without PA ramping. If the value is outside this spec, then the 5dBm variant (03) will be used.


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 29 Dezember 2016, 22:22:09
Hallo Ralf,

inder aculfw gibt es 2 Varianten die Frequenz einzustellen.

1. per SW in der 328P nanoCUL-Variante
/* define this device as a 433 MHz one */
/* this isn't done like a CUL by reading a port pin but instead a fixed value of 0 for mark433_pin is used */
#define MULTI_FREQ_DEVICE
#define MARK433_PIN mark433_pin
#define MARK433_BIT             0
extern const uint8_t mark433_pin;


2. per Port-Pin in der 32U4 CUL-Variante
#define MARK433_PORT            PORTB
#define MARK433_PIN             PINB
#define MARK433_BIT             6
#define MARK915_PORT            PORTB
#define MARK915_PIN             PINB
#define MARK915_BIT             5



Zitat
0x57, // 10 MDMCFG4   8C     bWidth 325kHz
0xC4, // 11 MDMCFG3   22     DataRate
0xb9, // 14 MDMCFG0   F8     ChannelSpace: 350kHz

Zitat
0x57, // 10 MDMCFG4  *8C    55    bWidth 325kHz
0xC4, // 11 MDMCFG3 (x)   DataRate: 5603,79 Baud ((256+196)*2^7)*26000000/(2^28)

Die Datenrate scheint bei ASK relevant zu sein, 0xC4 für MDMCFG3 scheint entgegen dem Kommentar auf Bitrate von 1400.95 BAUD zu setzen.
Channelspace MDMCFG0 = B9  => 174.957275 KBAUD
Die aculfw gibt da Aufschluss zur Berechnung. D.h. man müsste mal das InputSignal/Periodendauer nach der Datenrate-Vorgabe überprüfen...


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Dezember 2016, 23:00:47
Also ich würde nicht so viel in die Firmware implementieren.

Meines Erachtens, kann man die komplette Register Information über die serielle Schnittstelle auf den UC und dann auf den CC1101 übertragen.
Da müsste nichts in die Firmware zwingend rein. Dort nimmt es nur platz weg, den wir vielleicht noch brauchen.. z.B. für die Ethernet Variante.

Sobald es einmal im EEProm ist, läuft das Gerät auch ohne FHEM und der normale Ablauf ist ja in etwa so:

Hardware zusammenbauen
Per USB an den FHEM Server anbinden
Firmware Flashen

Für die Ethernet Variante stelle ich mir auch vor, dass man die nach dem Flashen konfiguriert.
Das sollte für die CC1101 Variante doch auch kein Problem sein.

Je nach Verwendungswzeck kann man dann die passenden Register im FHEM Modul hinterlegen.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Dezember 2016, 00:27:42
Hallo Sidey,

demnach ist es für Dich kein Problem für den CC1101 vier hex Files zu erstellen (nanoCC1101_433, nanoCC1101_868, prominiCC1101_433, prominiCC1101_868).

Die 29 Registerwerte für den FactoryReset würde ich gerne in der Firmware behalten.
Bei der PATABLE können wir es so machen, daß sie im Signalduino Modul hinterlegt wird. Beim x-Befehl werden dann anstatt 1 Byte die 8 Byte der PATABLE übergeben.

Zum Platz sparen müssten eigentlich die ganzen IT-Befehle raus können, da sie nicht mehr benötigt werden.

Eine Alternative zur Ethernet Variante ist das USR-TCP232-T2 Tiny Serial Ethernet Converter Module.
Ich denke die Ethernet Variante macht nur Sinn, wenn damit mehr möglich ist als mit dem USR-TCP232-T2
z.B. Betrieb über Port 1000 und Debug Ausgabe über Port 23. Bringt die höhere Übertragungsrate als 57600 der Ethernet Variante Vorteile?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 Dezember 2016, 01:04:06
Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
demnach ist es für Dich kein Problem für den CC1101 vier hex Files zu erstellen (nanoCC1101_433, nanoCC1101_868, prominiCC1101_433, prominiCC1101_868).
Eher eine Fleißarbeit. Aber wofür brauchen wir unterschiedliche firmware für 868 und 433 Mhz?


Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Die 29 Registerwerte für den FactoryReset würde ich gerne in der Firmware behalten.

Warum? Wenn wir das für alle Varianten machen, dann bläht sich das ja unweigerlich auf. Im Moment 433 und 868 Mhz, aber für andere Variationen (ich weiss jetzt nicht welche) würde sich das ja noch erweitern.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Bei der PATABLE können wir es so machen, daß sie im Signalduino Modul hinterlegt wird. Beim x-Befehl werden dann anstatt 1 Byte die 8 Byte der PATABLE übergeben.

Ich kenne Unterschied zwischen PATable und Register leider noch nicht.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Zum Platz sparen müssten eigentlich die ganzen IT-Befehle raus können, da sie nicht mehr benötigt werden.
Ja, die können raus.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Eine Alternative zur Ethernet Variante ist das USR-TCP232-T2 Tiny Serial Ethernet Converter Module.
Ich denke die Ethernet Variante macht nur Sinn, wenn damit mehr möglich ist als mit dem USR-TCP232-T2
z.B. Betrieb über Port 1000 und Debug Ausgabe über Port 23. Bringt die höhere Übertragungsrate als 57600 der Ethernet Variante Vorteile?
Könnte man machen. Debug Ausgaben würde ich ja aber nur seriell ausgeben.
Die Geschwindigkeit hängt meines Erachtens am SPI Bus, was der kann weiss ich aktuell nicht. Für einen Arduino Uno ist halt das Ethernet Shield ganz nett, draufstecken geht. Auf dem ESP8266 habe ich ja auch schon ein wenig experimentiert. Da schien mir aber der Empfang durch die 3,3v eher schlecht.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Dezember 2016, 01:33:07
Eine Möglichkeit wäre, nur 2 Varianten mit 433 MHz, nanoCC1101 und prominiCC1101.
Es wäre dann in der 00_Signalduino.pm ein Attribut CC1101_Frequenz notwendig.
Wenn bei der Initialisierung die Antwort des V-Befehls die Version CC1101 enthält und das Attribut CC1101_Frequenz existiert, dann könnte per W-Befehle die Frequenz geändert werden.

Für das Empfangen der OOK-Signale müsste eigentlich eine Variante reichen. Falls Du z.B. auch FM-Signale empfangen willst, dann müssten die dazu notwendigen Änderungen per W-Befehl ins EEPROM und Register geschrieben werden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 30 Dezember 2016, 07:33:26
ZitatIch kenne Unterschied zwischen PATable und Register leider noch nicht.

Mit PATable = Tabelle kann ein Power-Amplifier-Ramping durchgeführt werden.
Das Ramping wäre für FS20 (SlowRF) möglich, ist aber nicht implementiert.
So dass für die Verstärkung (PA) beim senden nur Einzelwerte berücksichtigt werden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Dezember 2016, 12:07:23
Ich habe das dev-r33_cc1101 etwas angepasst, damit das compilieren mit der Arduino IDE einfacher ist
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101

Dazu müssen die folgenden Dateien in das Sketch-Verzeichnis kopiert werden
bitstore.h
cc1101.h
FastDelegate.h
output.h
RF_Receiver.ino
signalDecoder.cpp
signalDecoder.h
SimpleFIFO.h


Die TimerOne Lib habe ich ins libraries Verzeichnis kopiert
https://github.com/PaulStoffregen/TimerOne

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 Dezember 2016, 12:19:56
Man könne vielleicht ein kleines Script erstellen, welches die Dateien mittels link im Hauptverzeichnis verfügbar macht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 30 Dezember 2016, 12:20:25
Hallo Ralf,

danke. Bin mittlerweile doch auf VisualMicro umgestiegen.

Aber in https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp (https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp)
fehlt immer noch die Methode setRSSICallback

Gilt das auch für Linux?
Erstellt eine symbolische Verknüpfung.

MKLINK [[/D] | [/H] | [/J]] Verknüpfung Ziel

        /D           Erstellt eine symbolische Verknüpfung für ein Verzeichis.
                     Standardmäßig wird eine symbolische Verknüpfung für
                     eine Datei erstellt.
        /H           Erstellt eine feste Verknüpfung anstelle einer
                     symbolischen Verknüpfung.
        /J           Erstellt eine Verzeichnisverbindung.
        Verknüpfung  Gibt den Namen für die symbolischen Verknüpfung an.
        Ziel         Gibt den Pfad (relativ oder absolut) an, auf den die
                     neue Verknüpfung verweist.


oder ein make?

Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 Dezember 2016, 12:57:04
Das ist richtig, ich habe die Funktion in der Signaldecoder.h definiert....
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 30 Dezember 2016, 13:08:25
Jetzetle, sorry hab ich übersehen ...  :-[

Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Dezember 2016, 21:02:15
Ich habe nun auch das Schreiben und Lesen der PATABLE eingebaut.
Wenn man mit WS35 den Sender einschaltet, funktioniert das Senden schon.

Ich habe in der zweiten Nachricht eine kleine Dukumentation geschrieben
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 Dezember 2016, 21:34:22
Hi Ralf,

danke für deinen Einsatz.

Was müssen wir denn noch machen, damit das Senden funktioniert?
Das Register fürs Senden setzen und dann den SENDPin wie bisher auf an / aus stellen?

Grüße Sidey

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Dezember 2016, 23:25:20
Vor dem Senden muß von RX auf TX gewechselt werden.
Erst nach SIDLE (0x36)
dann kurz warten
und dann nach TX (0x35)

Das senden funktioniert wie seither mit dem sendpin

nach dem senden
nach SIDLE (0x36) evtl reicht auch  SFSTXON (0x31),
dann kurz warten
und dann nach RX (0x34)

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 31 Dezember 2016, 09:13:55
Zitat von: juergs am 30 Dezember 2016, 12:20:25
Hallo Ralf,

danke. Bin mittlerweile doch auf VisualMicro umgestiegen.

Aber in https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp (https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp)
fehlt immer noch die Methode setRSSICallback

Gilt das auch für Linux?
Erstellt eine symbolische Verknüpfung.

MKLINK [[/D] | [/H] | [/J]] Verknüpfung Ziel

        /D           Erstellt eine symbolische Verknüpfung für ein Verzeichis.
                     Standardmäßig wird eine symbolische Verknüpfung für
                     eine Datei erstellt.
        /H           Erstellt eine feste Verknüpfung anstelle einer
                     symbolischen Verknüpfung.
        /J           Erstellt eine Verzeichnisverbindung.
        Verknüpfung  Gibt den Namen für die symbolischen Verknüpfung an.
        Ziel         Gibt den Pfad (relativ oder absolut) an, auf den die
                     neue Verknüpfung verweist.


oder ein make?

Jürgen

Hi

unter Linux gibts das schon immer:
Usage: ln [OPTION]... [-T] TARGET LINK_NAME   (1st form)
  or:  ln [OPTION]... TARGET                  (2nd form)
  or:  ln [OPTION]... TARGET... DIRECTORY     (3rd form)
  or:  ln [OPTION]... -t DIRECTORY TARGET...  (4th form)
In the 1st form, create a link to TARGET with the name LINK_NAME.
In the 2nd form, create a link to TARGET in the current directory.
In the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
Create hard links by default, symbolic links with --symbolic.
By default, each destination (name of new link) should not already exist.
When creating hard links, each TARGET must exist.  Symbolic links
can hold arbitrary text; if later resolved, a relative link is
interpreted in relation to its parent directory.

Mandatory arguments to long options are mandatory for short options too.
      --backup[=CONTROL]      make a backup of each existing destination file
  -b                          like --backup but does not accept an argument
  -d, -F, --directory         allow the superuser to attempt to hard link
                                directories (note: will probably fail due to
                                system restrictions, even for the superuser)
  -f, --force                 remove existing destination files
  -i, --interactive           prompt whether to remove destinations
  -L, --logical               dereference TARGETs that are symbolic links
  -n, --no-dereference        treat LINK_NAME as a normal file if
                                it is a symbolic link to a directory
  -P, --physical              make hard links directly to symbolic links
  -r, --relative              create symbolic links relative to link location
  -s, --symbolic              make symbolic links instead of hard links
  -S, --suffix=SUFFIX         override the usual backup suffix
  -t, --target-directory=DIRECTORY  specify the DIRECTORY in which to create
                                the links
  -T, --no-target-directory   treat LINK_NAME as a normal file always
  -v, --verbose               print name of each linked file
      --help     display this help and exit
      --version  output version information and exit

The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:

  none, off       never make backups (even if --backup is given)
  numbered, t     make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups

Using -s ignores -L and -P.  Otherwise, the last option specified controls
behavior when a TARGET is a symbolic link, defaulting to -P.

GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/ln>
or available locally via: info '(coreutils) ln invocation'


und make sowieso...

Usage: make [options] [target] ...
Options:
  -b, -m                      Ignored for compatibility.
  -B, --always-make           Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
                              Change to DIRECTORY before doing anything.
  -d                          Print lots of debugging information.
  --debug[=FLAGS]             Print various types of debugging information.
  -e, --environment-overrides
                              Environment variables override makefiles.
  --eval=STRING               Evaluate STRING as a makefile statement.
  -f FILE, --file=FILE, --makefile=FILE
                              Read FILE as a makefile.
  -h, --help                  Print this message and exit.
  -i, --ignore-errors         Ignore errors from recipes.
  -I DIRECTORY, --include-dir=DIRECTORY
                              Search DIRECTORY for included makefiles.
  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.
  -k, --keep-going            Keep going when some targets can't be made.
  -l [N], --load-average[=N], --max-load[=N]
                              Don't start multiple jobs unless load is below N.
  -L, --check-symlink-times   Use the latest mtime between symlinks and target.
  -n, --just-print, --dry-run, --recon
                              Don't actually run any recipe; just print them.
  -o FILE, --old-file=FILE, --assume-old=FILE
                              Consider FILE to be very old and don't remake it.
  -O[TYPE], --output-sync[=TYPE]
                              Synchronize output of parallel jobs by TYPE.
  -p, --print-data-base       Print make's internal database.
  -q, --question              Run no recipe; exit status says if up to date.
  -r, --no-builtin-rules      Disable the built-in implicit rules.
  -R, --no-builtin-variables  Disable the built-in variable settings.
  -s, --silent, --quiet       Don't echo recipes.
  -S, --no-keep-going, --stop
                              Turns off -k.
  -t, --touch                 Touch targets instead of remaking them.
  --trace                     Print tracing information.
  -v, --version               Print the version number of make and exit.
  -w, --print-directory       Print the current directory.
  --no-print-directory        Turn off -w, even if it was turned on implicitly.
  -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
                              Consider FILE to be infinitely new.
  --warn-undefined-variables  Warn when an undefined variable is referenced.

This program built for i586-pc-linux-gnu
Report bugs to <bug-make@gnu.org>


~josef

Guten Rutsch
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 31 Dezember 2016, 12:02:13
Hallo Josef,

... informativ + gut gemeint, habe mich aber vielleicht falsch ausgedrückt.
Ich meinte: "Syntax-kompatibel mit der Linux-Seite".

Das Problem ist ja, die Arduino IDE erwartet die Libs ja an bestimmten Stellen oder lokal.
Beim Entwickeln ist das aber eher ein Hindernis, weil man die Includes abändern muss.
Die Symbolischen-Links wären hier von Vorteil, da man die Standard-Include #include<lib_xy.h> so lassen könnte.
Da die Include-Hierarchien schnell unübersichtlich werden können.
Wenn nur einer daran entwickelt mag das zwar egal sein, bei mehreren Entwicklern aber eher ein Hindernis.

Grüße + einen guten Rutsch in neue Jahr!
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 02 Januar 2017, 18:10:10
Hallo Ralf9,

wollte den Output der OOK-Modul- und Deiner CC1101-Variante im DSO || LA gegenüberstellen
um die Übertragungsqualität zu begutachten und evtl. auch mit der Parametrierung zu experimentieren.

Allerdings bekomme ich in meiner plain Arduino-Variante den Kompile nicht komplett durch:
ZitatC:\Users\Jürgen\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.15\cores\arduino\main.cpp: In function 'main':
C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_732343\sketch\cc1101.h:219:39: warning: iteration 7 invokes undefined behavior [-Waggressive-loop-optimizations]

Mit den Source-Files aus dem Github-Repository funktioniert das nicht.

TimerOne befindet sich bei mir in den Library-Ordner
Anbei mein schon "optimiertes" bzw. angepasstes Ergebnis. Möchte aber nicht unbedingt einen Nebenschauplatz eröffnen.

Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 Januar 2017, 19:24:25
Zitat von: juergs am 02 Januar 2017, 18:10:10
Mit den Source-Files aus dem Github-Repository funktioniert das nicht.

was passiert, wenn Du die warnings ignorierst und auf hochladen klickst?

Gruß Ralf 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 02 Januar 2017, 19:42:43
probiere es aus ...
ZitatSketch uses 19,604 bytes (63%) of program storage space. Maximum is 30,720 bytes.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 02 Januar 2017, 21:52:56
Wenn die Libs nicht im Librarysordner sind,
passt das nicht.

Nach lokal reinholen über "Add file", werden die Warnings trotzdem angezeigt, Compile geht aber durch:

ZitatSketch uses 19,428 bytes (63%) of program storage space. Maximum is 30,720 bytes.
Global variables use 957 bytes (46%) of dynamic memory, leaving 1,091 bytes for local variables. Maximum is 2,048 bytes.
D:\Program Files (x86)\Arduino\arduino-1.6.12\hardware\tools\avr/bin/avrdude -CD:\Program Files (x86)\Arduino\arduino-1.6.12\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM28 -b57600 -D -Uflash:w:C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_653191/RF_Receiver.ino.hex:i

avrdude: Version 6.3, compiled on Sep 12 2016 at 17:24:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "D:\Program Files (x86)\Arduino\arduino-1.6.12\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM28
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xa3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xa3

Hat der Upload wohl den Bootloader zerschossen. War wohl Sonderfall.

Danach habe ich diese Version geflasht, dann ging der Upload wieder:
"RF_Receiver.ino.with_bootloader.hex"

Der hier im config-Verzeichnis der timerOne.h
#include "config\known_16bit_timers.h"

habe ich noch in
#include "known_16bit_timers.h" geändert.

Vermutlich ist meine Vorgehensweise falsch.
Benutzt Du CodeBlocks o.ä. zu kompilieren?

Der Nano reagiert dann nicht auf "?" -Kommandos etc.
ZitatSIGNALDuino-dev-r33_cc1101\RF_Receiver\RF_Receiver.ino:171:9: warning: extra tokens at end of #endif directive

Ich klinke mich allerdings jetzt aus diesem Thema aus!

Jürgen



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 Januar 2017, 23:44:40
ZitatSIGNALDuino-dev-r33_cc1101\RF_Receiver\RF_Receiver.ino:171:9: warning: extra tokens at end of #endif directive

Auf dem github war in der RF_Receiver.ino noch ein Fehler. Ich habs korrigiert.

ZitatBenutzt Du CodeBlocks o.ä. zu kompilieren?
CodeBlocks sagt mir nichts, ich verwende unter Linux (Opensuse) die Arduino IDE.


Ich habe beim WS-Befehl (command strobes) die Rückgabe des chip status eingebaut
cmdStrobeReg 36 chipStatus 1 delay1 0
Ich habe um zutesten ob ein delay von 1ms nach dem command strobes ausreicht, nach einem delay 1ms eine erneute chip status Abfrage eingebaut.

Der chip status kann folgende Werte haben:
0 IDLE      IDLE state  (Also reported for some transitional states instead of SETTLING or CALIBRATE)
1 RX        Receive mode
2 TX        Transmit mode
3 FSTXON    Fast TX ready
4 CALIBRATE Frequency synthesizer calibration is running
5 SETTLING  PLL is settling
6 RXFIFO_OVERFLOW
7 TXFIFO_UNDERFLOW


Mit WS3D kann das status byte abgefragt werden
0x3D  SNOP  No operation. May be used to get access to the chip status byte.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 08 Januar 2017, 13:10:20
Hallo
Ich bin durch div. gegoogle auf diese Diskussion gestossen, ich bein leider nicht so der Programmierer, kann euch daher kaum bis garnicht unterstützen... aber ich wollte mal fragen, ob das schon soweit funktioniert bzw. ich würd mich als Tester zur Verfügung stellen, meine Frage ist nur, ich habe derzeit den Selbstbaucul mit den CC1101 im Einsatz, ist die Verkabelung mit dem Arduino Nano und dem CC1101 genauso beim Signalduino wie beim Selbstbaucul? d.h. könnte man den Nano einfach um-flashen um zum singnalduino zu gelangen??

Wie müsste ich das anstellen - eine Step-by-Step-Anleitung für Noobs ;) wie mich wäre toll..

wenn ich irgendwie unterstützen kann, dann gebt bescheid...

das wäre toll wenn der CC1101 als signalduino funktionieren würde, der kann nämlich auch - so weit ich weiß - mehrere Frequenzbereiche abdecken, oder bin ich da falsch informiert?

lg
und gebt bescheid, wenn ich was helfen kann.

danke.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 09 Januar 2017, 18:27:22
ZitatWie müsste ich das anstellen - eine Step-by-Step-Anleitung

Ja Du kannst den Nano einfach um-flashen.
schau mal hier:
https://forum.fhem.de/index.php/topic,61774.msg554241.html#msg554241

Der Empfang funktioniert, das Senden ist fast fertig.

Der signalduino kann genauso wie der CUL eine Frequenz die Du mit set cc1101_freq ändern kannst.
Mit get protocolIDs wird eine Liste der unterstützten Protokolle angezeigt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 Januar 2017, 21:26:43
In der Anlage ist ein aktuelles hex-File der Signalduino CC1101 Firmware. Ich habe es mit der Arduino IDE 1.6.5 kompiliert.

V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 20:49:02

Nun kann auch beim Senden die Frequenz und Datenrate geändert werden, dies wird z.B. bei Somfy und einigen IT devices benötigt.

2017.01.12 21:09:03.963 2: sduinoE IT_set: Lampe1 on
2017.01.12 21:09:03.966 3: sduinoE IT_set: Setting ITfrequency (0D,0E,0F) to 10 aa 56 = 433.300 MHz
2017.01.12 21:09:03.966 5: sduinoE/write: adding to queue sendMsg P3#F0F000FFFF0D#R6#C280#F10aa56
2017.01.12 21:09:03.966 4: sduinoE/set: sending via SendMsg: SR;R=6;P0=280;P1=-8680;P2=840;P3=-280;P4=-840;D=01042304040423040404040404042304230423042304042304;F=10aa56;
2017.01.12 21:09:04.330 4: sduinoE/msg READ: SR;R=6;P0=280;P1=-8680;P2=840;P3=-280;P4=-840;D=01042304040423040404040404042304230423042304042304;F=10aa56;ccreg write back 10B071


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 12 Januar 2017, 22:07:33
Danke Ralf,

jetzt geht's. Super!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2017, 08:18:07
Ich hab die Firmware nach eine kleinen Anpassungen gestern noch im repo für den cc1101 Nano aktualisiert
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Januar 2017, 18:18:43
supercool!!!
das mit dem flachen hab ichauch schon gesehen, meine frage, wie komm ich jetzt zur aktuellen firmware des signalduino? ist die, sobald ich
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
ausführe automatisch da? und verwendet fhem diese dann automatisch zum flashen oder muss ich das irgendwo dem FHEM mitteilen?

ich nehme An die Einstellungen und Paarungen mit meinen Somfy sind dann alle flöten bzw. funktionieren nicht mehr mit dem signalduino oder kann man das irgendwie "rüberspielen"???
:o

lg und danke
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2017, 18:36:37
Über den Update Befehl kommt die aktuelle Entwicklungsversion der Module und Firmware auf deinen Fhem Server.

Mit dem Flash Befehl wird dann diese auf den Arduino geladen.
Je nachdem, was Du im Attribut Hardware angibst, wird eine angepasste Firmware geladen.

Solange die gleichen logischen Module verwendet werden, funktionieren deine Geräte wie zuvor.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Januar 2017, 18:58:20
ok, nur damit ich sicher bin es auch richtig verstanden zu haben...

1. Definieren des Signalduinos (=selbe Pfad wie der SelbstbauNanoCUL /dev/serial/...)
2. Definieren der hardware (=>Nano328)
3. Definieren der BAUDRate (=> selbe wie beim CUL @38400 oder kann man die hier erhöhen zb. auf 57600 - ist hier die aktuelle oder die zukünftige gemeint?)
4.set sduino flash? oder muss ich zuvor noch etwas definieren?

DeviceOverview
sduino
closed
sduino
100
Internals
CFGFN
Clients
:IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09:SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
DEF
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
DMSG
nothing
DevState
INACTIVE
DeviceName
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
NAME
sduino
NR
296
PARTIAL
STATE
closed
TIME
1484329057
TYPE
SIGNALduino
initResetFlag
1
initretry
3
version
Readings
state
closed
2017-01-13 18:40:31
version
0
2017-01-13 18:38:00
sduino
Attributes
flashCommand
avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
deleteattr
hardware
nano328
deleteattr
room
SignalDuino


da fehlt doch noch [PORT], [HEXFILE] und [LOGFILE] oder stöpselt sich das FHEM das selbst zusammen?

ich trau mich noch nicht den cul flachen, der funktioniert endlich mal... aber ich will auch meine Wetterstation empfangen können....immer diese grundlegenden und gravierenden Entscheidungen..
::)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2017, 19:04:44
Hardware ist nanocc1101 wenn Du vom nanocul kommst.

Baudrate ist 57600 (Default, wenn nichts angegeben ist)

Flashen kannst Du, sobald das Gerät definiert und das Attribut definiert wurden.

Die passende Firmware sich das Modul selbstständig.

Wenn es nicht funktioniert, kannst Du auch jederzeit wieder eine andere Firmware flashen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Januar 2017, 19:14:06
hallo Sidey
danke für die schnelle Antwort, aber irgendwas passt da nicht ganz...
wenn ich auf attr hardware gehe kann ich nur "nano328 / uno / promini328" auswählen

die baudrate, die ich definiere mit dem Pfad, ist das lediglich die zum übertragen oder ist das auch die baudrate mit der dann in späterer folge fhem mit dem signalduino kommuniziert? also die bei " /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400" ist die derzeitige Kommunikationsgeschwindigkeit... und nach dem flashen muss ich diese auf 57600 ändern, denn das ist ja die Standard wenn ich das richtig verstanden habe. oder hat das nix damit zu tun?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Januar 2017, 19:20:17
so.... ich habe getan....
aber mit Fehlern...

flashing Arduino sduino
hex file: ./FHEM/firmware/SIGNALduino_nanocc1101.hex
port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
log file: ./log/SIGNALduino-Flash.log
sduino closed
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -vv -U flash:w:./FHEM/firmware/SIGNALduino_nanocc1101.hex 2>./log/SIGNALduino-Flash.log

--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/SIGNALduino_nanocc1101.hex"
avrdude: error opening ./FHEM/firmware/SIGNALduino_nanocc1101.hex: No such file or directory
avrdude: input file ./FHEM/firmware/SIGNALduino_nanocc1101.hex auto detected as invalid format
avrdude: can't open input file ./FHEM/firmware/SIGNALduino_nanocc1101.hex: No such file or directory
avrdude: read from file './FHEM/firmware/SIGNALduino_nanocc1101.hex' failed

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino opened


kann es an der Groß/kleinschreibung liegen??

pi@SmartPi:/opt/fhem/FHEM/firmware $ ls -al
insgesamt 944
drwxr-xr-x 2 fhem dialout   4096 Jän 13 18:14 .
drwxr-xr-x 5 fhem dialout  20480 Jän 13 18:14 ..
-rw-r--r-- 1 fhem dialout  99233 Jän 13 18:10 esptool.py
-rw-r--r-- 1 fhem dialout  54451 Nov 15  2015 JeeLink_EC3000.hex
-rw-r--r-- 1 fhem dialout 442384 Jän 13 18:10 JeeLink_LaCrosseGateway.bin
-rw-r--r-- 1 fhem dialout  80715 Nov 15  2015 JeeLink_LaCrosse.hex
-rw-r--r-- 1 fhem dialout  34557 Nov 15  2015 JeeLink_PCA301.hex
-rwxrwxrwx 1 fhem dialout  49906 Jän 13 18:47 SIGNALduino_nano328.hex
-rwxrwxrwx 1 fhem dialout  56423 Jän 13 18:14 SIGNALduino_nanoCC1101.hex
-rwxrwxrwx 1 fhem dialout  49906 Jän 13 18:47 SIGNALduino_promini328.hex
-rwxrwxrwx 1 fhem dialout  49906 Jän 13 18:47 SIGNALduino_uno.hex
pi@SmartPi:/opt/fhem/FHEM/firmware $
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2017, 19:31:24
Die angegebene Firmware gibt es nicht. Bitte Fhem nach dem Update all Befehl neu starten und dann mittels Hardware Attribut den nanocc1101 wählen. Dann das selbst vergebene Firmware Files aus der Konfiguration löschen.

Ansonsten den korrekten Dateinamen der Firmware angeben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 13 Januar 2017, 19:35:15
Normalerweise geht das flashen vom Signalduino ganz einfach (die SIGNALduino CC1101 Firmware funktioniert z.Zt. nur auf dem Selbstbau NanoCUL):

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

fhem neustarten
Zitat
ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 19. Jan 17:25 usb-FTDI_FT232R_USB_UART_A600G900-if00-port0 -> ../../ttyUSB0

Zitatdefine sduino SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_xxxxxxxx-if00-port0@57600


beim attr hardware "nanoCC1101" setzen

und dann mit "set sduino flash" flashen.

Es ist evtl notwendig den NanoCUL kurz aus- und wieder einstecken.

In ganz seltenen Fällen kann ein Factory Reset notwendig sein:
get sduino raw e

Wenn der CC1101 erkannt wurde steht in der version "cc1101":
ZitatV 3.3.1-dev SIGNALduino cc1101 - compiled ...


Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 13 Januar 2017, 20:24:41
das habe ich ja auch alles gemacht, die firmware habe ich nicht selbst erstellt, die war nach den updates da... ich habe lediglich den signalduino definiert und in der fhem.cfg das hardware Attribut gesetzt... dann wollte ich flashen... siehe voriges post - das kam dabei raus...
jetzt habe ich die firmware gelöscht, nochmals ein "update all" ausgeführt und fhem neu gestartet...
dann geflashed aber genau das selbe Endresultat....
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: billy-boy am 13 Januar 2017, 21:00:57
Moin Moin

Ich hab auch mein nanoCUL umgeflasht. Funktioniert einwandfrei.

Der SD empfängt sogar Daten von einer 20 Jahre alten Wetterstation.
Diese hat 3 alte THR128. Allerdings werden die Daten nicht ausgewertet.

mit Log 4 erhalte ich


2017.01.13 20:33:18 4: sduino/msg READ: MC;LL=-2688;LH=3170;SL=-1213;SH=1718;D=8ED7BEDB;C=1464;L=32;R=13;
2017.01.13 20:33:18 4: sduino: Found manchester Protocol id 18 clock 1464 RSSI -67.5 -> OSV1
2017.01.13 20:33:18 3: sduino: Unknown code 0871284124, help me!
2017.01.13 20:33:19 4: sduino/msg READ: MC;LL=-2621;LH=3164;SL=-1223;SH=1707;D=8ED7BEDB;C=1452;L=32;R=12;
2017.01.13 20:33:19 4: sduino: Found manchester Protocol id 18 clock 1452 RSSI -68 -> OSV1
2017.01.13 20:33:19 4: sduino: Dropped (0871284124) due to short time or equal msg


Muß ich da jetzt selber Hand anlegen? oder ist da was in Planung?
Es scheint allerdings was nicht zu passen.
Die angezeigte Temperatur sollte 21,3 sein. Das THR sendet auf Channel3.

Danke für die klasse Arbeit

Billy
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 13 Januar 2017, 21:04:50
Hi Michel,

ja das ist die Groß/Kleinschreibung.
Bei mir hat das Hexfile im Firmware ordner ein großes CC.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 13 Januar 2017, 21:24:56
Zitat von: Michl1003! am 13 Januar 2017, 20:24:41
und in der fhem.cfg das hardware Attribut gesetzt... dann wollte ich flashen... siehe voriges post - das kam dabei raus...

das ist der Fehler, normalerweise sollte man die fhem.cfg nicht direkt editieren.
Wenn das Attribut "hardware nanoCC1101" heißt und Du  "hardware nanocc1101" einträgst, kann es nicht funktionieren.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: C.Frahm am 13 Januar 2017, 21:56:05
Hallo,  kurze Frage. Funktionieren Homematic Geräte dann noch wenn man den Nanocul umfassend?
Vielen Dank Gruß Christian
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2017, 22:19:25
Zitat von: C.Frahm am 13 Januar 2017, 21:56:05
Hallo,  kurze Frage. Funktionieren Homematic Geräte dann noch wenn man den Nanocul umfassend?
Vielen Dank Gruß Christian

Deine Homematic geräte funktionieren noch, allerdings nehme ich an, dass deine eigentliche Frage ist, ob der SIGNALduino Homematic empfängt.
Das muss ich mit nein beantworten. Dafür gibt es von EQ3 besser geeignete Geräte.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: C.Frahm am 13 Januar 2017, 22:26:33
Zitat von: Sidey am 13 Januar 2017, 22:19:25
Deine Homematic geräte funktionieren noch, allerdings nehme ich an, dass deine eigentliche Frage ist, ob der SIGNALduino Homematic empfängt.
Das muss ich mit nein beantworten. Dafür gibt es von EQ3 besser geeignete Geräte.

Grüße Sidey

Hallo,

ja das mein ich. Aber danke dir für deine Antwort dann warte ich auf den neuen Transreciever.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 14 Januar 2017, 00:17:36
@Ralf:
Bist der Hammer!! hab in der fhem.cfg die CC auf groß und dann hats auch schon funktioniert!
ich konnte nämlich in der normalem Maske nur eben diese 3 Varianten auswählen ohne den nanoCC1101..

jetzt hat der Flash gefunkt...

danke schon mal soweit...

Update:
die Somfy-Rollos funktionieren auch, musste nur die IODevice auf den Signalduino umstellen....

ich hab da noch 2 Fragen:
der erkennt auch meine Auriol Wetterstation (die Premium = 3 teilig mit Windgeschwindigkeit, Windrichtung, Regensensoren http://www.ebay.de/itm/AURIOL-Premium-Wetterstation-3-teilig-Ausstellungsstuck-/281363740020?pt=DE_Elektronik_Computer_Haushaltsgeräte_Bügeleisen_PM&hash=item418295f574), die Temp und Feuchtewerte stimmen nicht mit denen der Wetterstation überein... (Wind, Regen wird gar nicht übertragen?) - habe das hier gefunden, kann jemand damit was anfangen? http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf
gibts da schon was? hab nur diesen Post https://forum.fhem.de/index.php/topic,17196.1710.html gefunden aber auch nicht weiter schlau draus geworden.

2. habe eine Somfy-Rollo, die lässt sich nur mit dem Handsender bedienen, kann ich das das signal irgendwie ins fhem klonen? ich bekomme zwar, wenn ich den sender drücke eine menge an zeilen im log aber wenn ich die dann als raw senden will tut sich nix.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Pfriemler am 15 Januar 2017, 21:37:30
Ich suche noch nach Infos, ob man den Signalduino auch direkt auf einem ESP zum Laufen bekommt. Seit dem Oktober scheint sich da nichts getan zu haben.
Habe ich was übersehen? Ist die "Arbeitsteilung" zwischen Signalverarbeitung (Arduino) und WLAN (ESPlink) auf absehbare Zeit das Mittel der Wahl?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 15 Januar 2017, 21:45:10
Zitat von: Pfriemler am 15 Januar 2017, 21:37:30
Ich suche noch nach Infos, ob man den Signalduino auch direkt auf einem ESP zum Laufen bekommt. Seit dem Oktober scheint sich da nichts getan zu haben.
Habe ich was übersehen? Ist die "Arbeitsteilung" zwischen Signalverarbeitung (Arduino) und WLAN (ESPlink) auf absehbare Zeit das Mittel der Wahl?

Aktuell musst Du den ESP leider zum WLAN Chip degradieren.
Prinzipiell läuft der SIGNALduino Code auch auf dem ESP. Leider schmiert er mehrmals pro Tag ab (unproblematisch).
Problematischer ist, dass er nicht so flott auf den Interrupt reagiert. Da müsste man noch mal schauen, ob man das irgendwie umgehen könnte.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 15 Januar 2017, 22:07:21
Es wurde auch schon versucht die culfw auf den ESP8266 zu portieren.
Dies dürfte auch für den Signalduino gelten:
Zitat von: hjgode am 26 November 2016, 09:14:24
Da der ESP8266 sehr zeitkritisch bezgl WLAN ist, können schnelle Interrupts die Verbindung stören. Eine Portierung von zeitkritischem Code zur Auswertung von Signalen wird sich schwierig bis unmöglich gestalten

Nur so ein paar Gedanken.

Ganz ohne einen Arduino wird es demnach beim ESP8266 nicht sauber funktionieren.
Was möglich sein müsste, ist eine Arbeitsteilung, bei der promini die Signale per Interrupt empfängt und in den FIFO speichert und auch das Senden übernimmt.
Der ESP8266 würde dann die Nachrichten seriell vom FIFO abholen und verarbeiten.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Pfriemler am 15 Januar 2017, 23:29:11
Danke für Aufklärung. Dann werde ich wohl doch einen Arduino kaufen müssen ...

via Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MichlB am 16 Januar 2017, 16:25:07
hallo wieder mal.
Wie funktioniert das, wenn ich ein neues Protokoll in die 14_CUL_TCM97001.pm einbauen möchte? Da ich ja die übertragungslogic der Wetterstation hätte, müsste das doch machbar sein oder?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 16 Januar 2017, 18:38:44
Du schreibst einen Patch und veröffentlichst ihn ihm Forum.

Dass die Codierung zum tcm97001 Modul passt, hast Du bereits geklärt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Januar 2017, 07:37:19
@Ralf:

Ich habe gestern ein paar Messungen und Analysen zum Thema Laufzeit etc mit einem NANO (16 MHz ) durchgeführt.

Ich habe alles in Millisekunden gemessen. Alles <1 ms ist schnell genug.

Ein Schleifendurchlauf kann derzeit  leider fast bis zu 50 ms dauern, da wir eine while schleife in loop haben.
In dieser Zeit läuft der FiFo voll und wir verlieren Daten.

Ich habe das näher untersucht und wie vermutet, geht die meiste Zeit beim Serial.Print drauf.
Wenn ich die Firmware compiliere, dann ist der TX Puffer 64 Byte. Sobald wir mehr als 64 Byte seriell senden, blockiert die Serial Print Funktion, bis alle Daten im TX Puffer sind.
Ein Erhöhen der Baudrate (ich habe es mal mit 250000) getestet, bringt hier deutliche Verbesserungen.

Die langen Ausgabezeiten sind im wesentlichen bei den MU Protokollen ein Problem, da hierbei um die 340 Zeichen übertragen werden müssen.

Um das Problem zu minimieren, hilft aus meiner Sicht nur, die Datenmenge zur Übertragung zu reduzieren.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: drdownload am 20 Januar 2017, 10:09:33
Hi, ich habe jetzt im Wiki gesehen, dass der Smartwares SH5-TSO-A auch ünterstützt wird mit dem Modul IT. Der Smartwares SH5-TSO-A ist jedoch ein Home-Easy Gerät, kann das stimmen?

LG
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 20 Januar 2017, 10:44:31
Hab ich auch gedacht. Ist aber offensichtlich nicht so.
Ich habe hier von der Heim-Bieber-Filiale 2 Bewegungsmelder, 1 x Smartwares  SH5-TSO-A, 1 x HomeEasy HE851.
Der Smartwares-Melder wird per Autocreate angelegt, der HomeEasy nicht.
Die beiden Dinger sind eineiige Zwillige - optisch gesehen. Hingen auch im Verkaufsraum an gleicher Stelle. Daß sie offensichtlich völlig unterschiedliche Funkprotokolle senden ist mir erst aufgefallen, als der HE851 sich partout nicht integrieren ließ.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 Januar 2017, 21:41:03
Zitat von: Sidey am 20 Januar 2017, 07:37:19
Wenn ich die Firmware compiliere, dann ist der TX Puffer 64 Byte. Sobald wir mehr als 64 Byte seriell senden, blockiert die Serial Print Funktion, bis alle Daten im TX Puffer sind.
Ein Erhöhen der Baudrate (ich habe es mal mit 250000) getestet, bringt hier deutliche Verbesserungen.

Eine Möglichkeit wäre demnach den TX Puffer und die Baudrate zu erhöhen.
Bei einer Baudraten erhöhung gibt es was zu beachten:
http://arduino.stackexchange.com/questions/296/how-high-of-a-baud-rate-can-i-go-without-errors

Zitat
Die langen Ausgabezeiten sind im wesentlichen bei den MU Protokollen ein Problem, da hierbei um die 340 Zeichen übertragen werden müssen.
Um das Problem zu minimieren, hilft aus meiner Sicht nur, die Datenmenge zur Übertragung zu reduzieren.

Die reduzierung der Datenmenge sollte abschaltbar sein. Wenn z.B. D=13121012101012 zu D=0x13 0x12 0x10 0x12 reduziert wird, dann können die raw-Nachrichten nicht mehr mit Putty oder einem seriellen Monitor angeschaut werden

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 21 Januar 2017, 10:14:37
Eine höhere Baudrate ist prinzipiell möglich, wird meines Erachtens aber zu Problemen bei  Anwendern führen. (Schlechte Kabel, ungünstig laufende Quarze )

Das Abschalten der Datenreduzierung  halte ich für ungünstig. Wir wollen ja reduzieren, damit keine Daten verloren gehen.
Das man es dann nicht mehr ohne Hilfsmittel lesen kann ist ein Nachteil, ich wüsste aber nicht, wie man das lösen möchte.

Ein Erhöhen des TX Puffers löst die Dauer auch nur geringfügig. Wir müssten den TX Puffer dafür riesen großes machen. Das lohnt sich nicht.

Im Abschnitt D= kann man das meiste herausholen. Dort haben wir einen overhead von 5/8 je Zeichen. Wir übertragen Werte von 0-7. Dafür sind drei Bits notwendig. Wir übertragen aber immer 8. Der Overhead beginnt schon im Message Array.

Wenn man das ganze ähnlich wie im Bitstore aufzieht, dann setzt man pro Wert immer 3 bits und verschiebt dann.

Man müsste auf Fhem Seite lediglich die Daten wieder in 3 Bit Häppchen unterteilen.

Dann kommt man auf einen overhead von maximal 7/8 bit auf die gesamte Datenmenge.

Den Teil bei P= kann man reduzieren, wenn man anstelle von Dezimal auf hexadezimal umstellt.

Des weiteren kann man auch Überlegungen ob man sich wiederholende Zeichenfolgen erkennt und komprimiert.
Gerade bei MU Nachrichten finden sich ja auch Wiederholungen wieder, die wir heute nicht erkennen.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 21 Januar 2017, 18:07:42
Hallo zusammen.

Ich weiß, es wird gerade beim Signalduino an der Umsetzung gearbeitet, den CC1101 zu implementieren.

Ich bin im Netz in letzter Zeit öfters auf den Begriff LoRa gestoßen. Diese Module haben eine recht hohe Reichtweite beim senden.
Besteht die Möglichkeit so ein RFM95 Modul für 433 MhZ mit dem SignalDuino nutzbar zu machen ?

Von der Modulationarten scheint es ja zu passen !

RFM95
LoRaTM Modem.
Š 168 dB maximum link budget.
Š +20 dBm - 100 mW constant RF output vs. V supply.
Š +14 dBm high efficiency PA.
Š Programmable bit rate up to 300 kbps.
Š High sensitivity: down to -148 dBm.
Š Bullet-proof front end: IIP3 = -12.5 dBm.
Š Excellent blocking immunity.
Š Low RX current of 10.3 mA, 200 nA register retention.
Š Fully integrated synthesizer with a resolution of 61 Hz.
Š FSK, GFSK, MSK, GMSK, LoRaTM and OOK modulation.
Š Built-in bit synchronizer for clock recovery.
Š Preamble detection.
Š 127 dB Dynamic Range RSSI.
Š Automatic RF Sense and CAD with ultra-fast AFC.
Š Packet engine up to 256 bytes with CRC.
Š Built-in temperature sensor and low battery indicator.
Š Modue Size:16*16mm


CC1101


- High sensitivity (–111 dBm at 1.2 kBaud, 868 MHz, 1% packet error rate)
- Low current consumption (14.7 mA in RX,1.2 kBaud, 868 MHz)
- Programmable output power up to +10dBm for all supported frequencies
- Excellent receiver selectivity and blocking performance
- Programmable data rate from 1.2 to 500 kBaud
- Frequency bands: 300-348 MHz, 387-464 MHz and 779-928 MHz

Analog Features

- 2-FSK, GFSK, and MSK supported as well as OOK and flexible ASK shaping
- Suitable for frequency hopping systems due to a fast settling frequency synthesizer: 90us settling time
- Automatic Frequency Compensation (AFC) can be used to align the frequency synthesizer to the received center frequency
- Integrated analog temperature sensor


http://www.kh-gps.de/lora.htm (http://www.kh-gps.de/lora.htm)

Gruß und Danke
Sascha
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 21 Januar 2017, 18:18:21
Zitat von: sash.sc am 21 Januar 2017, 18:07:42
Ich weiß, es wird gerade beim Signalduino an der Umsetzung gearbeitet, den CC1101 zu implementieren.

Ich bin im Netz in letzter Zeit öfters auf den Begriff LoRa gestoßen. Diese Module haben eine recht hohe Reichtweite beim senden.
Besteht die Möglichkeit so ein RFM95 Modul für 433 MhZ mit dem SignalDuino nutzbar zu machen ?

Wenn beim RFM95 Modul auch der CC1101 verwendet wird, dann ist es evtl möglich.

Edit.
Ich habe mir mal das Datenblatt des RFM95 angeschaut, das sieht komplett anders aus wie der CC1101.
Den RFM95 zu unterstützen ist mir zu aufwendig.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 21 Januar 2017, 19:16:42
Zitat von: Ralf9 am 21 Januar 2017, 18:18:21
Wenn beim RFM95 Modul auch der CC1101 verwendet wird, dann ist es evtl möglich.

Edit.
Ich habe mir mal das Datenblatt des RFM95 angeschaut, das sieht komplett anders aus wie der CC1101.
Den RFM95 zu unterstützen ist mir zu aufwendig.

Gruß Ralf
Danke für deine Antwort.

Gruss
Sascha
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 21 Januar 2017, 19:57:37
Zitat von: Sidey am 21 Januar 2017, 10:14:37
Das Abschalten der Datenreduzierung  halte ich für ungünstig. Wir wollen ja reduzieren, damit keine Daten verloren gehen.
Das man es dann nicht mehr ohne Hilfsmittel lesen kann ist ein Nachteil, ich wüsste aber nicht, wie man das lösen möchte.

Ich würde es schön finden, wenn die Datenreduzierung abschaltbar wäre. Man könnte sie z.B, mit "CEK" ein und mit "CDK" ausschalten.

Ich habe Mir mal genauer darüber Gedanken gemacht:
Im ersten Moment hört sich das mit der Datenreduzierung recht gut machbar an. Ich denke das das doch etwas aufwändiger wird.
Die reduzierten Daten  in der "sub SIGNALduino_Read($)" zu verarbeiten ist wahrscheinlich nicht so einfach.

Am beginn der raw Nachricht sollte erkennbar, daß sie reduziert wird. zB. mit Mu und Ms. Bei MC Nachrichten müssten wir auf eine Reduzieung verzichten können.

Eine reduzierte MU Nachricht könnte dann z.B. so aussehen:
ZitatMuP0C9P1D34P2ABCP31F9D<anz><reduzierteDaten>CP0

Die Reduzierung kann man auch noch abhängig machen von der Anzahl der P Abschnitte. Bei P0-P3 kann man dann in 2 Bit Häppchen aufteilen.
Bei der Reduzierung muss auch darauf geachtet werden, daß in den reduzierten Daten der Wert 0x02 nicht vorkommt, da sonst der Beginn der Nachricht nicht mehr eindeutig erkannt werden kann.
Das hier wird auch nicht mehr so einfach funktionieren, da " \n" auch in den reduzierten Daten vorkommen kann.
  while($SIGNALduinodata =~ m/\n/) {
    my $rmsg;
    ($rmsg,$SIGNALduinodata) = split("\n", $SIGNALduinodata, 2);



ZitatEin Schleifendurchlauf kann derzeit  leider fast bis zu 50 ms dauern, da wir eine while schleife in loop haben.
In dieser Zeit läuft der FiFo voll und wir verlieren Daten.

Das hier weckt bei mir Begehrlichkeiten und Wünsche :)
Kannst Du mir eine konfigurierbar Debug Option einbauen?

Debug Level1:
Nachdem mit dem seriell senden die Verarbeitung in der signalduino.cpp fertig ist, soll der freie FIFO angeschaut werden.
Wenn zuwenig frei ist, soll der freie FIFO in einer Debug Nachricht ausgegeben werden z.B.
<002>MD10<003>   für 10 freie Bytes

falls es nicht zu aufwändig ist:
Debug Level2:
Nach jeder Nachricht wird der freie FIFO und die Zeit des schleifendurchlaufs ausgegeben.

Die Debug Option könnte man mit CED1 oder CED2 ein und mit CED0 ausschalten.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 21 Januar 2017, 19:59:53
Hallo sach.sc,

die Daten des RFM95 hören sich ja gut an, aber:z.B. max. erlaubte Sendeleistung:
10mW CC1101 gegen "100 mW constant RF output"!
Short_Range_Devices (https://de.wikipedia.org/wiki/Short_Range_Devices)
Es gäbe ja auch keine Sensoren dafür? Außer eigene Protokolle.

Allerdings gäbe es weitere die IOT-Alternativen:

z.B. "CC2650STK – Multi standard supporting Bluetooth, 6LoWPAN, and ZigBee":
TI-SensorTag (http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/?INTC=SensorTag&HQS=sensortag)
prototypingkit-texas-instruments-cc2650stk (https://www.conrad.de/de/prototypingkit-texas-instruments-cc2650stk-1341194.html?gclid=CKOpzcH109ECFUcQ0wodq6IB0g&insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&s_kwcid=AL!222!3!172422438366!!!g!!&ef_id=VzcBuQAAAI7nfZaX:20170121185758:s)
http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/tearDown.html (http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/tearDown.html)

mit
ZitatDas neue SensorTag IoT-Kit lädt Sie ein, Ihre Cloud-verbundenen Produktideen zu realisieren. Das neue SensorTag enthält nun 10 stromsparende MEMS-Sensoren in einem winzigen roten Paket.
Es kann mit Entwicklungs-Packs erweitert werden, um das Hinzufügen von Sensoren und Aktoren zu ermöglichen.
ZitatOne year battery life and battery-less operation for Bluetooth low energy, 6LoWPAN, ZigBee, and Sub-1GHz Long Range

Grüße,
Jürgen


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 21 Januar 2017, 20:16:57
Hallo Jürgen.

Danke für die Info.
Habe gedacht das rfm95 mit 433MHz hauptsächlich als Sender einzusetzen. Einfach um die Reichweite aufgrund der Leistung zu erhöhen.
Stichwort IT Protokoll..  8)

Von mobil gesendet daher kurze Antwort

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 21 Januar 2017, 20:24:14
ZitatHabe gedacht das rfm95 mit 433MHz hauptsächlich als Sender einzusetzen. Einfach um die Reichweite aufgrund der Leistung zu erhöhen.
Stichwort IT Protokoll..  8)

Ja, das bekommst Du aber auch mit einem 1:1 Repeater hin, aber max. 10 mW Sendeleistung.
Schau mal unter "Hideki" hier im Forum oder:
RemoteSensor -examples -Repeater (RemoteSensor-Lib) (https://bitbucket.org/fuzzillogic/433mhzforarduino/src/0847a6d8a9173abd5abf9cf571a1539f56588c0e/RemoteSensor/examples/Repeater/?at=default)

Funk-Erweiterung-Repeater-ITV-100.html (http://www.intertechno24.de/Sender/Funk-Erweiterung/Funk-Erweiterung-Repeater-ITV-100.html)

Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 21 Januar 2017, 20:37:27
Zitat von: Sidey am 21 Januar 2017, 10:14:37
Eine höhere Baudrate ist prinzipiell möglich, wird meines Erachtens aber zu Problemen bei  Anwendern führen. (Schlechte Kabel, ungünstig laufende Quarze )

Zur Baudrate habe ich was interessantes gefunden.
http://wormfood.net/avrbaudcalc.php?postbitrate=115200&postclock=16&u2xmode=1&hidetables=1

Demnach ist bei 8 MHz die Baudrate 57600 nicht so gut. Der error ist mit 2.1% zwischen recommended and absolute max error rates

Beim promini müsste man eigentlich die Baudrate auf 250000 erhöhen können, da dieser normalerweise nicht direkt per Kabel zum USB Port verbunden wird, oder täusche ich mich da?

Liest hier jemand mit, der beim usr-tcp232-t2 und ESP8266 messen kann wie groß der error bei 250000 ist oder weiß es sogar ohne zu messen?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 22 Januar 2017, 01:56:08
Zitat von: Ralf9 am 21 Januar 2017, 19:57:37
Ich würde es schön finden, wenn die Datenreduzierung abschaltbar wäre. Man könnte sie z.B, mit "CEK" ein und mit "CDK" ausschalten.

Ich habe Mir mal genauer darüber Gedanken gemacht:
Im ersten Moment hört sich das mit der Datenreduzierung recht gut machbar an. Ich denke das das doch etwas aufwändiger wird.
Die reduzierten Daten  in der "sub SIGNALduino_Read($)" zu verarbeiten ist wahrscheinlich nicht so einfach.

Ich habe mal mit einer simplen variante angefangen. Jeder Wert nimmt 4 bit ein. Somit stehen in einem byte immer 2 Werte. Die gemessenen Zeiten stehen im Code.

Serial.println("---- Start of ----");
delay(400);
     
char c[] = { "010203040506071012131415161720212324252627303132343536374041424345464750515253545657606162636465677071727374757601020304050607101213141516172021232425262730313234353637404142434546475051525354565760616263646567707172737475760102030405060710121314151617202123242526273031323435363740414243454647505152535456576061626364656770717273747576" };
unsigned long now;
unsigned int duration;
uint16_t len = sizeof(c) / sizeof(c[0])-1;


now= millis();
Serial.write(c, len);
duration = millis() - now;  // 46 ms
Serial.println("");
Serial.println(duration);
Serial.println("---- ----");

delay(400);

now = millis();
byte buff = 0;

for (int i =1; i <= len; i++)
{

if (i % 2)
{
buff = c[i - 1]<<4;
//Serial.write(buff<<4);

} else {
buff = buff | c[i - 1] ;
Serial.write(buff);
}
}
duration = millis() - now;  //18 ms
Serial.write(0x04);
delay(120);
Serial.println("");
Serial.println(duration); 

Serial.println("---- end test ----");


Alles mit 57600 Baud getestet.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 22 Januar 2017, 12:17:07
Hallo Sidey,

wollte die Performance (NANO,16MHz) der Arduino- mit der Printf-Lösung gegenüberstellen,
da ich gerade den Testaufbau parat hatte.
Habe Dein Testcase etwas abgespeckt um vergleichen zu können.

Ergebnis: Leider kostet "Komfort" etwas mehr an Zeit. ( 24:30ms  ... was zu beweisen war, leider.  :'( )

ZitatStarting in 5s ...
*** Start of ArduinoSerial ----
LEN: 336
1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv
Dauer: 24
*** End test ----

*** Start of printf via FILE ---
LEN: 336
1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv
Dauer: 30
*** End test ----


Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Januar 2017, 21:11:54
Ich habe noch ein bisschen weiter getestet....

Die Variante, einen Wert nur 3 Bits belegen zu lassen bringt auch noch mal deutliche Geschwindigkeitsvorteile.
Ich denke, ich werde die den message Array auf die Bitstore Klasse umrüsten und die Bitstore Klasse noch ein wenig mit Operatoren ausrüsten.

Dann wird intern immer sparsam gespeichert und die Ausgabe kann im Normalfall dann auch so erfolgen.
Probleme mit Zeilenenden hatte ich noch keine, das schaue ich mir noch mal an, welche Bitfolge dazu führen würde.

Weitere Überlegung, die Werte hinter P=1252  können wir als int (16 bit) anstelle der 4 zeichen (32 bit) übergeben.


Lesen kann man die Ausgabe dann nur noch in Fhem.

Vielleicht schreibe ich eine mini Terminalanwendung, die das direkt umwandelt.



Zur Baudrate habe ich auch noch ein bisschen gelesen.
Die Baudrate ist von der USB Verbindung unabhängig. Die USB Verbindung ist immer gleich schnell, da gibt es keine Baudrate.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Januar 2017, 21:39:24
Zitat von: Sidey am 25 Januar 2017, 21:11:54
Die Variante, einen Wert nur 3 Bits belegen zu lassen bringt auch noch mal deutliche Geschwindigkeitsvorteile.
Ich denke, ich werde die den message Array auf die Bitstore Klasse umrüsten und die Bitstore Klasse noch ein wenig mit Operatoren ausrüsten.

Dann wird intern immer sparsam gespeichert und die Ausgabe kann im Normalfall dann auch so erfolgen.

Kannst Du abschätzen ob der 8 MHz pro mini dafür noch schnell genug ist?


Zitat
Weitere Überlegung, die Werte hinter P=1252  können wir als int (16 bit) anstelle der 4 zeichen (32 bit) übergeben.

Ist wahrscheinlich keine so gute Idee. z.B. P=4098 wäre 0x1002 und wäre dann Zeilenende und Nachrichtenbeginn

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Januar 2017, 22:01:06
Zitat von: Ralf9 am 25 Januar 2017, 21:39:24
Kannst Du abschätzen ob der 8 MHz pro mini dafür noch schnell genug ist?

Ich schätze mal ja. Die serielle Ausgabe ist bei 8Mhz gleich schnell.


Zitat von: Ralf9 am 25 Januar 2017, 21:39:24
Ist wahrscheinlich keine so gute Idee. z.B. P=4098 wäre 0x1002 und wäre dann Zeilenende und Nachrichtenbeginn


4096 wäre b0001000000000010

Da würde ich erst mal kein Problem sehen. Aber das schauen wir uns an, wenn wir an dem Punkt sind.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 25 Januar 2017, 23:17:17
Hallo,
ich bin am verzweifeln.
Ich habe mit einen SIGNALduino mit den Standard 433Mhz Billigmodulen gebaut, der funktioniert auch super.
Nur beim Somfy Protokoll habe ich keine Reichweite, wunder auch nicht, da die Somfy-Frequenz 433,42 Mhz ist, der SIGNALduino sendet mit 433,92Mhz
(das Problem ist im Forum auch beschrieben).

Kein Problem, ihr habt inzwischen ja den CC1101 in die SIGNALduino Firmware eingebaut.
Also habe ich mir jetzt einen SIGNALduino-CC1101 aufgebaut, da funktioniert jetzt aber (fast) nichts mehr.
Sobald ich das CC1101-Modul mit dem SIGNALduino verbinde klappt nichts mehr, der SIGNALDuino lässt sich nicht mehr initialisieren.
(Schaltung wie NanoCul incl. Widerstandsteiler mit 470/1000 Ohm siehe : https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan (https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan))
Der Fehlerfall sieht im Logfile folgendermaßen aus:

2017.01.25 22:36:18 3: sduino reset
2017.01.25 22:36:18 3: Opening sduino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.01.25 22:36:18 3: Setting sduino serial parameters to 57600,8,N,1
2017.01.25 22:36:19 1: sduino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.01.25 22:36:19 1: sduino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.01.25 22:36:19 3: sduino device opened
2017.01.25 22:36:20 3: sduino/init: disable receiver (XQ)
2017.01.25 22:36:21 3: sduino/init: get version, retry = 0
2017.01.25 22:36:31 3: sduino/init: get version, retry = 1
2017.01.25 22:36:41 3: sduino/init: get version, retry = 2
2017.01.25 22:36:51 3: sduino/init: get version, retry = 3
2017.01.25 22:36:51 2: sduino/init retry count reached. Closed
2017.01.25 22:36:51 2: sduino closed


Vertausche ich die MOSI/MISO Leitungen klappt die Initialisierung des SIGNALduino, allerdings wird kein CC1101 gefunden und ich bekomme die Version:
V 3.3.1-dev SIGNALduino - compiled at Jan 12 2017 23:04:38
ohne CC1101 angezeigt.

Entferne ich die MOSI Leitung des CC1101 (über Spannungsteiler an Pin D11 des Nano) von Pin D11, klappt die Initialisierung des SIGNALduino und ich bekomme die Version:
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38
korrekt angezeit (hä, wie denn das).
Senden klappt allerdings nicht (wie denn auch ohne MoSi Leitung).
Mir ist schon schleierhaft, wie ohne MoSi Leitung überhaupt der CC1101 erkannt wird.

Hat jemand eine Idee?
(bin bzgl. HW nicht unterbelichtet, habe inzwischen 2x ProMicro CUL gebaut die seit > 1 Jahr problemlos arbeiten)

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Januar 2017, 23:27:28
Du kannst mal mit
get sduino raw e
einen factory reset machen
und dann ein
get sduino ccreg 99

Edit:
Du kannst auch mal die a-culfw flashen um zu testen ob Deine Hardware ok ist.

Edit2:
Du kannst Dich auch mit Putty oder dem seriellen Monitor der Arduino IDE verbinden und dann z.B. "V" senden

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 25 Januar 2017, 23:42:23
@ralf9
Du bist der Beste !!!
get sduino raw e
hat zum Erfolg geführt!
Musste vorher nur D11 abziehen damit sich der "get" Befehl an die Oberfläche traut (der SINGALduino sich initialisieren lässt).

Hatte ich im Forum schonmal gelesen. Hatte aber ausversehen "set" anstelle von "get" eingegeben, da kam dann nur eine Fehlermeldung.
Was passiert bei diesem Befehl genau?

Der SIGNALduino sendet noch auf 433,92Mhz (geringfügig niedriger), jetzt muss ich mal schauen/nachlesen wie ich die 433,42Mhz einstelle.

Danke für die superschnelle Hilfe (ich geht nach dem Erfolg jetzt erst mal ins Bett)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Januar 2017, 23:50:31
mit dem factory reset wird das EEPROM mit den richtigen Werten initalisiert und dann ein reset des CC1101 durchgeführt.
Du kannst Dir das EEPROM mit "get sduino r00n" anschauen.

Wir hatten so einen Fall schon mal, wir konnten es aber nicht nachvollziehen. Evtl gibt es ganz seltene Fälle wo der automatische factory reset am Anfang nicht klappt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 26 Januar 2017, 00:13:54
Habe nach einigem suchen nicht rausbekommen, wie man per FHEM die Frequenz des SIGNALduino-CC1101 verändern kann.
@Ralf9: vielleicht hast Du einen Tipp / einen Link wo das beschrieben ist.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 Januar 2017, 00:19:54
Zitat von: Ralf9 am 25 Januar 2017, 23:50:31
Wir hatten so einen Fall schon mal, wir konnten es aber nicht nachvollziehen. Evtl gibt es ganz seltene Fälle wo der automatische factory reset am Anfang nicht klappt.

Ich denke ich habe den Fehler in der Firmware gefunden
in der RF_RECEIVER.ino Zeile 876
https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/RF_Receiver/RF_Receiver.ino

Damit dürfte sich das Verhalten erklären. Wenn beim ersten einschalten des nano der CC1101 nicht erkannt wird, wird das EEPROM als initialisiert markiert, aber es wird kein factory reset durchgeführt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 Januar 2017, 00:23:30
Zitat von: RaspII am 26 Januar 2017, 00:13:54
Habe nach einigem suchen nicht rausbekommen, wie man per FHEM die Frequenz des SIGNALduino-CC1101 verändern kann.
@Ralf9: vielleicht hast Du einen Tipp / einen Link wo das beschrieben ist.

set sduino cc1101_freq

Dies brauchst Du beim Somfy aber nicht machen, da wird beim Senden die Frequenz automatisch geändert.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 26 Januar 2017, 07:16:20
D.h. der SIGNALduino empfangt dann immer auf der Stamdardfrequenz von 433,92Mhz, das wäre genau das gewünschte Verhalten .
Ich teste das mal heute abend.

Dann habe ich noch eine Frage:
Bei mir ändert sich der Zustand der den Somfy Devices zugeordneten Icons nicht unmittelbar nach Druck von "auf" oder "ab", sondern nur wenn ich einen Refresh der Seite mache. Weiss jemand warum das so ist?


Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 26 Januar 2017, 07:55:50
Das hat irgendwas mit longpoll zu tun. Ist im Wiki bestimmt beschrieben. :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 26 Januar 2017, 11:36:14
Richtig.
Bei mir unter dem Abschnitt:
define WEB FHEMWEB 8083 global

in der fhem. cfg zu finden.

attr WEB longpollSVG 1
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 26 Januar 2017, 19:46:17
Zitat von: Ralf9 am 26 Januar 2017, 00:23:30
set sduino cc1101_freq

Dies brauchst Du beim Somfy aber nicht machen, da wird beim Senden die Frequenz automatisch geändert.

Gruß Ralf

Das automatische Ändern der Frequenz beim Senden tut bei mir nicht. Bestimmt habe ich wieder ein Attribut etc. vergessen (switch_rfmode 0 oder 1 bringt auch nichts)
Irgendwie steh ich auf dem Schlauch und finde auch in der Commandref und Wiki nichts.
Ich brauche hier Eure Hilfe.
Gerne mache ich danach auch einen Update der Wiki  8)

Hier noch meine aktuelle Konfig:
define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
attr sduino flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino hardware nanoCC1101

define RolloLinks SOMFY 5F462F A9 00AD
attr RolloLinks IODev sduino
attr RolloLinks devStateIcon open:fts_shutter_10 stop:fts_shutter_30 closed:fts_shutter_100
attr RolloLinks eventMap on:down stop:stop off:up
attr RolloLinks room SOMFY
attr RolloLinks switch_rfmode 1               #### Das war nur ein Test
attr RolloLinks webCmd down:stop:up

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 Januar 2017, 20:40:14
Zitat von: RaspII am 26 Januar 2017, 19:46:17
Das automatische Ändern der Frequenz beim Senden tut bei mir nicht. Bestimmt habe ich wieder ein Attribut etc. vergessen (switch_rfmode 0 oder 1 bringt auch nichts)
Irgendwie steh ich auf dem Schlauch und finde auch in der Commandref und Wiki nichts.
Ich brauche hier Eure Hilfe.

Wie ist bei Dir das log beim Senden?

Ich habe bei mir mal mit Deinem "define RolloLinks SOMFY 5F462F A9 00AD" gesendet:

2017.01.26 20:29:03.165 5: sduinoE/write: adding to queue sendMsg P43#A98A8A27084E11#R6
2017.01.26 20:29:03.165 5: sduinoE: sendmsg msg=P43#A98A8A27084E11#R6
2017.01.26 20:29:03.165 5: sduinoE: sendmsg Preparing manchester protocol=43, repeats=0, clock=640 data=A98A8A27084E11
2017.01.26 20:29:03.165 4: sduinoE/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;
2017.01.26 20:29:03.266 5: sduinoE SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;
2017.01.26 20:29:03.276 4: sduinoE SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;
2017.01.26 20:29:03.989 4: sduinoE/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;ccreg write back 10B07127C4
2017.01.26 20:29:03.989 5: sduinoE/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;ccreg write back 10B07127C4
2017.01.26 20:29:03.989 4: sduinoE/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A98A8A27084E11;F=10AB85550A;ccreg write back 10B07127C4


Mit  F=10AB85550A  wird die Frequenz und Datenrate beim Senden geändert

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 26 Januar 2017, 22:14:17
@Ralf:
Habe diesen Fehler gefunden.
Ich hatte einen FHEM Update gemacht. Mir war nicht klar, dass dann wohl der voangegangene Update:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
überschrieben wird.
Habe obigen Update jetzt wiederholt und schon funktioniert es (die Frequenz liegt mit dem grünen Modul bei 433,41 Mhz, ich denke das sollte gehen). Testen kann ich allerdings mit den echten Rolläden erst nächste Woche.

Man kann FHEM wohl beibringen, dass nach einem "FHEM Update" auch immer obiger Update mit ausgeführt wird, falls mir jemand eine Schnellbleiche geben kann: immer zu.

Jetzt bleibt nur noch das Problem mit dem Update der ICONs (attr WEB longpollSVG 1 hat nichts gebracht).
Oder senden die Rollos eine Quittung und erst dann wird die Oberfläche upgedatet?

Danke für die bisherigen Tipps, ohne Euch wäre ich verloren.
Hatte ich eigentlich schon erwähnt, dass ich das Konzept des SIGNALduino richtig Klasse finde (z.B. die Schnittstelle zur Firmware)
Dickes Lob an alle Beteiligten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 26 Januar 2017, 22:17:01
Zitat von: RaspII am 26 Januar 2017, 22:14:17
Man FHEM wohl beibringen, dass nach einem "FHEM Update" auch immer obiger Update mit ausgeführt wird, falls mir jemand eine Schnellbleiche geben kann: immer zu.

Das geht sogar:
https://wiki.fhem.de/wiki/Update#Repository-Verwaltung

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 26 Januar 2017, 22:47:18
Hat geklappt -> Danke
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 Januar 2017, 22:48:17
Zitat von: RaspII am 26 Januar 2017, 22:14:17
Jetzt bleibt nur noch das Problem mit dem Update der ICONs (attr WEB longpollSVG 1 hat nichts gebracht).

Du mußt Dich noch ein wenig mit den Attributen drive-up-time-... und drive-down-time-... beschäftigen, dann wird das auch noch was.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 27 Januar 2017, 09:23:01
Hab zwar nicht verstanden wo da der Zusammenhang ist, werde mich aber übers WE einlesen.
(Bei der Entwicklung der Kopp Implementierung habe ich mich am SOMFY.pm Modul orientiert,  trotzdem reagiert die Oberfläche unterschiedlich)
Ich melde mich mit dem Ergebnis nach dem WE

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 27 Januar 2017, 15:28:46
Hallo Sidey, Ralf,

zur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden.  Perfmon läuft bei mir mit und zeigt es mir an.
Wiki: Modul perfmon überwacht das Antwortzeitverhalten von FHEM und erzeugt einen Eintrag in der Logdatei, wenn die Abarbeitung eines Ereignisses länger als eine Sekunde (1000 Millisekunden) dauert.
Sytem ist ein Odroid-C1 mit 2x SignalduinoCC1101 für 433 und 868 MHz. Sonst keine anderen Module. Ich habe den Odroid schon einmal neu aufgesetzt. Heute mach ich es noch einmal. DBLog läuft für die Logspeicherung in eine MySQL DB auf einem NAS.

Im Verdacht habe ich einen THR128 (siehe Bild). Der sendet diesen Code. Dieser wird noch nicht erkannt und die weitere Verarbeitung dauert zu lange ??:

2017.01.27 14:32:19 5: SD433: applying filterfunc SIGNALduino_compPattern
2017.01.27 14:32:19 4: SD433/msg READ: MC;LL=-2729;LH=3131;SL=-1255;SH=1666;D=DF5BBE2A;C=1463;L=31;R=47;
2017.01.27 14:32:19 4: SD433: Found manchester Protocol id 18 clock 1463 RSSI -50.5 -> OSV1
2017.01.27 14:32:19 5: SD433: extracted data 11011111010110111011111000101010 (bin)
2017.01.27 14:32:19 5: SD433: OSV1 protocol converted to hex: (0820A441D5) with length (8) bits


Heute hatte ich es, das zweimal solche Ausgaben kamen (siehe Anlage). Nach einer Weile fängt er sich wieder.
Die Daten habe ich mit einem CC110L empfangen.
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38.
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Version:
fhem.pl            13210 2017-01-23 17:16:54Z rudolfkoenig
98_autocreate.pm   11984 2016-08-19 12:47:50Z rudolfkoenig
14_CUL_TCM97001.pm 12994 2017-01-07 07:49:53Z bjoernh
93_DbLog.pm        13193 2017-01-22 20:00:41Z DS_Starter
91_eventTypes.pm   11984 2016-08-19 12:47:50Z rudolfkoenig
01_FHEMWEB.pm      13201 2017-01-23 09:56:46Z rudolfkoenig
92_FileLog.pm      13152 2017-01-20 09:04:34Z rudolfkoenig
14_Hideki.pm       14395 2017-01-23 18:00:00Z v3.3.1-dev
91_notify.pm       13207 2017-01-23 13:55:25Z rudolfkoenig
41_OREGON.pm       34476 2016-12-04 13:00:00Z dev
No Id found for 99_perfmon.pm
14_SD_WS09.pm      16018 2016-07-11 10:10:10Z pejonp
00_SIGNALduino.pm  10484 2017-01-22 15:00:00Z v3.3.1-dev
99_SUNRISE_EL.pm   12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm          12482 2016-11-01 09:25:59Z rudolfkoenig
98_telnet.pm       13169 2017-01-21 13:28:14Z rudolfkoenig
99_Utils.pm        11984 2016-08-19 12:47:50Z rudolfkoenig
19_VBUSIF.pm       12980 2017-01-06 12:36:39Z Tobias.Faust
98_version.pm      11987 2016-08-19 17:13:41Z markusbloch

Vielleicht ist diese Verhalten ja schon bekannt oder andere haben so ein Verhalten auch schon festgestellt. Es funktioniert soweit alles, nur das die Anzeige in FHEM machmal etwas dauert.

Jörg
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Januar 2017, 19:11:47
Zitatzur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden.  Perfmon läuft bei mir mit und zeigt es mir an.
Wiki: Modul perfmon überwacht das Antwortzeitverhalten von FHEM und erzeugt einen Eintrag in der Logdatei, wenn die Abarbeitung eines Ereignisses länger als eine Sekunde (1000 Millisekunden) dauert.

Mir sind im log recht viele unsinnige und unplausible Nachrichten aufgefallen.
@Sidey
Ist da evtl noch ein Bug in der Firmware? Kannst Du eine Abfrage einbauen, damit solche unplausible Nachrichten nicht übertragen erden?

2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=77777777777777777777777777777777775;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=77777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=7777777777777777777777777777777777775;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=7777777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=777777777777777777777777777777777777775;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=777777777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=77777777777777777777777777777777777777775;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=77777777777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:27 4: SD433/msg READ: MS;P7=-32001;D=7777777777777777777777777777777777777777775;CP=-1;SP=3;R=6;
2017.01.27 14:32:28 4: SD433/msg READ: MS;P7=-32001;D=7777777777777777777777777777777777777777777;CP=-1;SP=3;R=6;
2017.01.27 14:32:28 4: SD433/msg READ: MS;P7=-32001;D=777777777777777777777777777777777777777777775;CP=-1;SP=3;R=6;

2017.01.27 14:32:46 4: SD433/msg READ: MS;P0=-499;P4=-32001;D=0000000000000000000000000000000000000004444444444;CP=-1;SP=3;R=51;
2017.01.27 14:32:46 4: SD433/msg READ: MS;P0=-499;P4=-32001;D=000000000000000000000000000000000000000444444444442;CP=-1;SP=3;R=51;
2017.01.27 14:32:46 4: SD433/msg READ: MS;P0=-499;P4=-32001;D=000000000000000000000000000000000000000444444444444;CP=-1;SP=3;R=51;
2017.01.27 14:32:46 4: SD433/msg READ: MS;P0=-499;P4=-32001;D=00000000000000000000000000000000000000044444444444441;CP=-1;SP=3;R=51;
2017.01.27 14:32:46 4: SD433/msg READ: MS;P0=-499;P4=-32001;D=00000000000000000000000000000000000000044444444444444;CP=-1;SP=3;R=51;
SD433/msg READ: MS;P7=-32001;D=777777777777777777777777777777777;CP=-1;SP=3;R=51;
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 Januar 2017, 20:06:03
Ja, das ist ein Bug.
Ich hab noch nicht raus, wieso das den Nachrichtenpuffer nicht resettet, da beide Werte ja das gleiche Vorzeichen haben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 Januar 2017, 23:30:28
Hallöchen,

Zitat von: pejonp am 27 Januar 2017, 15:28:46
zur Zeit reagiert mein FHEM etwas träge. Ursache habe ich noch nicht so richtig gefunden.  Perfmon läuft bei mir mit und zeigt es mir an.

hmm, vielleicht hilft die apptime noch etwas weiter.
Ich habe mal eine deiner Nachrichten, die 5 Sekunden gebraucht hat bei mir durchgejagt:


2017.01.27 23:15:21.531 3: dummyDuino: Unknown code 0820CC419D, help me!
2017.01.27 23:15:21.497 5: dummyDuino: dispatch 0820CC419D
2017.01.27 23:15:21.492 5: dummyDuino: converted Data to (0820CC419D)

2017.01.27 23:15:21.491 5: dummyDuino: OSV1 protocol converted to hex: (0820CC419D) with length (8) bits
2017.01.27 23:15:21.489 5: dummyDuino: extracted data 11011111001100111011111001100010 (bin)
2017.01.27 23:15:21.488 4: dummyDuino: Found manchester Protocol id 18 clock 1466 RSSI -56.5 -> OSV1
2017.01.27 23:15:21.484 4: dummyDuino/msg get raw: MC;LL=-2712;LH=3152;SL=-1252;SH=1681;D=DF33BE62;C=1466;L=31;R=35;


Das dauert auf einem Raspberry Pi 1 in diesem Beispiel 50 millisekunden. In einem anderen Versuch hängt da auch was etwa 1,6 Sekunden.

2017.01.27 23:21:37.817 3: dummyDuino: Unknown code 0820CC419D, help me!
2017.01.27 23:21:36.207 5: dummyDuino: dispatch 0820CC419D
2017.01.27 23:21:36.202 5: dummyDuino: converted Data to (0820CC419D)


Das Log ist bei dir nicht umgedreht, aber es dauert fast 5 Sekunden:


2017.01.27 14:32:48 4: SD433/msg READ: MC;LL=-2728;LH=3136;SL=-1262;SH=1668;D=DF33BE62;C=1465;L=31;R=37;
2017.01.27 14:32:48 4: SD433: Found manchester Protocol id 18 clock 1465 RSSI -55.5 -> OSV1
2017.01.27 14:32:48 5: SD433: extracted data 11011111001100111011111001100010 (bin)
2017.01.27 14:32:48 5: SD433: OSV1 protocol converted to hex: (0820CC419D) with length (8) bits
2017.01.27 14:32:48 5: SD433: converted Data to (0820CC419D)
2017.01.27 14:32:48 5: SD433: dispatch 0820CC419D
2017.01.27 14:32:53 3: SD433: Unknown code 0820CC419D, help me!


Die Zeit vergeht nach dem Aufruf von Dispatch() (fhem.pl:3475)  und vor (fhem.pl:3533).
Zwischen diesen Zeilen werden die Clientmodule durchprobiert.

Irgendein client Modul lässt sich vielleicht zeit?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 28 Januar 2017, 00:38:30
Ich denke es ist am sinnvollsten das OSV1 vorläufig dem Modul SIGNALduino_un zuzuordnen

preamble => 'u18#',
modulematch     => '^u18#[0-9A-F].*',


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 28 Januar 2017, 11:24:48
Zitat von: Ralf9 am 26 Januar 2017, 22:48:17
Du mußt Dich noch ein wenig mit den Attributen drive-up-time-... und drive-down-time-... beschäftigen, dann wird das auch noch was.

Gruß Ralf

Hab ich gemacht und schon klappts (ohne Longpoll)
Ich glaube ich habe das Prinzip verstanden, der Zustand ändert sich über die Zeit  :)
Was ist der Unterschied zwischen den Attributen drive-up-time-to-100 und drive-up-time-to-open ?

Nachtrag:
Was mir noch fehlt, ist das sich meine ICONs (mit denen ich von FHEM aus die Rolläden steure) auch an den Status ändern, wenn via Somfy Fernbedienung (also anderer HEX Code) eine entsprechende Taste gedrückt ist. Ich habe da schon einige Infos gefunden wenn man den CUL zum senden und den FHEMduino zum Empfangen nimmt, verstanden habe ich das aber wenn ich ehrlich bin nicht.

Ansonsten denke ich das reicht fürs erste, jetzt geht es an die Praxis (mal schaun ob das Reichweitenproblem weg ist)

Wenn meine Implementierung jetzt in der Praxis funktioniert, würde ich die Erkenntnisse gerne in der Wiki dokumentieren.
Am besten geeignet finde ich hierfür die SOMFY Wiki,
https://wiki.fhem.de/wiki/SOMFY (https://wiki.fhem.de/wiki/SOMFY)
dort könnte man z.B. einen Link auf "SOMFY via SIGNALduino" setzten und diese neue Seite anlegen.
Diese Seite könnte man auch in der SINGALduino WIKI verlinken.
Was meint Ihr?

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 12:49:20
Hallo,

die FW - SIGNALduino ist bisher nur für den Arduino Nano entwickelt. Wie ist der Stand für den Arduino Micro.
" ... muss die Firmware selbst compilieren."" Woher bekomme ich zum compilieren die Sourcen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 28 Januar 2017, 12:52:44
Source hier unter https://wiki.fhem.de/wiki/SIGNALduino (https://wiki.fhem.de/wiki/SIGNALduino)
Versteckt unter "github". unter https://github.com/RFD-FHEM/RFFHEM/tree/master (https://github.com/RFD-FHEM/RFFHEM/tree/master)
den passenden "Branch" auswählen.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 13:33:14
Danke,
soweit war ich auch schon und nun "hapert" es  das richtige zu finden.
Die Sourcen werden für den ATmega32u4 benötigt und nicht ATMega328 :o oder ich sehe langsam gar nicht mehr durch  ;D
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 Januar 2017, 13:57:55
Den pro Micro gibt es mit atmega328 und atmega168.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 14:04:31
Hallo HomeAuto_User,

wenn du den ATmega32u4 hast,  müstest du in der IDE den Leonardo auswählen. Steht so beim radino CC1101 433 MHz. Bei mir konnte ich es kompilieren. Ob es geht kann ich nicht sagen.

Eigenschaften (radino CC1101 433 MHz):

    Arduino-compatible (Arduino Micro / Leonardo)
    ATmega32U4 High-Performance Low-Power Microcontroller
    CC1101 mit 433 MHz Frontend
    15 GPIOS (5 PWM, 5 Analog IN)
    I²C, SPI, UART
    USB (HID Keyboard & Mouse, virtual UART)

Beim  radino32 CC1101 433 MHz - Modul ist ja ein STM32 verbaut, da wird es etwas schwieriger.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 15:26:29
Zitat von: pejonp
Hallo HomeAuto_User,

... Bei mir konnte ich es kompilieren. Ob es geht kann ich nicht sagen.

hier klappt es leider nicht.

sketch/TimerOne.h:58: undefined reference to `TimerOne::clockSelectBits'
sketch/TimerOne.h:59: undefined reference to `TimerOne::pwmPeriod'
...

Ich muss ehrlicher weise auch sagen, Arduino IDE ist auch Neuland.

LG
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 18:06:48
Hallo HomeAuto_User,

entpacke einmal die angehangene 7z-Datei und öffne sie mit der Arduino IDE 1.6.5.
Ich habe alle h- und cpp-Dateien aus den Unterverzeichnissen in das eine gelegt. Ist nicht schön, macht man ansonsten auch nicht, aber so braucht man nicht alle Libs installieren.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 18:21:03
Zitat von: pejonp am 28 Januar 2017, 18:06:48
Hallo HomeAuto_User,

entpacke einmal die angehangene 7z-Datei und öffne sie mit der Arduino IDE 1.6.5.
Ich habe alle h- und cpp-Dateien aus den Unterverzeichnissen in das eine gelegt. Ist nicht schön, macht man ansonsten auch nicht, aber so braucht man nicht alle Libs installieren.

pejonp
Besten Dank, ja, mein Fehler. Ich vergaß ein Teil der Datein und hatte nicht alle zusammen.
Es lässt sich nun kompilieren und nun muss ich mich nur an die PINs machen, da sich welche geändert haben in meinem Falle.  ??? Nur wo.  :-[ Muss ich durchblicken bei den Sketches
... wieder ein Schritt weiter  :D
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 18:29:11
die PIN stehen in der  cc1101.h  und RF_Receiver.ino.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 18:34:27
Zitat von: pejonp am 28 Januar 2017, 18:29:11
die PIN stehen in der  cc1101.h  und RF_Receiver.ino.

*Daumen*  :D
Ich muss nur die Namen nun vergleichen und wie eine Gegenüberstellung schaffen.

Finden muss ich nun:

SPI_PORT
SPI_DDR
SPI_IN
SPI_SS
SPI_MISO
SPI_MOSI
SPI_SCLK

CC1100_CS_DDR
CC1100_CS_PORT
CC1100_CS_PIN

CC1100_OUT_DDR
CC1100_OUT_PORT
CC1100_OUT_PIN
CC1100_OUT_IN

CC1100_IN_DDR
CC1100_IN_PORT
CC1100_IN_PIN
CC1100_IN_IN

CC1100_INT
CC1100_INTVECT
CC1100_ISC
CC1100_EICR

LED_DDR
LED_PORT
LED_PIN

MARK433_PORT
MARK433_PIN
MARK433_BIT

MARK915_PORT
MARK915_PIN
MARK915_BIT

wenn diese angepasst werden kann ich nach der kompilierung den Test wagen und somit auf meinem radino CC1101 die FW drauf brennen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 18:55:34
als erstes müssten die PIN in der CC1101.h angepaßt werden. (Laut Schaltbild radino cc1101)

namespace cc1101 {

   #define csPin    8  //10   // CSN  out
   #define mosiPin  16 //11   // MOSI out
   #define misoPin  14 //12   // MISO in
   #define sckPin   15  //13   // SCLK out

GD02 und GD00 stehen  ich in der *.ino. PIN 9 für die LED paßt so nicht, muß andere Pin werden.

#define PROGNAME               "RF_RECEIVER"
#define PROGVERS               "3.3.1-dev"
#define VERSION_1               0x33
#define VERSION_2               0x1d

#ifdef CMP_CC1101
// #define PIN_LED               9  //passt so nicht
  #define PIN_SEND              9 //3   // gdo0Pin TX out
#else
  #define PIN_LED               13    // Message-LED
  #define PIN_SEND              11

#endif
#define PIN_RECEIVE            7 //2
#define BAUDRATE               57600
#define FIFO_LENGTH            50
#define DEBUG               1


Du kannst es ja mal so versuchen. Da ich so ein Teil nicht habe ohne Garantie.

pejonp   
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 18:58:11
Das ähnelt ja der Doku  ;D Herstellerinfo - Seite 3 (http://wiki.in-circuit.de/images/4/49/305000077A_radino_CC1101.pdf)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 19:00:51
Ja, ist Absicht. Ist die Doku, aber Seite 6. ;-)

LED vielleicht auf Pin 4. Halt Pin 4 ist schlecht, schon belegt bei 433MHz-Modul. Pin 6.

Aber ich glaube es wird noch nicht funktionieren da Pin 7 und 9 keinen Interrupt auslösen. Gibt es zu deinem radino Beispiele. Vielleicht ist da so etwas bei.

Uno, Nano, Ethernet:
    Inter. 0 = Digitaler Pin 2
    Inter. 1 = Digitaler Pin 3

Leonardo:
    Inter. 0 = Digitaler Pin 3
    Inter. 1 = Digitaler Pin 2
    Inter. 2 = Digitaler Pin 0
    Inter. 3 = Digitaler Pin 1

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 20:32:28
Ich bin auf der Suche.
Die PIN´s welche wir bisher in der Mache hatten können auf jedenfall durch Händlerdokumentation verifiziert werden.

Vielleicht wird man hier (http://wiki.in-circuit.de/index.php5?title=radino_Library) fündig. Da wurden Module von denen mit Arduino behandelt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 21:19:57
Steht vielleicht hier (https://github.com/GreyGnome/PinChangeInt) oder hier (https://propaneandelectrons.com/blog/int6-on-arduino-leonardo-atmega32u4) bzw. hier (http://rcarduino.blogspot.de/2013/04/the-problem-and-solutions-with-arduino.html) die Lösung?

Im letzten Link ist davon die Rede, ATMega32u4 - Leonardo and Micro.(The 8-bit Arduino boards are based on one of three related chips)
Da gehe ich davon aus

Board                    int.0 int.1 int.2 int.3 int.4 int.5
Leonardo, Micro     3       2       0       1
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 Januar 2017, 21:39:27
Hi,

ich habe die Zuordnung der Pins gefunden:
http://wiki.in-circuit.de/images/4/49/305000077A_radino_CC1101.pdf (http://wiki.in-circuit.de/images/4/49/305000077A_radino_CC1101.pdf)

Auf Seite 5 stehts und auf Seite 6 ist eine super Zeichnung:

Arduino Pin #7: CC1101-GDO2
Arduino Pin #8: CC1101-SS Signal: CS
Arduino Pin #9: CC1101-GDO0
Arduino Pin #14: CC1101-SO (MISO)
Arduino Pin #15: CC1101-SCLK
Arduino Pin #16: CC1101-SI (MOSI)


Demnach musst Du in RF_receive.ino den Sende und empfangs Pin anpassen:
  #define PIN_SEND              9   // gdo0Pin TX out   
  #define PIN_RECEIVE         7

cc1101.h muss auch angepasst werden:
   #define csPin   8   // CSN  out
   #define mosiPin 16   // MOSI out
   #define misoPin 14   // MISO in
   #define sckPin  15 // SCLK out

Das war der einfache Teil. Vielleicht geht es dann auch schon.
Ganz sicher bin ich mit wegen dem Interrupt auf Pin7 nicht, aber man findet hinweise, dass die Funktion attatchInterrupt() den  Interrupt nicht unterstützt.
https://propaneandelectrons.com/blog/int6-on-arduino-leonardo-atmega32u4 (https://propaneandelectrons.com/blog/int6-on-arduino-leonardo-atmega32u4)


Wenn das mit dem Interrupt auf Pin#7 nicht mit attatchInterrupt() klappt, dann muss die Funktion
enableReceive und disableReceive angepasst werden, in dem dort die Register gesetzt werden.

Die Funktion handleInterrupt aus einer Funktion ISR(INT6_vect)  aufgerufen werden.
In etwa so:

ISR(INT6_vect) {
handleInterrupt ();
}


Ich kann es leider nicht auf einem ATMega32U4 ausprobieren, da mir bei diesem der USB Port abgebrochen ist.  :(
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 21:54:57
Hi sidey,
So sahen doch meine Daten aus. mosi und miso vertauscht.😉

Schaut mal hier wird der radino für den cul genutzt. In der board.h  sind die Belegungen.
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CSM_RADINO/

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 22:28:05
Zitat von: pejonp am 28 Januar 2017, 21:54:57
Hi sidey,
So sahen doch meine Daten aus. mosi und miso vertauscht.😉

Schaut mal hier wird der radino für den cul genutzt. In der board.h  sind die Belegungen.
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CSM_RADINO/

pejonp
Wenn es um die Belegung geht, dann geht folgendes aus meiner CUL FW  ;D hervor.
Diese geht mit dem CC_radino perfekt.  8)

#  define PB0 PORTB0
#  define PB1 PORTB1
#  define PB2 PORTB2
#  define PB3 PORTB3
#  define PB6 PORTB6
#  define PD2 PORTD2
#  define PD3 PORTD3
#endif  // CUL_V3

#define SPI_PORT      PORTB
#define SPI_DDR         DDRB
#define SPI_SS         PB0
#define SPI_MISO      PB3
#define SPI_MOSI      PB2
#define SPI_SCLK      PB1

#if defined(CUL_V3)
#  define CC1100_CS_DDR         DDRB
#  define CC1100_CS_PORT        PORTB
#  define CC1100_CS_PIN         4
#  define CC1100_OUT_DDR        DDRB
#  define CC1100_OUT_PORT       PORTB
#  define CC1100_OUT_PIN        5
#  define CC1100_OUT_IN         PINB
#  define CC1100_IN_DDR         DDRE
#  define CC1100_IN_PORT        PINE
#  define CC1100_IN_PIN         6
#  define CC1100_IN_IN          PINE
#  define CC1100_INT         INT6
#  define CC1100_INTVECT        INT6_vect
#  define CC1100_ISC         ISC60
#  define CC1100_EICR           EICRB
#  define LED_DDR               DDRB
#  define LED_PORT              PORTB
#  define LED_PIN               0
#endif

#define MARK433_PORT            PORTD
#define MARK433_PIN             PIND
#define MARK433_BIT             4
#define MARK915_PORT            DDRB
#define MARK915_PIN             PORTB
#define MARK915_BIT             7

nur die Interrupt Sache ist nun noch offen.

Wieso nun diese FW?
Weil bei den anderen keine Sensoren von Hideki unterstützt werden und die SignalFW auf das "Versprechen" auf Herz und Nieren getestet werden muss.  ::)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 Januar 2017, 22:29:51
Hast Du meinen Vorschlag für die Pins schon getestet?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 22:31:57
Zitat von: Sidey am 28 Januar 2017, 22:29:51
Hast Du meinen Vorschlag für die Pins schon getestet?

Erst einmal den Getränkenachschub sichern / Programmer starten und dann werde ich umgehend gleich berichten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 23:14:36
Wäre zu schön gewesen, nichts geht.
Es wird schonmal nicht alles korrekt ausgelesen an Details in Linux.

Bsp:
[88142.758974] usb 1-1.2: new full-speed USB device number 13 using dwc_otg
[88142.838984] usb 1-1.2: device descriptor read/64, error -32
[88143.028968] usb 1-1.2: device descriptor read/64, error -32
[88143.218966] usb 1-1.2: new full-speed USB device number 14 using dwc_otg
[88143.298963] usb 1-1.2: device descriptor read/64, error -32
[88143.488968] usb 1-1.2: device descriptor read/64, error -32
[88143.678971] usb 1-1.2: new full-speed USB device number 15 using dwc_otg
[88144.098983] usb 1-1.2: device not accepting address 15, error -32
[88144.179046] usb 1-1.2: new full-speed USB device number 16 using dwc_otg
[88144.598995] usb 1-1.2: device not accepting address 16, error -32
[88144.599113] usb 1-1-port2: unable to enumerate USB device

Sozusagen "Müll"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 23:33:45
Hallo,

anscheinend wird dein USB-Gerät nicht richtig unter linux erkannt. Hat aber nicht mit dem Sketch zu tun. Wie hast du den den radino an linux angebunden ? USB-Adapter (siehe Bild) oder anderen Arduino... ?
was zeigt den lsusb an ?

pejonp

PS: diese Sachen schon versucht. radino & Linux (steht ganz unten) --> (http://wiki.in-circuit.de/index.php5?title=radino_common_problems)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 28 Januar 2017, 23:40:14
Zitat von: HomeAuto_User am 28 Januar 2017, 23:14:36
Wäre zu schön gewesen, nichts geht.
Es wird schonmal nicht alles korrekt ausgelesen an Details in Linux.

Bsp:
[88142.758974] usb 1-1.2: new full-speed USB device number 13 using dwc_otg
[88142.838984] usb 1-1.2: device descriptor read/64, error -32
[88143.028968] usb 1-1.2: device descriptor read/64, error -32
[88143.218966] usb 1-1.2: new full-speed USB device number 14 using dwc_otg
[88143.298963] usb 1-1.2: device descriptor read/64, error -32
[88143.488968] usb 1-1.2: device descriptor read/64, error -32
[88143.678971] usb 1-1.2: new full-speed USB device number 15 using dwc_otg
[88144.098983] usb 1-1.2: device not accepting address 15, error -32
[88144.179046] usb 1-1.2: new full-speed USB device number 16 using dwc_otg
[88144.598995] usb 1-1.2: device not accepting address 16, error -32
[88144.599113] usb 1-1-port2: unable to enumerate USB device

Sozusagen "Müll"
In der Datei /boot/cmdline.txt folgendes anhängen: dwc_otg.speed=1
Ist ein Problem mit den FTDI Adaptern am Raspberry. Hatte die gleichen Probleme ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 23:40:28
HiHo,
angebunden ist der radino via USB. Der ganze befindet sich auf einem "Trägerboard" (http://shop.in-circuit.de/product_info.php?cPath=22_28&products_id=170). | Schema (http://wiki.in-circuit.de/images/6/62/610000305B_Layoutschaltplan_radino_USB_Stick.pdf)

lsusb
Bus 001 Device 012: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 011: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

???
USB Unterstützung im Sketch? :o
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 28 Januar 2017, 23:45:30
Zitat von: prodigy7 am 28 Januar 2017, 23:40:14
In der Datei /boot/cmdline.txt folgendes anhängen: dwc_otg.speed=1
Ist ein Problem mit den FTDI Adaptern am Raspberry. Hatte die gleichen Probleme ...
Kann das auch eine Rolle spielen, wenn der selbige Aufbau nur mit anderer FW funktioniert?
Versuchen werde ich es.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 28 Januar 2017, 23:48:23
diese Sachen schon versucht. radino & Linux (steht ganz unten) --> (http://wiki.in-circuit.de/index.php5?title=radino_common_problems)

Hast du jetzt 4 Geräte im Einsatz ?? Hast du nur Atmel oder STM32 ?

- mod. CC_Radino mit USB (433mhz) | radino32 CC1101+Trägerboard
- mod. CC_Radino mit USB (868mhz) | radino32 CC1101+Trägerboard

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 00:11:20
Zitat von: pejonp am 28 Januar 2017, 23:48:23
diese Sachen schon versucht. radino & Linux (steht ganz unten) --> (http://wiki.in-circuit.de/index.php5?title=radino_common_problems)

Hast du jetzt 4 Geräte im Einsatz ?? Hast du nur Atmel oder STM32 ?
pejonp
Die Sache aus dem Link habe ich probiert, keine Wirkung.

Ich habe derzeit 1 Gerät (433Mhz).
Das Gerät umfasst die Trägerplatine (http://shop.in-circuit.de/product_info.php?cPath=22_28&products_id=170), die Platine radino CC1101 (http://shop.in-circuit.de/product_info.php?cPath=22_27&products_id=33) auf dieser unter einem Blechdeckel der Arduino nano + CC1101 (http://wiki.in-circuit.de/index.php5?title=radino_CC1101) implimentiert sind.

Hinweis: mit einer CUL FW läuft alles, es geht nun um die Umsetzung via Arduino, weil da aktuell für diese Kombination nichts existiert

PS: Signatur angepasst im Profil, das es zu keinem Missverständnis kommt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 00:14:00
ich tippe mal auf bootloader...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 00:21:01
Zitat von: Sidey am 29 Januar 2017, 00:14:00
ich tippe mal auf bootloader...
Nach der kompilierung von Arduino werden 2 hex-Files erstellt.

RF_Receiver.ino.leonardo.hex
RF_Receiver.ino.with_bootloader.leonardo.hex

Wenn ich das ohne Bootloader flashe, so sollte mein alter Bootloader ja nicht angegegriffen werden.
Den Test mit dem Bootloader habe ich noch nicht geflasht, da ich aufpassen muss auf die gesetzten Bits, sonst funkioniert die CUL FW nicht mehr.
Die Bootloader sollten ja unterschiedlich "machbar" sein.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 00:22:27
ich habe bis jetzt immer den Standard arduino bootloader verwendet.

Keine Ahnung, ob die Firmware mit einem anderen bootloader funktioniert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 00:52:09
Zitat von: Sidey am 29 Januar 2017, 00:14:00
ich tippe mal auf bootloader...
Der Test wurde nun auch vollzogen. Nichts.

dmesg | grep usb
[    1.808496] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
[    1.888476] usb 1-1.4: device descriptor read/64, error -71
[    2.078538] usb 1-1.4: device descriptor read/64, error -71
[    2.268592] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
[    2.348530] usb 1-1.4: device descriptor read/64, error -71
[    2.538525] usb 1-1.4: device descriptor read/64, error -71
[    2.728524] usb 1-1.4: new full-speed USB device number 6 using dwc_otg
[    3.158505] usb 1-1.4: device not accepting address 6, error -71
[    3.248637] usb 1-1.4: new full-speed USB device number 7 using dwc_otg
[    3.319758] usbcore: registered new interface driver brcmfmac
[    3.668576] usb 1-1.4: device not accepting address 7, error -71
[    3.668877] usb 1-1-port4: unable to enumerate USB device
[ 2557.940879] usb 1-1.4: new full-speed USB device number 8 using dwc_otg
[ 2558.020877] usb 1-1.4: device descriptor read/64, error -71
[ 2558.210875] usb 1-1.4: device descriptor read/64, error -71
[ 2558.400877] usb 1-1.4: new full-speed USB device number 9 using dwc_otg
[ 2558.480925] usb 1-1.4: device descriptor read/64, error -71
[ 2558.670880] usb 1-1.4: device descriptor read/64, error -71
[ 2558.860883] usb 1-1.4: new full-speed USB device number 10 using dwc_otg
[ 2559.280887] usb 1-1.4: device not accepting address 10, error -71
[ 2559.360888] usb 1-1.4: new full-speed USB device number 11 using dwc_otg
[ 2559.780891] usb 1-1.4: device not accepting address 11, error -71
[ 2559.780958] usb 1-1-port4: unable to enumerate USB device
[ 2761.082694] usb 1-1.4: new full-speed USB device number 12 using dwc_otg
[ 2761.162704] usb 1-1.4: device descriptor read/64, error -71
[ 2761.352702] usb 1-1.4: device descriptor read/64, error -71
[ 2761.542695] usb 1-1.4: new full-speed USB device number 13 using dwc_otg
[ 2761.622692] usb 1-1.4: device descriptor read/64, error -71
[ 2761.812695] usb 1-1.4: device descriptor read/64, error -71
[ 2762.002705] usb 1-1.4: new full-speed USB device number 14 using dwc_otg
[ 2762.422709] usb 1-1.4: device not accepting address 14, error -71
[ 2762.502705] usb 1-1.4: new full-speed USB device number 15 using dwc_otg
[ 2762.922734] usb 1-1.4: device not accepting address 15, error -71
[ 2762.922887] usb 1-1-port4: unable to enumerate USB device

lsusb
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 29 Januar 2017, 00:58:26
Hallo,

wenn du den radino noch an der IDE hast und per serieler Console raufgehst, was wird dir angezeigt bei CUL FW oder bei Signalduino ? 

Vielleicht einmal im Sketch die Baudrate auf 9600 setzten.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 01:22:26
Zitat von: pejonp am 29 Januar 2017, 00:58:26
Hallo,

wenn du den radino noch an der IDE hast und per serieler Console raufgehst, was wird dir angezeigt bei CUL FW oder bei Signalduino ? 

Vielleicht einmal im Sketch die Baudrate auf 9600 setzten.

pejonp
Im Sketch die Baudrate habe ich schon auf 9600 gesetzt. Die anderen FW Cul und aCulfw laufen auch auf 9600 problemlos.
...Console, da fehlen mir bisher die Voraussetzungen, da ich mit dem Raspberry Pi selber via ISP direkt programmiere.  8)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 Januar 2017, 01:40:31
ich habe es mal auf dem pro micro getestet. Dort funktioniert die Kommunication über USB (/dev/ttyACM0). Die Baudrate ist 57600
Ich kann im seriellen Monitor z.B. mit V die Version abfragen.
Da ich keinen CC1101 angeschlossen habe, habe ich ihn auskommentiert:
//#define CMP_CC1101

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 01:52:47
Da kam mir doch soeben in den Sinn, das ich via Windows direkt auf den USB Zugreifen kann via Putty, wie man mir es zeigte.

"Fremd" FW via Terminal funktioniert und der USB Port wird auch angezeigt in Windows als COM5.
Ergebnis mit V

V 1.23.07 a-culfw Build: private build (unknown) CUL433 (F-Band: 433MHz)

ArduinoFW, keine USB-Erkennung in Windows -> kein Port und somit nix  :(

Ich vermute die USB Umsetzung in Arduino ist noch fehlerhaft oder ggf. Interrupts ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 29 Januar 2017, 09:27:16
Hattest Du schon getestet was
ls -l /dev/serial/by-id
auf dem Raspberrypi zeigt?
(hoffe die Frage ist nicht zu banal)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 10:00:56
Also, die Firmware läuft auch auf einem atmega32u4. Da gab es schon Anwender, die das compiliert haben.

Die serielle Ausgabe hat auch wenig mit den im Sketch verwalteten Interrupts zu tun.

Es muss irgendwas grundsätzlicheres sein, wenn schon das OS den USB Port nicht initialisiert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 Januar 2017, 11:06:17
Falls der atmega32u4 mit 8 MHz läuft ist bei der Arduino IDE ein add on notwendig, dann kannst Du den Sparcfun pro micro und als Prozessor 8 MHz auswählen.
Unter Windows war bei mir für USB ein Treiber für den pro Micro notwendig.
https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide

Wenn Du die Arduino IDE unter Windows installierst, dann kannst Du direkt mit der IDE hochladen (flashen) und dann mit dem seriellen Monitor testen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 29 Januar 2017, 12:33:26
Hat mir evt. noch jemand einen Tipp zum Nachtrag im meinem schon ein paar Tage altem Beitrag?
https://forum.fhem.de/index.php/topic,58396.msg571268.html#msg571268 (https://forum.fhem.de/index.php/topic,58396.msg571268.html#msg571268)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 13:02:54
Hallo,
Zitat von: Sidey am 29 Januar 2017, 10:00:56
Also, die Firmware läuft auch auf einem atmega32u4. Da gab es schon Anwender, die das compiliert haben.
Es muss irgendwas grundsätzlicheres sein, wenn schon das OS den USB Port nicht initialisiert.
Kann man da nicht ansetzen. Was ist dafür zuständig wenn das OS den USB Port initialisiert.
Hinweis meinerseits, das selbige Gerät nur mit einer anderen FW, funktionier der USB Port an dem OS problemlos. Es ist nur die Arduino FW.

Zitatls -l /dev/serial/by-id
ls: Zugriff auf /dev/serial/by-id nicht möglich: Datei oder Verzeichnis nicht gefunden

ZitatFalls der atmega32u4 mit 8 MHz läuft ist bei der Arduino IDE ein add on notwendig, dann kannst Du den Sparcfun pro micro und als Prozessor 8 MHz auswählen.
Unter Windows war bei mir für USB ein Treiber für den pro Micro notwendig.
Muss ich sofort mal schauen. | Der Treiber nützt nichts für Windos, das Gerät an sich wird nicht erkannt von Windows. UBS kann nicht erkannt werden -> kein Gerät in Windows.

ZitatWenn Du die Arduino IDE unter Windows installierst, dann kannst Du direkt mit der IDE hochladen (flashen) und dann mit dem seriellen Monitor testen.
Ich habe Arduino IDE und das flashen getrennt. Mein derzeit zur Verfügung stehender Programmer ist der PI selber. Somit kann ich nicht von Arduino IDE progmmieren bzw. den Terminal Modus ansehen.

@RaspII
Sorry wenn du ein wenig untergehst.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 Januar 2017, 13:22:11
ZitatMuss ich sofort mal schauen. | Der Treiber nützt nichts für Windos, das Gerät an sich wird nicht erkannt von Windows. UBS kann nicht erkannt werden -> kein Gerät in Windows.

Ich habe Arduino IDE und das flashen getrennt. Mein derzeit zur Verfügung stehender Programmer ist der PI selber. Somit kann ich nicht von Arduino IDE progmmieren bzw. den Terminal Modus ansehen.

Ich konnte unter Windows 7 mit der Arduino IDE flashen obwohl der com Port nicht erkannt wurde. Ich musste den pro micro kurz vor dem hochladen (flashen) ein- und ausstecken.

Nach dem erfolgreichen flashen wurde an usb was erkannt, aber es wurde für den pro micro kein treiber gefunden.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 13:22:54
Zitat von: Ralf9 am 29 Januar 2017, 11:06:17
Falls der atmega32u4 mit 8 MHz läuft ist bei der Arduino IDE ein add on notwendig, dann kannst Du den Sparcfun pro micro und als Prozessor 8 MHz auswählen.
Unter Windows war bei mir für USB ein Treiber für den pro Micro notwendig.
https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide

Ergebnis: *Daumen Hoch*
lsusb
Bus 001 Device 014: ID 1b4f:9204

/dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 29 13:16 usb-SparkFun_SparkFun_Pro_Micro-if00 -> ../../ttyACM0

Erkenntnis: Mein radino CC1101 (http://shop.in-circuit.de/product_info.php?cPath=22_27&products_id=33) muss bei der ARDUINO IDE kompilierung mit dem "Installing the Arduino Addon" von hier (https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide) vorgenommen werden.

Weitere Tests für den Funktionsumfang werden getätigt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 14:09:59
Zitat von: HomeAuto_User am 29 Januar 2017, 13:22:54
Weitere Tests für den Funktionsumfang werden getätigt.
FHEM erkennt und Initialized den CUL (als CUL angelegt)

- LED´s müssen angepasst werden. Ständig die rote aktiv und auch gelbe

Befehle fehlerhaft:
bWidth --> Can't get old MDMCFG4 value
ccconf --> Timeout reading answer for get C0D
credit10ms => No answer
fhtbuf => No answer
raw => Unsupported command
uptime => No answer

Befehle funktionstüchtig:
cmds =>  V R t X F S P C r W
freq => laut Logfile wird dies eingestellt
ITClock => laut Logfile wird dies eingestellt
rAmp => laut Logfile wird dies eingestellt
reopen  => laut Logfile wird dies eingestellt | neu Initialized
sens (keine Kontrolle möglich, da ccconf nicht klappt)
version => V 3.3.1-dev SIGNALduino - compiled at Jan 29 2017 13:13:23

Test als sduino wie laut Wiki erfolgt noch. Somit sieht man ggf. Unterschiede.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 14:27:59
FHEM erkennt und Initialized den sduino (als sduino angelegt - wie Wiki)

- LED´s müssen angepasst werden. Ständig die rote aktiv und auch gelbe

Befehle fehlerhaft:
bWidth (gibt es nicht)
ccconf (gibt es nicht)
credit10ms (gibt es nicht)
fhtbuf (gibt es nicht)
raw => Unsupported command |taucht 2x auf im Menü, einmal unter set und get
uptime => No answer

Befehle funktionstüchtig:
cmds => V R t X F S P C r W
freq (gibt es nicht)
ITClock => laut Logfile wird dies eingestellt
rAmp (gibt es nicht)
protocollDs => Liste erscheint
reopen (gibt es nicht)
reset => neu "opened"
sens (gibt es nicht)
version =>version: V 3.3.1-dev SIGNALduino - compiled at Jan 29 2017 13:13:23
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 29 Januar 2017, 14:40:47
Hi,

mach mal ein Update, FHEM neu starten nicht vergessen:

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

und danach Version.

So definiert ?

define SD433 SIGNALduino /dev/....
attr SD433 hardware nanoCC1101
attr SD433 verbose 5

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 14:42:47
So wie das aussieht, hast Du nicht die cc1101 Version compiliert
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 15:02:46
Zitat von: pejonp am 29 Januar 2017, 14:40:47
So definiert ?

define SD433 SIGNALduino /dev/....
attr SD433 hardware nanoCC1101
attr SD433 verbose 5
Ja

ping OK
state opened
version V 3.3.1-dev SIGNALduino - compiled at Jan 29 2017 13:13:23

Zitat von: pejonp am 29 Januar 2017, 14:40:47
mach mal ein Update, FHEM neu starten nicht vergessen:

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

und danach Version.
2017.01.29 14:59:05 1 : nothing to do...
2017.01.29 14:59:30 4 : SD433/KeepAliveOk: 0
2017.01.29 14:59:30 3 : SD433/KeepAliveOk: 0 retry = 1 -> get ping
2017.01.29 14:59:30 4 : SD433/keepalive retry = 1
2017.01.29 14:59:30 5 : SD433 SW: P
2017.01.29 14:59:30 4 : SD433/msg READ: OK
2017.01.29 14:59:30 5 : SD433/msg READ: regexp=^OK$ cmd=ping msg=OK
2017.01.29 14:59:30 4 : SD433/HandleWriteQueue: nothing to send, stopping timer
2017.01.29 15:00:30 4 : SD433/KeepAliveOk: 1
2017.01.29 15:00:30 4 : SD433/keepalive retry = 0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 15:13:20
Welchen sourcecode hast Du compiliert und geflasht?

Nur mit diesem Branch kann der cc1101 initialisiert werden:

https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101

Und natürlich die gestern genannten Pins anpassen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 15:21:05
Zitat von: Sidey am 29 Januar 2017, 15:13:20
Welchen sourcecode hast Du compiliert und geflasht?

Nur mit diesem Branch kann der cc1101 initialisiert werden:

https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101

Und natürlich die gestern genannten Pins anpassen.

https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101

Ich gehe nun noch einmal alles durch! Der erste Vergleich mit den Sourcen zeige, das es die selben Dateien sind welche ich auch schon verwendete.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 Januar 2017, 15:40:40
wenn bei Version kein cc1101 steht, dann wurde der cc1101 nicht erkannt
V 3.3.1-dev SIGNALduino cc1101 - compiled ...

beim initialisieren müsste folgendes ausgegeben werden
CCVersion=
CCPartnum=
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 18:45:29
Bisher kein Erfolg.

Hier der Orginalauszug der Dateien nach dem runter laden der Sourcen:

#ifdef CMP_CC1101
  #define PIN_LED               9
  #define PIN_SEND              3   // gdo0Pin TX out
#else
  #define PIN_LED               13    // Message-LED
  #define PIN_SEND              11

#endif
#define PIN_RECEIVE            2

   #define csPin   10   // CSN  out
   #define mosiPin 11   // MOSI out
   #define misoPin 12   // MISO in
   #define sckPin  13   // SCLK out

---------------------------------------------------------
Die gänginge Variante mit einer anderen FW wo ich auch ccconf abfragen kann und somit ich ausgehe, das der CC1101 funkioniert.

#  define CC1100_CS_DDR         DDRB
#  define CC1100_CS_PORT        PORTB
#  define CC1100_CS_PIN         4
#  define CC1100_OUT_DDR        DDRB
#  define CC1100_OUT_PORT       PORTB
#  define CC1100_OUT_PIN        5
#  define CC1100_OUT_IN         PINB
#  define CC1100_IN_DDR         DDRE
#  define CC1100_IN_PORT        PINE
#  define CC1100_IN_PIN         6
#  define CC1100_IN_IN          PINE
#  define CC1100_INT         INT6
#  define CC1100_INTVECT        INT6_vect
#  define CC1100_ISC         ISC60
#  define CC1100_EICR           EICRB
#  define LED_DDR               DDRB
#  define LED_PORT              PORTB
#  define LED_PIN               0

#define MARK433_PORT            PORTD
#define MARK433_PIN             PIND
#define MARK433_BIT             4
#define MARK915_PORT            DDRB
#define MARK915_PIN             PORTB
#define MARK915_BIT             7

Laut Dokumentation Seite 6 (http://wiki.in-circuit.de/images/4/49/305000077A_radino_CC1101.pdf) sind die PIN´s / 14 15 16 7 8 9 4
Alles bisher ohne Erfolge. Der CC1101 spricht nicht mit uns.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 18:56:46
Du musst die Quelldateien anpassen, damit die richtigen Pins verwenden werden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 19:42:57
Zitat von: Sidey am 29 Januar 2017, 18:56:46
Du musst die Quelldateien anpassen, damit die richtigen Pins verwenden werden.
Entschuldigung der Frage, welche?
Anpassungen werden in der
RF_Receiver.ino | cc1101.h
vorgenommen oder eine Boardverwaltungsdatei?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 29 Januar 2017, 19:50:55
Hi,

Siehe ab Post 170 https://forum.fhem.de/index.php/topic,58396.msg571624.html#msg571624

Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2017, 19:53:14
Gefühlte 100 Beiträge weiter vorne:

https://forum.fhem.de/index.php?topic=58396.msg571792.msg#571792
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 20:17:57
Zitat von: pejonp am 29 Januar 2017, 19:50:55
Hi,

Siehe ab Post 170 https://forum.fhem.de/index.php/topic,58396.msg571624.html#msg571624

Pejonp

Hallo, was denkt ihr was ich mache bzw. probiere  ;D :o

Erkenntnis und Ergebnis:
TEST1
#ifdef CMP_CC1101
#define PIN_LED               2     // ???
#define PIN_SEND              9     // GDO0 Pin TX out
#else
#define PIN_LED               13    // Message-LED
#define PIN_SEND              11    // GDO2 ???

#endif
#define PIN_RECEIVE           7     // 433 or 912Mhz

#define csPin   8     // CSN out   (CS bzw. SS)
#define mosiPin 16    // MOSI out  (SI)
#define misoPin 14    // MISO in   (SO)
#define sckPin  15    // SCLK out  (SCLK)

TEST2
#ifdef CMP_CC1101
#define PIN_LED               7     // ???
#define PIN_SEND              3     // GDO0 Pin TX out
#else
#define PIN_LED               13    // Message-LED
#define PIN_SEND              11    // GDO2 ???

#endif
#define PIN_RECEIVE           2     // 433 or 912Mhz

#define csPin   8     // CSN out   (CS bzw. SS)
#define mosiPin 16    // MOSI out  (SI)
#define misoPin 14    // MISO in   (SO)
#define sckPin  15    // SCLK out  (SCLK)

TEST3   -   Ständige an - abmeldung in FHEM und ccconf gibt es nicht zur Auswahl
#ifdef CMP_CC1101
#define PIN_LED               7     // ???
#define PIN_SEND              3     // GDO0 Pin TX out
#else
#define PIN_LED               13    // Message-LED
#define PIN_SEND              11    // GDO2 ???

#endif
#define PIN_RECEIVE           2     // 433 or 912Mhz

#define csPin   10     // CSN out   (CS bzw. SS)
#define mosiPin 11    // MOSI out  (SI)
#define misoPin 12    // MISO in   (SO)
#define sckPin  13    // SCLK out  (SCLK)

TEST4   -   Ständige an - abmeldung in FHEM und ccconf gibt es nicht zur Auswahl
#ifdef CMP_CC1101
#define PIN_LED               2     // ???
#define PIN_SEND              9     // GDO0 Pin TX out
#else
#define PIN_LED               13    // Message-LED
#define PIN_SEND              11    // GDO2 ???

#endif
#define PIN_RECEIVE           7     // 433 or 912Mhz

   #define csPin   10     // CSN out   (CS bzw. SS)
   #define mosiPin 11    // MOSI out  (SI)
   #define misoPin 12    // MISO in   (SO)
   #define sckPin  13    // SCLK out  (SCLK)
   
TEST1+2 --> This command is only available with a cc1101 receiver und ccconf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 29 Januar 2017, 21:38:14
Hi,

versuche einmal in der RF_..ino diese Werte.

#ifdef CMP_CC1101
  #define PIN_LED               9 <-- die 9 ist belegt vielleicht die 10 oder auch die 13
  #define PIN_SEND            9 <-- hier ändern, in der Doku ist es die PB5(9)
#else
  #define PIN_LED               13    // Message-LED
  #define PIN_SEND              11

#endif
#define PIN_RECEIVE         7 <-- hier ändern, , in der Doku ist es die PE6(7)
#define BAUDRATE               57600
#define FIFO_LENGTH            50
#define DEBUG               1

in der cc1101.h  sollte es so aussehen:

#define csPin   8     // CSN out   (CS bzw. SS)
#define mosiPin 16    // MOSI out  (SI)
#define misoPin 14    // MISO in   (SO)
#define sckPin  15    // SCLK out  (SCLK)

ohne Garantie ;-(

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 22:11:45
Ich teste deine Angaben mal.

Unabhängig habe ich nun es hinbekommen das Orginal Board in Arduino einzubinden und wollte dann kompilieren.
Da erhalte ich eine Fehlermeldung in der RF_Receiver.ino.

RF_Receiver.ino: In function 'void enableReceive()':

RF_Receiver:274: error: 'digitalPinToInterrupt' was not declared in this scope

   attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE), handleInterrupt, CHANGE);

                                                    ^

exit status 1
'digitalPinToInterrupt' was not declared in this scope


Bisher immer mit diesem Kompiliert lauf Empfehlung von den Vorseiten. (https://forum.fhem.de/index.php/topic,58396.msg572050.html#msg572050)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 29 Januar 2017, 22:15:12
Zitat von: HomeAuto_User am 29 Januar 2017, 13:02:54
@RaspII
Sorry wenn du ein wenig untergehst.
Macht erst mal fertig hier (das Teil ist für den Preis ziemlich interessant und man muss nichts mehr basteln).
Mir habt Ihr schon viel geholfen, es darf auch mal anderen geholfen werden  ;D
Ich warte einfach mal ab und lese mich solange quer durch die Threads.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 29 Januar 2017, 22:27:55
void enableReceive() {
   attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE),handleInterrupt,CHANGE);
}


digitalPinToInterrupt (https://forum.arduino.cc/index.php?topic=370167.0)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 22:59:02
Zitat von: juergs am 29 Januar 2017, 22:27:55
void enableReceive() {
   attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE),handleInterrupt,CHANGE);
}


digitalPinToInterrupt (https://forum.arduino.cc/index.php?topic=370167.0)

Nun hat sich der komplette Kompiler verabschiedet.
Eine Neuinstallation brachte auch nichts.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 29 Januar 2017, 23:45:38
Schlusswort für heute.

Keine Definition der PIN´s brachte einen Erfolg.

Die Nutzung des Kompilers ist wieder hergestellt.
Nach meiner Idee, das Programm mit dem Herstellerboardangaben zu kompilieren klappte der Code nicht --> Fehler.
Nun versuche ich mich an der Behebung desses um einen neuen Versuch zu starten obwohl behauptet wurde, das spiele keine Rolle.
Es muss eine Ursache haben, welche gefunden werden möchte.

E:\Programme\Rasberry - Projekt\Projekt_CUL_\Flashen\ARDUINO_Firmware\RF_Receiver\RF_Receiver.ino: In function 'void enableReceive()':

RF_Receiver:270: error: 'digitalPinToInterrupt' was not declared in this scope

    attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE),handleInterrupt,CHANGE);

                                                     ^

E:\Programme\Rasberry - Projekt\Projekt_CUL_\Flashen\ARDUINO_Firmware\RF_Receiver\RF_Receiver.ino: In function 'void disableReceive()':

RF_Receiver:278: error: 'digitalPinToInterrupt' was not declared in this scope

   detachInterrupt(digitalPinToInterrupt(PIN_RECEIVE));

                                                    ^

exit status 1
'digitalPinToInterrupt' was not declared in this scope


-----------------------------
Danke an alle Mithelfenden. :-*

PS: @juergs, wie hast du die Headerdatei FastPortHelpers.h weiterverarbeitet und vielleicht wäre es eine Erleichterung wenn man diese ggf. in den Code aufnimmt wenn das auch anderen helfen würde?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 30 Januar 2017, 00:05:35
Hallo HomeAuto_User;

bleib dran.

'digitalPinToInterrupt' was not declared in this scope

die kannst dort auch eine Zahl für den Pin eintragen. Ich würde dort einmal die 7 versuchen.

Bein Nano ist es glaube ich Pin 2 für Interrupt 0 (siehe unten).

ersetzte einemal : attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE),handleInterrupt,CHANGE);
durch :  attachInterrupt(7,handleInterrupt,CHANGE);  Zahl ggf. ändern

Hier die Interrupts:
Board                                              Digital Pins Usable For Interrupts
Uno, Nano, Mini, other 328-based      2, 3
Mega, Mega2560, MegaADK              2, 3, 18, 19, 20, 21
Micro, Leonardo, other 32u4-based    0, 1, 2, 3, 7

Uno,Nano, Ethernet:

    Inter. 0 = Digitaler Pin 2
    Inter. 1 = Digitaler Pin 3

Leonardo:

    Inter. 0 = Digitaler Pin 3
    Inter. 1 = Digitaler Pin 2
    Inter. 2 = Digitaler Pin 0
    Inter. 3 = Digitaler Pin 1

  pejonp                 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 Januar 2017, 07:07:28
Moin,
Meiner Meinung nach, muss man den Interrupt und nicht den Pin in der atttatchInterrupt routine angeben.

Ich hatte einen Beitrag verlinkt, in dem stand, dass atttatchInterrupt mit Pin7 nicht funktioniert. Die Fehlermeldung "not declared" ist natürlich banane.

So langsam denke ich auch, dass wir die Board Konfiguration wohl besser mal ins repo mit aufnehmen.

Welches Bord hast Du in de Arduino IDE jetzt zum Compilieren genau ausgewählt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Januar 2017, 15:03:28
@HomeAuto_User
Ich würde es am Anfang erst mal ohne den digitalPinToInterrupt beim enableReceive() versuchen.
Das kannst Du dann in einem zweiten Schritt machen.
Zuvor sollte der cc1101 sauber angesprochen werden können.
Du kannst mal im seriellen Monitor die folgenden Befehle testen
e        factory reset
r00n     liest Werte aus dem EEPROM aus
C99      liest alle Register des cc1101
WS36     cc1101 wechselt nach idle
WS34     cc1101 RX enable



Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 30 Januar 2017, 17:54:11
Hallo,

ZitatIch würde es am Anfang erst mal ohne den digitalPinToInterrupt beim enableReceive() versuchen.
Das kannst Du dann in einem zweiten Schritt machen.
Zuvor sollte der cc1101 sauber angesprochen werden können.
getan

ZitatBoard Konfiguration
Vielleicht habe ich hier einen Tip dazu gefunden in der Datei pins_arduino.h vom Hersteller. Es sieht mir nach einer PIN-Umdefinition an.
Leider bin ich in Arduino noch nicht so fit, daher bräuchte ich Mithilfe. (Datei hängt an)

Vorab, so

#define csPin   17
#define mosiPin 16
#define misoPin 14
#define sckPin  15

klappte es noch nicht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 31 Januar 2017, 07:11:01
Hallo,

kann man eigentlich die Meldung im Log "KeepAliveOk: 0 retry = 1 -> get ping" irgendwie abschalten? Außer mit Verbose 0.

Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 31 Januar 2017, 10:12:20
Zitat von: HomeAuto_User am 30 Januar 2017, 17:54:11
...
Vorab, so

#define csPin   17
#define mosiPin 16
#define misoPin 14
#define sckPin  15

klappte es noch nicht.
Hallo,

#define csPin   17 <--- sollte laut Schaltbild die 8 sein.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Januar 2017, 12:04:29
Zitat von: majorshark am 31 Januar 2017, 07:11:01
kann man eigentlich die Meldung im Log "KeepAliveOk: 0 retry = 1 -> get ping" irgendwie abschalten? Außer mit Verbose 0.

Demnach kommt es bei Dir vor, daß 60 Sek lang nichts empfangen wird. Wenn man mehrere Temperatursensoren empfängt, kommt dies normalerweise nicht vor daß 60 Sek lang nichts empfangen wird.
Bei Bedarf, kann ich es so abändern, daß die erste (retry = 1) Meldung einen Loglevel 4 hat und die weiteren einen Loglevel 3.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 31 Januar 2017, 14:26:00
Zitat von: Ralf9 am 31 Januar 2017, 12:04:29
Demnach kommt es bei Dir vor, daß 60 Sek lang nichts empfangen wird. Wenn man mehrere Temperatursensoren empfängt, kommt dies normalerweise nicht vor daß 60 Sek lang nichts empfangen wird.
Bei Bedarf, kann ich es so abändern, daß die erste (retry = 1) Meldung einen Loglevel 4 hat und die weiteren einen Loglevel 3.

Gruß Ralf

Das wird so sein, den eigentlich habe ich mir den sduino nur wegen Somfy zusammengebaut. Sensoren frage ich damit (noch) nicht ab. Wobei.  ::) Der Nachbar hat ein Windsensor an der Wand. Diesen Wert könnte ich noch gut gebrauchen.  ;)

Wenn es so vorgesehen ist mit den Meldungen und diese dann verschwinden wenn es richtig genutzt wird muss es nicht unbedingt geändert werden.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Januar 2017, 18:10:19
Ich denke, wir können den Loglevel Mal auf 4 erhöhen und erst wenn der keepalive ausbleibt, auf 3 oder 2 reduzieren... Eine richtige Vorgabe, welcher Loglevel für was gibt es ja auch nicht. Braucht man diese Meldung überhaupt im normalfall (Verbose 3?)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 31 Januar 2017, 18:17:56
Zitat von: pejonp am 31 Januar 2017, 10:12:20
Hallo,

#define csPin   17 <--- sollte laut Schaltbild die 8 sein.

pejonp
Hallo,
der Zwischenstand der Dinge, NIX geht. Keine Initialisierung des CC1101. Sämtliche Boards ausprobiert zur Kompilierung bzw. Beschaltungen der PIN´s hin und her probiert.
Der WURM muss anderweitig versteckt sein. Die Idee geht dahin, den Code zu prüfen welcher zur Verfügung gestellt wurde oder es findet sich ne Möglichkeit herauszubekommen was die Anschlüsse betrifft.

User welche den radino CC1101 oder das CSM radino Modul mit SIGNALduino betreiben wären nun Hilfreich. --> die Gegenprobe mit der Cul oder aCul FW funktioniert ja.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Januar 2017, 18:28:38
Ich passe den sourcecode an. Gib mir mal ein paar Tage.

Welches Board wählst Du beim compilieren derzeit aus?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 31 Januar 2017, 18:46:21
Zitat von: Sidey am 31 Januar 2017, 18:28:38
Ich passe den sourcecode an. Gib mir mal ein paar Tage.

Welches Board wählst Du beim compilieren derzeit aus?

Hallo,
da bin ich ja gespannt wie ein "nackiger" Hamster weil mittlerweile schon mehrere daran verzweifeln.

Auswahl Board radino CC1101 --> Hersteller Board Libraries (http://www.ic42.de/BSP/radino/ICT_Boards.zip)
"" Arduino-compatible (Arduino Micro / Leonardo) "" laut Hersteller.

Nur aufpassen Viele compatiblen Boards werden auf f_cpu=16000000L gesetzt und der Hersteller nimmt f_cpu=8000000L.
Also ist ausschlaggebend 8Mhz was auch das SparkFun Board Bsp. könnte. Pro Micro 3.3V - Board (https://github.com/sparkfun/Arduino_Boards)

PS: Sollte es sofort klappen hätttest was gut  ;)

EDIT: Auch mit den Herstellerangaben PIN´s klappte es nicht, deswegen  :-\
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Januar 2017, 19:48:49
Du kannst mal in der cc1101.h am Anfang der "checkCC1101" Routine ein DBG_PRINTLN einfügen
bool checkCC1101() {
DBG_PRINTLN("checkCC1101");
...


Du müsstest dann, wenn Du den seriellen Monitor öffnest, die folgende Ausgabe bekommen:
ZitatUsing sFIFO
Reading values fom eeprom
CCInit
checkCC1101
CCVersion=20
CCPartnum=0
Starting timerjob
receiver enabled

Was wird ausgegeben, wenn Du im seriellen Monitor "V" , "r00n" und "C99" sendest

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Januar 2017, 21:50:05
Zitat von: HomeAuto_User am 31 Januar 2017, 18:46:21
Auswahl Board radino CC1101 --> Hersteller Board Libraries (http://www.ic42.de/BSP/radino/ICT_Boards.zip)
"" Arduino-compatible (Arduino Micro / Leonardo) "" laut Hersteller.
Du verwirrst mich. Ich habe das Board In-Circuit radino cc1101 compiliert.

Zitat von: HomeAuto_User am 31 Januar 2017, 18:46:21

Nur aufpassen Viele compatiblen Boards werden auf f_cpu=16000000L gesetzt und der Hersteller nimmt f_cpu=8000000L.
Also ist ausschlaggebend 8Mhz was auch das SparkFun Board Bsp. könnte. Pro Micro 3.3V - Board (https://github.com/sparkfun/Arduino_Boards)

Ich verstehe nicht, was ich jetzt aufpassen soll?

Die Parameter für das board kommen vom Hersteller. Die werden doch stimmen oder?

radinoCC1101.build.usb_product="radino CC1101"
radinoCC1101.build.usb_manufacturer="In-Circuit"
radinoCC1101.build.extra_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid} '-DUSB_PRODUCT={build.usb_product}'
radinoCC1101.upload.tool=arduino:avrdude
radinoCC1101.bootloader.tool=arduino:avrdude
radinoCC1101.bootloader.file=caterina/Caterina-radino_CC1101.hex
radinoCC1101.upload.use_1200bps_touch=true
radinoCC1101.upload.wait_for_upload_port=true
radinoCC1101.vid.0=0x1DA9
radinoCC1101.pid.0=0x002B
radinoCC1101.vid.1=0x1DA9
radinoCC1101.pid.1=0x002C

radinoCC1101.name=In-Circuit radino CC1101
radinoCC1101.upload.protocol=avr109
radinoCC1101.upload.maximum_size=28672
radinoCC1101.upload.speed=57600
radinoCC1101.upload.disable_flushing=true
radinoCC1101.bootloader.low_fuses=0xfb
radinoCC1101.bootloader.high_fuses=0xd8
radinoCC1101.bootloader.extended_fuses=0xff
#radinoCC1101.bootloader.path=caterina
#radinoCC1101.bootloader.file=Caterina-radino_CC1101.hex
radinoCC1101.bootloader.unlock_bits=0x3F
radinoCC1101.bootloader.lock_bits=0x2F
radinoCC1101.build.mcu=atmega32u4
radinoCC1101.build.f_cpu=8000000L
radinoCC1101.build.vid=0x1DA9
radinoCC1101.build.pid=0x002C
radinoCC1101.build.core=arduino:arduino
radinoCC1101.build.variant=ictmicro


Hier SIGNALDuino.ino_ict_boards_avr_radinoCC1101.hex zum Flashen:
https://drive.google.com/file/d/0B3UU1FxM6ZDUNDQtNnNYd0hUOEU/view?usp=sharing
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Januar 2017, 21:59:15
Zitat von: Sidey am 31 Januar 2017, 18:10:19
Ich denke, wir können den Loglevel Mal auf 4 erhöhen und erst wenn der keepalive ausbleibt, auf 3 oder 2 reduzieren... Eine richtige Vorgabe, welcher Loglevel für was gibt es ja auch nicht. Braucht man diese Meldung überhaupt im normalfall (Verbose 3?)

Ich habe ein wenig gebastelt. Ich habe auch log Einträge zusammengefasst. Ich habe vor es wie folgt einzubauen:

So sieht es normalerweise aus, wenn mindestens alle 60 Sek was empfangen wird

2017.01.31 21:37:06.888 4 : sduinoE/keepalive ok, retry = 0

2017.01.31 21:38:06.890 4 : sduinoE/keepalive ok, retry = 0


Wenn innerhalb 60 Sek nichts empfangen wird, dann wird retry erhöht und ein ping gesendet
2017.01.31 21:30:24.003 4 : sduinoE/KeepAlive not ok, retry = 1 -> get ping
2017.01.31 21:30:24.114 4 : sduinoE/msg READ: OK
2017.01.31 21:31:24.005 4 : sduinoE/keepalive ok, retry = 0

2017.01.31 21:32:24.008 4 : sduinoE/KeepAlive not ok, retry = 1 -> get ping
2017.01.31 21:32:24.119 4 : sduinoE/msg READ: OK
2017.01.31 21:33:24.009 4 : sduinoE/keepalive ok, retry = 0



Wenn beim ping keine Antwort kommt, sieht es so aus
2017.01.31 21:44:43.987 4 : sduinoE/keepalive ok, retry = 0

2017.01.31 21:45:43.990 4 : sduinoE/KeepAlive not ok, retry = 1 -> get ping

2017.01.31 21:46:43.994 3 : sduinoE/KeepAlive not ok, retry = 2 -> get ping


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Januar 2017, 22:10:18
ich habe mal gesucht, für den radino gibt es für die Arduino IDE auch eine Library
http://wiki.in-circuit.de/index.php5?title=radino_Library

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 31 Januar 2017, 23:06:22
Hallo,
Zitat von: Sidey am 31 Januar 2017, 21:50:05
Du verwirrst mich. Ich habe das Board In-Circuit radino cc1101 compiliert.

Hier SIGNALDuino.ino_ict_boards_avr_radinoCC1101.hex zum Flashen:
https://drive.google.com/file/d/0B3UU1FxM6ZDUNDQtNnNYd0hUOEU/view?usp=sharing

Vielen Dank, dennoch
ZitatCCInit
CCVersion=0
CCPartnum=0
no CC11xx found!

Zitat von: Ralf9 am 31 Januar 2017, 22:10:18
ich habe mal gesucht, für den radino gibt es für die Arduino IDE auch eine Library
http://wiki.in-circuit.de/index.php5?title=radino_Library

Gruß Ralf
Danke, sind bekannnt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 01 Februar 2017, 22:39:34
Ich hab jetzt mal eine HOWTO WIKI Seite zum Thema SOMFY-RTS via SIGNALduino angelegt:
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)

Dort ist alles beschrieben was ich Stand heute über das Thema weiss.

Was mir immer noch fehlt:
meine ICONs (mit denen ich von FHEM aus die Rolläden steure) sollen auch an den Status ändern, wenn via Somfy Fernbedienung (also anderer HEX Code) die entsprechende Taste gedrückt wird (FHEM also ein Kommando empfängt).

Ich habe da schon einige Infos gefunden (https://forum.fhem.de/index.php/topic,34793.msg567152.html#msg567152 (https://forum.fhem.de/index.php/topic,34793.msg567152.html#msg567152)), allerdings nur bzgl. der Lösung "CUL zum senden und den FHEMduino zum Empfangen"
Verstanden habe ich das aber wenn ich ehrlich bin nicht.

Es wäre schön wenn jemand Zeit findet und mir erklärt wie man beim SIGNALduino SOMFY-RTS Handsender so mit FHEM Devices verknüpft, das der Status der Rolläden auch aktualisiert wird wenn der Rolladen via Handsender verstellt wird (FHEM darf ja nicht den selben Device Code wie der Handsender benutzen)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ellert am 02 Februar 2017, 15:25:10
Zitat von: RaspII am 01 Februar 2017, 22:39:34
Ich hab jetzt mal eine HOWTO WIKI Seite zum Thema SOMFY-RTS via SIGNALduino angelegt:
https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)

Dort ist alles beschrieben was ich Stand heute über das Thema weiss.

Was mir immer noch fehlt:
meine ICONs (mit denen ich von FHEM aus die Rolläden steure) sollen auch an den Status ändern, wenn via Somfy Fernbedienung (also anderer HEX Code) die entsprechende Taste gedrückt wird (FHEM also ein Kommando empfängt).

Ich habe da schon einige Infos gefunden (https://forum.fhem.de/index.php/topic,34793.msg567152.html#msg567152 (https://forum.fhem.de/index.php/topic,34793.msg567152.html#msg567152)), allerdings nur bzgl. der Lösung "CUL zum senden und den FHEMduino zum Empfangen"
Verstanden habe ich das aber wenn ich ehrlich bin nicht.

Es wäre schön wenn jemand Zeit findet und mir erklärt wie man beim SIGNALduino SOMFY-RTS Handsender so mit FHEM Devices verknüpft, das der Status der Rolläden auch aktualisiert wird wenn der Rolladen via Handsender verstellt wird (FHEM darf ja nicht den selben Device Code wie der Handsender benutzen)

Zu dieser Frage: Wären dann die Fernbedienung und FHEM synchron?

Nein, das Attribut rawDevice kannst Du löschen.
Dafür setzt Du das Attribut Dummy, das verhindert, das dises Gerät mit dem Handsender in Konflikt kommt.

Um beide Geräte zu synchronisieren, kannst Du ein notify bauen, das  den Status von SOMFY_987654 auf Rolladen überträgt.

Etwa nach diesem Muster

SOMFY_(987654|weitereAdresse|weitereAdresse|usw.):parsestate:.(on|off|stop) {

my %ger1 = (
  "SOMFY_987654" => " Rolladen",
  "SOMFY_adresse_2" => "Partner_2",
  "SOMFY_adresse_3" => "Partner_3,Partner2, ...", Wenn SOMFY_adresse_3 in mehreren Aktoren (2, 3) angelernt ist.

und so weiter

  "SOMFY_adresse_n" => "Partner_n"
);
my %cmd1 = (
  "off"  => "open",
  "on"   => "closed",
  "stop" => "go-my"
  "prog" => "prog"
);
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});
my @gers = split(",",$ger1{$NAME});
for (my $i=0;$i<@gers;$i++) {
  fhem "setreading $gers[$i] state $cmd1{$EVTPART1}";
}
}


weitereAdresse entspricht SOMFY_adresse
Partner sind die entsprechenden FHEM-Somfy-Geräte (virtuelle Fernbedienung)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 02 Februar 2017, 17:19:52
Zitat von: Sidey am 31 Januar 2017, 18:28:38
Ich passe den sourcecode an. Gib mir mal ein paar Tage.

Welches Board wählst Du beim compilieren derzeit aus?

Hallo,

es gibt neue Erkenntnisse!
Die PIN´s für die Kommunikation konnten verifiziert werden für das Modul.
Es sind SCK_PIN   15 | MISO_PIN  14 | MOSI_PIN  16 | SS_PIN    8 wie auch schon aus der Doku zu entnehmen.

Ich bzw. wir haben den Test soweit vollzogen, das wir mit einem kleinen Programmteil wie hier (https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi50o785vHRAhWiQJoKHbUWDdUQFggjMAA&url=http%3A%2F%2Fwww.electrodragon.com%2Fw%2FCC1101&usg=AFQjCNEeVjUG6ITupbWyhDSPJxDJXQINJg&bvm=bv.146094739,d.bGs) die Kommunikation getestet haben. Als Ausgabe haben wir uns 2 Werte aus dem Register gelesen wie Version und Produktnummer.

Der Vergleich zeigt, das @Sidney seine Initialisierung für den CC1101 anders geschrieben bzw. "konstruiert" wie aus dem Beispiel.
Es müsste die Initialisierung vermutlich umgestaltet werden ODER es ist nur ein Wert der sich anders verhält. Da das Ganze in sehr viel Unterprogrammen abläuft, so sehen wir bisher noch nicht durch  :-\
Hast du @Sidney vielleicht eine Idee wenn du dir das Beispiel mit deinem geschriebenen vergleichst, wo vielleicht der Haken ist? Wir vermuten, das es vielleicht mist dem Chipselect zu tun hat.

Ich bin mir sicher, wenn wir den "Wurm" finden, dann könnte deine Version auch für das Modul "freigegeben" werden.

Liebe Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 02 Februar 2017, 18:04:26
@Ellert
Danke für die Info.
Hört sich kompliziert an. Probieren ich bei Gelegenheit mal aus.
Ich hab dich richtig verstanden, diese Info muss dann in die fhem.cfg?

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 Februar 2017, 18:08:35
@home_user
Kannst Du mir den kleinen Sketch mal zukommen lassen?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ellert am 02 Februar 2017, 20:30:00
Zitat von: RaspII am 02 Februar 2017, 18:04:26
@Ellert
Danke für die Info.
Hört sich kompliziert an. Probieren ich bei Gelegenheit mal aus.
Ich hab dich richtig verstanden, diese Info muss dann in die fhem.cfg?

Gesendet von meinem SM-G900F mit Tapatalk

Nein in den DEF-Editor
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 02 Februar 2017, 22:03:30
Hm, jetzt bin ich verwirrt.
Das ist doch das selbe. Nur einmal editiere ich die fhem.cfg im Editor, im anderen Fall gehe ich über die Oberfläche.
Oder habe ich jetzt was komplett falsch verstanden (bin leider immer noch kein Experte)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 02 Februar 2017, 22:15:23
Ich habe dann noch eine letzte Frage für heute.
Irgendwo hatte ich gelesen, dass die Signalduino Module später mal in die offizielle FHEM Distribution einfliessen werden.
Ist schon bekannt wann das passieren wird?

Ich könnte/müsste dann die Info über das derzeit notwendige Update wieder korrigieren und evt. beschreiben wie man das automatische Update wieder deaktiviert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 02 Februar 2017, 22:55:26
Zitat von: Sidey am 02 Februar 2017, 18:08:35
@home_user
Kannst Du mir den kleinen Sketch mal zukommen lassen?

Grüße Sidey
Nabend,

hier ist das kleine Beispiel für den Kommunikationstest.
(natürlich kann man dies auch noch optimieren)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ellert am 02 Februar 2017, 23:58:22
Zitat von: RaspII am 02 Februar 2017, 22:03:30
Hm, jetzt bin ich verwirrt.
Das ist doch das selbe. Nur einmal editiere ich die fhem.cfg im Editor, im anderen Fall gehe ich über die Oberfläche.
Oder habe ich jetzt was komplett falsch verstanden (bin leider immer noch kein Experte)
ZitatDas ist doch das selbe.
Die cfg sollte nur von jemandem bearbeitet werden, der weiss was er tut. Du schreibst selbst, dass dies bei Dir nicht der Fall ist.
In der cfg müssen die Maskierungen und Umbrüche explizit angegeben werden, im DEF nicht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 04 Februar 2017, 22:41:06
Hallo,

Zitat von: Sidey am 02 Februar 2017, 18:08:35
@home_user
Kannst Du mir den kleinen Sketch mal zukommen lassen?

@Sidey, konntest du schonmal einen Blick in den Code werfen?

Soeben mache ich Test´s zu den Produktvarianten um für weitere Modelle Vorarbeit zu leisten.
Bsp: Auswertung Modulvarainte radino_CC110, welche man auch auf das radino_CSM Produkt anwenden könnte. (Funkfrequenzvariante)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Februar 2017, 01:37:59
Zitat von: HomeAuto_User am 04 Februar 2017, 22:41:06
@Sidey, konntest du schonmal einen Blick in den Code werfen?

Ich habe mir die Unterschiede zur a-culfw und auch zur radino lib angesehen. Aufgefallen sind mir nur unterschiedliche delay Zeiten.

Die Firmware ist unter dem gleichen Link wie die zuletzt compilierte erhältlich:
https://drive.google.com/open?id=0B3UU1FxM6ZDUNDQtNnNYd0hUOEU

Grüße Sidey
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 05 Februar 2017, 03:44:18
Guten Morgen,

Zitat von: Sidey am 05 Februar 2017, 01:37:59
Ich habe mir die Unterschiede zur a-culfw und auch zur radino lib angesehen. Aufgefallen sind mir nur unterschiedliche delay Zeiten.

Grüße Sidey

Leider muss ich Dir mitteilen, das der Wurm noch vorhaben ist. Es muss einen Unterschied geben!

ZitatUsing sFIFO
Init eeprom to defaults after flash
ccFactoryReset done
CCInit
CCVersion=0
CCPartnum=0
no CC11xx found!

Starting timerjob
receiver enabled

Unterschiede Nano <-> radino im ISP Verständnis? (Wenn ich ein Testfile vom Nano einspiele, welches da den Cc1101 findet, da findet der radino nix) Nehme ich das Testfile welches ich hier hochgeladen hatte, findet er ihn. Hm...

Desweiteren, Ich konnte es erst kompilierennachdem ich folgendes änderte

//attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE), handleInterrupt, CHANGE);
  attachInterrupt(PIN_RECEIVE, handleInterrupt, CHANGE);


//detachInterrupt(digitalPinToInterrupt(PIN_RECEIVE));
  detachInterrupt(PIN_RECEIVE);

Normal??

Liebe Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Februar 2017, 09:20:14
Also, wenn Du selbst compiierst, dann musst Du für den Radio compilieren, sonst greifen die Einstellungen nicht.

Den Quellcode muss man für den Radio nicht mehr anpassen, den habe ich angepasst.

Hast Du für den Nano compiliert,dann ist klar, dass es nicht geht.

Hast Du das von mir compiliere Hex probiert?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 05 Februar 2017, 14:55:37
Zitat von: Sidey am 05 Februar 2017, 09:20:14
Also, wenn Du selbst compiierst, dann musst Du für den Radio compilieren, sonst greifen die Einstellungen nicht.

Den Quellcode muss man für den Radio nicht mehr anpassen, den habe ich angepasst.

Hast Du für den Nano compiliert,dann ist klar, dass es nicht geht.

Hast Du das von mir compiliere Hex probiert?

Dein fertiges File ausprobiert!

ZitatUsing sFIFO
Init eeprom to defaults after flash
ccFactoryReset done
CCInit
CCVersion=0
CCPartnum=0
no CC11xx found!

ZitatHast Du für den Nano compiliert,dann ist klar, dass es nicht geht.
NEIN, ich wähle das Board radino aus, NICHT NANO. .. auch mit dem Source-Code

ZitatAlso, wenn Du selbst compiierst, dann musst Du für den Radio compilieren, sonst greifen die Einstellungen nicht.
Das habe ich getan und das mit deinem angepasten Code.

ZitatDen Quellcode muss man für den Radio nicht mehr anpassen, den habe ich angepasst.
Glaube mir, da ist noch ein Wurm drin.  :-[
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Februar 2017, 15:10:26
Schade, wäre wohl zu einfach gewesen...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 05 Februar 2017, 18:20:52
Du kannst mal in der cc1101.h in Zeile 346 beim return das false durch true ersetzen. Damit wird dann der cc1101check deactiviert.
https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/cc1101.h
Nach dem neu flashen kannst Du dann mal im seriellen Monitor folgendes senden:
C99
e     (factoryreset)
C99


Danach kannst Du mal in der cc1101.h ab Zeile 410 schrittweise folgendes ändern und danach jeweils neu flashen:
Zuerst die (45) auf 100 und 500 erhöhen,
und dann die beiden (30) auf 100 und 500 erhöhen
void CCinit(void) {                              // initialize CC1101

cc1101_Deselect();                                  // some deselect and selects to init the cc1101
delayMicroseconds(30);

cc1101_Select();
delayMicroseconds(30);

cc1101_Deselect();
delayMicroseconds(45);

cmdStrobe(CC1101_SRES);



Gruß Ralf

Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 05 Februar 2017, 19:23:13
Zitat von: Sidey am 05 Februar 2017, 15:10:26
Schade, wäre wohl zu einfach gewesen...

@Sidey - Wir bleibe dran.
Mir fiel was auf. Du fragst via #ifdef ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101 das Board ab.
Nachdem ich nun die Abfrage einfach mal in einen Sketch nahm und testete, bekomme ich keine Übereinstimmung und somit bin ich in der Sonst-Schleife.
Woher nimmst du diesen Wert? Hast du oder dein Programm die Board.txt ergänzt / geändert?

Wenn ich nach dem ergänzen der Herstellerdateien in Arduino IDE nachsehe, so habe ich neue Einträge aber keine die sich so benennen wie du Ihn abfragst.
(Windows 10 / Arduino) Nicht das dies bei versch. Programmen / Betriebssystemen anders gehandhabt wird.

@Ralf, ich werde das mal testen.

Edit: Es war spät und selbst erklärend :) Dennoch gibt es eine warme Spur!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Brandenburger am 06 Februar 2017, 11:52:56
Hallo Sidey,

seit ich meine TFA30.3121 mit dem SIGNALduino empfange, tauchen in den logs sporadische Temperaturwerte von 30.0°C auf.

2017-02-06_03:33:42 Sensor1 humidity: 81.0
2017-02-06_03:36:40 Sensor1 humidity: 80.0
2017-02-06_03:58:10 Sensor1 temperature: 30.0
2017-02-06_03:59:09 Sensor1 temperature: 2.7
2017-02-06_04:18:44 Sensor1 temperature: 30.0
2017-02-06_04:19:43 Sensor1 temperature: 2.6
2017-02-06_04:32:28 Sensor1 temperature: 30.0
2017-02-06_04:33:26 Sensor1 temperature: 2.6
2017-02-06_06:00:20 Sensor1 temperature: 2.4
2017-02-06_06:39:16 Sensor1 humidity: 79.0
2017-02-06_06:40:15 Sensor1 humidity: 80.0

Die Versionen von fhem, SIGNALduino und CUL_TX sind aktuell.
Beim CUL433 ware alle empfangenen Werte korrekt.

Grüße aus Brandenburg! :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 06 Februar 2017, 15:48:33
Hallo,

@Ralf, deine Variante brachte nichts.

@Sidey, schau bitte mal in deine output.h an.
Zitat#define portOfPin(P)\
  (((P)>=0&&(P)<8)?&PORTD:(((P)>7&&(P)<14)?&PORTB:&PORTC))
#define ddrOfPin(P)\
  (((P)>=0&&(P)<8)?&DDRD:(((P)>7&&(P)<14)?&DDRB:&DDRC))
#define pinOfPin(P)\
  (((P)>=0&&(P)<8)?&PIND:(((P)>7&&(P)<14)?&PINB:&PINC))
#define pinIndex(P)((uint8_t)(P>13?P-14:P&7))
#define pinMask(P)((uint8_t)(1<<pinIndex(P)))

#define pinAsInput(P) *(ddrOfPin(P))&=~pinMask(P)
#define pinAsInputPullUp(P) *(ddrOfPin(P))&=~pinMask(P);digitalHigh(P)
#define pinAsOutput(P) *(ddrOfPin(P))|=pinMask(P)
#define digitalLow(P) *(portOfPin(P))&=~pinMask(P)
#define digitalHigh(P) *(portOfPin(P))|=pinMask(P)
#define isHigh(P)((*(pinOfPin(P))& pinMask(P))>0)
#define isLow(P)((*(pinOfPin(P))& pinMask(P))==0)
#define digitalState(P)((uint8_t)isHigh(P))
Hier werden Ports "umgewandelt" in PIN-Bezeichnunen ABER vermutlich nur bis 13.
Alle Ports/Pins über 13, also 14/15/16/(17) welche für den Radino benutzt werden, würden somit "ausgegrenzt" werde.

Ansatz?
Gegenüberstellung zur Verdeutlichung (https://github.com/pololu/fastgpio-arduino)
""Zitat:  (note that this code only works with ATmega8/168/328-based board such Arduino Uno. "" (http://masteringarduino.blogspot.de/2013/10/fastest-and-smallest-digitalread-and.html)

Grüße

PS: Später werde ich noch einen Test hochladen, wo du siehst, das bei einem simplen ISP Beispiel (nicht das Ersthochgeladene von den Vorseiten) die Initialisierung klappt.

EDIT: 1)LINK mit ggf. richtiger Erweiterung - Abschnitt "// --- Arduino Leonardo ---" (https://github.com/watterott/Arduino-Libs/blob/master/digitalWriteFast/digitalWriteFast.h)
          2) SPI_Test Sketch womit es auf beiden Systemen klappt
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 07 Februar 2017, 15:42:07
Jippi, und Hallo,  ;)

Zitat von: HomeAuto_User am 06 Februar 2017, 15:48:33
@Sidey, schau bitte mal in deine output.h an.Hier werden Ports "umgewandelt" in PIN-Bezeichnunen ABER vermutlich nur bis 13.
Alle Ports/Pins über 13, also 14/15/16/(17) welche für den Radino benutzt werden, würden somit "ausgegrenzt" werde.
Ansatz?

Bitte folgende Änderungen registrieren und übernehmen. CC1101 wird initialisiert und der Test mit FHEM steht noch aus.!
Es wurde für den radinoCC1101 umgesetzt mit Vorbereitung für das Mark433_PIN.
Parallel dazu habe ich die Version auch schon auf den NANO getestet.

Änderungen zusammengefasst und Files liegen bei. Sie basieren auf den "letzten Source" von vor 2 Tagen.
Zitat// output.h
// Radino
#define portOfPin(P) \
((((P) >= 0 && (P) <= 4) || (P) == 6 || (P) == 12 || (P) == 24 || (P) == 25 || (P) == 29) ? &PORTD : (((P) == 5 || (P) == 13) ? &PORTC : (((P) >= 18 && (P) <= 23)) ? &PORTF : (((P) == 7) ? &PORTE : &PORTB)))
#define ddrOfPin(P) \
((((P) >= 0 && (P) <= 4) || (P) == 6 || (P) == 12 || (P) == 24 || (P) == 25 || (P) == 29) ? &DDRD : (((P) == 5 || (P) == 13) ? &DDRC : (((P) >= 18 && (P) <= 23)) ? &DDRF : (((P) == 7) ? &DDRE : &DDRB)))
#define pinOfPin(P) \
((((P) >= 0 && (P) <= 4) || (P) == 6 || (P) == 12 || (P) == 24 || (P) == 25 || (P) == 29) ? &PIND : (((P) == 5 || (P) == 13) ? &PINC : (((P) >= 18 && (P) <= 23)) ? &PINF : (((P) == 7) ? &PINE : &PINB)))
#define pinIndex(P) \
(((P) >= 8 && (P) <= 11) ? (P) - 4 : (((P) >= 18 && (P) <= 21) ? 25 - (P) : (((P) == 0) ? 2 : (((P) == 1) ? 3 : (((P) == 2) ? 1 : (((P) == 3) ? 0 : (((P) == 4) ? 4 : (((P) == 6) ? 7 : (((P) == 13) ? 7 : (((P) == 14) ? 3 : (((P) == 15) ? 1 : (((P) == 16) ? 2 : (((P) == 17) ? 0 : (((P) == 22) ? 1 : (((P) == 23) ? 0 : (((P) == 24) ? 4 : (((P) == 25) ? 7 : (((P) == 26) ? 4 : (((P) == 27) ? 5 : 6 )))))))))))))))))))
// fehlt in pins_arduino.h
#define pinMask(P)((uint8_t)(1<<pinIndex(P)))


// output.h
// Nano
#define portOfPin(P)\
  (((P)>=0&&(P)<8)?&PORTD:(((P)>7&&(P)<14)?&PORTB:&PORTC))
#define ddrOfPin(P)\
  (((P)>=0&&(P)<8)?&DDRD:(((P)>7&&(P)<14)?&DDRB:&DDRC))
#define pinOfPin(P)\
  (((P)>=0&&(P)<8)?&PIND:(((P)>7&&(P)<14)?&PINB:&PINC))
#define pinIndex(P)((uint8_t)(P>13?P-14:P&7))
#define pinMask(P)((uint8_t)(1<<pinIndex(P)))



//RF_Receiver.ino
#define VERSION_2               0x1d

//// Änderungsbeginn  --->
#ifdef CMP_CC1101
  #ifdef ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101
    // radinoCC1101
    #define PIN_LED               13  // Message-LED gn
    #define PIN_SEND              9   // gdo0Pin TX out
    #define SS   8                    // CSN out - NOTWENDIG !!!!
    #define PIN_RECEIVE           7   // GDO2
    #define PIN_MARK433           4   // LOW -> 433Mhz | HIGH -> 868Mhz
    // fehlt in pins_arduino.h - ICT
    #define digitalPinToInterrupt(p) ((p) == 0 ? 2 : ((p) == 1 ? 3 : ((p) == 2 ? 1 : ((p) == 3 ? 0 : ((p) == 7 ? 4 : NOT_AN_INTERRUPT)))))
  #else
    // CC1101 ohne radino
    #define PIN_LED               LED_BUILTIN   // Message-LED gn
    #define PIN_SEND              3   // gdo0Pin TX out
    #define PIN_RECEIVE           2
  #endif
#else
    // getrennte Funkempf.
  #define PIN_LED               13   // Message-LED
  #define PIN_SEND              11
  #define PIN_RECEIVE           2
#endif
//// Änderungsende --->

#define BAUDRATE          57600


  pinAsOutput(PIN_LED);

//// Änderungsbeginn  ---> 
  // radino
#ifdef ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101
  pinAsOutput(PIN_MARK433);
  if (isLow(PIN_MARK433)) {
    Serial.println("433Mhz radino CC1101");
    } else {
    Serial.println("868Mhz radino CC1101");
    }
#endif
//// Änderungsende ---> 

  // CC1101
#ifdef CMP_CC1101

Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Februar 2017, 19:32:22
Bei den Superheterodyne Empfängern gibt es auch den RXB8. Weiß zufällig jemand wie gut dieser im Vergleich zum RXB6 2.0 ist?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 Februar 2017, 19:56:02
Ich habe einen... Der funktioniert gut... Ob er besser oder schlechter ist konnte ich nicht feststellen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 09 Februar 2017, 17:40:56
Guten Tag,

Zitat von: HomeAuto_User am 07 Februar 2017, 15:42:07
Jippi, und Hallo,  ;)
...
Änderungen zusammengefasst und Files liegen bei. Sie basieren auf den "letzten Source" von vor 2 Tagen.
Grüße

ich muss mich selber korrigieren, da die Modulvariante nicht korrekt ausgewertet wurde.
Der Code wurde angepasst und nun vollständigkeit halber erneut das File noch einmal um diese einbauen zu können.
In FHEM läuft der radino perfekt, somit ist die Realisierung auf dem ATmega32U4 erfolgt.

Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 09 Februar 2017, 21:00:00
Guten Abend,

Ich lasse soeben die Firmware arbeiten...
Gibt es schon Erfahrungen beim Verhalten mit mehreren Sendern welche sehr zeitgleich senden aber auch sehr häufig?

Die Protokolle können nur teilweise entschlüsselt werden aber öfters kommen immer andere Protokollfindungen.
Das "Durcheinader" scheint den SIGNALduino kurzzeitig zu trennen bzw. zu restarten.

Zitat2017.02.09 20:56:23 5: SIGNALduino/RAW READ: /MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0
2017.02.09 20:56:23 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0/101012121
2017.02.09 20:56:23 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121/212121210121210121
2017.02.09 20:56:23 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121/012121212
2017.02.09 20:56:23 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212/101010101
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101/212101213101212121
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121/010101212101010121
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121010101212101010121/212121212
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121010101212101010121212121212/101212101
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121010101212101010121212121212101212101/210121212421010101
2017.02.09 20:56:24 5: SIGNALduino/RAW READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121010101212101010121212121212101212101210121212421010101/012121012567;CP=1;R=233;

2017.02.09 20:56:24 4: SIGNALduino/msg READ: MU;P0=-982;P1=494;P2=-1956;P3=-3888;P4=800;P5=144;P6=-18240;P7=96;D=0101012121212121210121210121012121212101010101212101213101212121010101212101010121212121212101212101210121212421010101012121012567;CP=1;R=233;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MC;LL=-1008;LH=941;SL=-517;SH=457;D=68B59EFC16F2AB98CA8;C=487;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MC;LL=-1008;LH=941;SL=-517;SH=457;D=68B59EFC16F2AB98CA8;C=487;/L=73;R=0;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MC;LL=-1008;LH=941;SL=-517;SH=457;D=68B59EFC16F2AB98CA8;C=487;L=73;R=0;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MC;LL=-1015;LH=945;SL=-497;SH=465;D=5A2D77BF05BCAAE6B92;C=486;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MC;LL=-1015;LH=945;SL=-497;SH=465;D=5A2D77BF05BCAAE6B92;C=486;/L=75;R=5;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MC;LL=-1015;LH=945;SL=-497;SH=465;D=5A2D77BF05BCAAE6B92;C=486;L=75;R=5;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MU;P0=-1033;P1=448;P2=-528;P3=926;D=01212303012
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MU;P0=-1033;P1=448;P2=-528;P3=926;D=01212303012/121212321
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MU;P0=-1033;P1=448;P2=-528;P3=926;D=01212303012121212321/210121230
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MU;P0=-1033;P1=448;P2=-528;P3=926;D=01212303012121212321210121230/32121212
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MU;P0=-1033;P1=448;P2=-528;P3=926;D=0121230301212121232121012123032121212/1012;CP=1;R=0;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MU;P0=-1033;P1=448;P2=-528;P3=926;D=01212303012121212321210121230321212121012;CP=1;R=0;
2017.02.09 20:56:43 4: Found matched Protocol id 21 -> einhell garagedoor
2017.02.09 20:56:43 5: Starting demodulation at Position 0
2017.02.09 20:56:43 5: restarting demodulation at Position 2+2
2017.02.09 20:56:43 5: restarting demodulation at Position 6+2
2017.02.09 20:56:43 5: restarting demodulation at Position 14+2
2017.02.09 20:56:43 5: restarting demodulation at Position 20+2
2017.02.09 20:56:43 5: restarting demodulation at Position 24+2
2017.02.09 20:56:43 4: Found matched Protocol id 8 -> TX3 Protocol
2017.02.09 20:56:43 5: Starting demodulation at Position 5
2017.02.09 20:56:43 5: restarting demodulation at Position 19+2
2017.02.09 20:56:43 5: restarting demodulation at Position 25+2
2017.02.09 20:56:43 4: Found matched Protocol id 16 -> Dooya shutter
2017.02.09 20:56:43 5: Starting demodulation at Position 1
2017.02.09 20:56:43 5: restarting demodulation at Position 7+2
2017.02.09 20:56:43 5: restarting demodulation at Position 16+2
2017.02.09 20:56:43 5: restarting demodulation at Position 21+2
2017.02.09 20:56:43 5: restarting demodulation at Position 28+2
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MC;LL=-1035;LH=928;SL=-541;SH=431;D=5ADF7E0B7955CCE84;C=489;L=
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MC;LL=-1035;LH=928;SL=-541;SH=431;D=5ADF7E0B7955CCE84;C=489;L=/66;R=0;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MC;LL=-1035;LH=928;SL=-541;SH=431;D=5ADF7E0B7955CCE84;C=489;L=66;R=0;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MC;LL=-1035;LH=928;SL=-541;SH=431;D=75F0C74;C=489;L=26;R=0;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MC;LL=-1035;LH=928;SL=-541;SH=431;D=75F0C74;C=489;L=26;R=0;
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: /MC;LL=-1015;LH=944;SL=-525;SH=439;D=7FE6EEEBE2BA8;C=487;L=49;R
2017.02.09 20:56:43 5: SIGNALduino/RAW READ: MC;LL=-1015;LH=944;SL=-525;SH=439;D=7FE6EEEBE2BA8;C=487;L=49;R/=228;

2017.02.09 20:56:43 4: SIGNALduino/msg READ: MC;LL=-1015;LH=944;SL=-525;SH=439;D=7FE6EEEBE2BA8;C=487;L=49;R=228;
2017.02.09 20:56:44 5: SIGNALduino/RAW READ: /MC;LL=-1020;LH=924;SL=-545;SH=437;D=51D668B59B0C1522D5B2A68;C=
2017.02.09 20:56:44 5: SIGNALduino/RAW READ: MC;LL=-1020;LH=924;SL=-545;SH=437;D=51D668B59B0C1522D5B2A68;C=/487;L=89;R=63;

2017.02.09 20:56:44 4: SIGNALduino/msg READ: MC;LL=-1020;LH=924;SL=-545;SH=437;D=51D668B59B0C1522D5B2A68;C=487;L=89;R=63;
2017.02.09 20:56:44 5: SIGNALduino/RAW READ: /MC;LL=-1013;LH=944;SL=-536;SH=445;D=2D76C30548B56C222;C=489;L=67;R=63;

2017.02.09 20:56:44 4: SIGNALduino/msg READ: MC;LL=-1013;LH=944;SL=-536;SH=445;D=2D76C30548B56C222;C=489;L=67;R=63;
2017.02.09 20:56:45 5: SIGNALduino/RAW READ: /MC;LL=-1008;LH=935;SL=-532;SH=450;D=BB0C1522D5B3BC8;C=487;L=57
2017.02.09 20:56:45 5: SIGNALduino/RAW READ: MC;LL=-1008;LH=935;SL=-532;SH=450;D=BB0C1522D5B3BC8;C=487;L=57/;R=63;

2017.02.09 20:56:45 4: SIGNALduino/msg READ: MC;LL=-1008;LH=935;SL=-532;SH=450;D=BB0C1522D5B3BC8;C=487;L=57;R=63;
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: /MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=/34243464040414141
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=34243464040414141/404141404
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=34243464040414141404141404/14141404
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=3424346404041414140414140414141404/04040404040414140
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=342434640404141414041414041414140404040404040414140/414140404040414141
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=342434640404141414041414041414140404040404040414140414140404040414141/414141414
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=342434640404141414041414041414140404040404040414140414140404040414141414141414/14;CP=4;R=230;

2017.02.09 20:56:49 4: SIGNALduino/msg READ: MU;P0=-1992;P1=-991;P2=-148;P3=-444;P4=467;P6=-9152;D=34243464040414141404141404141414040404040404041414041414040404041414141414141414;CP=4;R=230;
2017.02.09 20:56:49 4: Found matched Protocol id 8 -> TX3 Protocol
2017.02.09 20:56:49 5: Starting demodulation at Position 11
2017.02.09 20:56:49 5: restarting demodulation at Position 17+2
2017.02.09 20:56:49 5: restarting demodulation at Position 23+2
2017.02.09 20:56:49 5: restarting demodulation at Position 43+2
2017.02.09 20:56:49 5: restarting demodulation at Position 49+2
2017.02.09 20:56:49 5: restarting demodulation at Position 61+2
2017.02.09 20:56:49 4: Found matched Protocol id 16 -> Dooya shutter
2017.02.09 20:56:49 5: Starting demodulation at Position 11
2017.02.09 20:56:49 5: restarting demodulation at Position 17+2
2017.02.09 20:56:49 5: restarting demodulation at Position 23+2
2017.02.09 20:56:49 5: restarting demodulation at Position 43+2
2017.02.09 20:56:49 5: restarting demodulation at Position 49+2
2017.02.09 20:56:49 5: restarting demodulation at Position 61+2
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: /MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=0121
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=0121/21313131
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=012121313131/21313121313131212
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=01212131313121313121313131212/121212121
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=01212131313121313121313131212121212121/213131213
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=01212131313121313121313131212121212121213131213/13121212121313131
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=0121213131312131312131313121212121212121313121313121212121313131/3131313131012;CP=1;R=229;

2017.02.09 20:56:49 4: SIGNALduino/msg READ: MU;P0=-4040;P1=441;P2=-1856;P3=-1026;D=01212131313121313121313131212121212121213131213131212121213131313131313131012;CP=1;R=229;
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: /MU;P0=-212;P1=473;P2=-1995;P3=-997;D=0121313
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=0121313/131213131
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=0121313131213131/21313131212121212
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=012131313121313121313131212121212/12121313121313121
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=01213131312131312131313121212121212121313121313121/212121313
2017.02.09 20:56:49 5: SIGNALduino/RAW READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=01213131312131312131313121212121212121313121313121212121313/10;CP=1;R=229;

2017.02.09 20:56:49 4: SIGNALduino/msg READ: MU;P0=-212;P1=473;P2=-1995;P3=-997;D=0121313131213131213131312121212121212131312131312121212131310;CP=1;R=229;
2017.02.09 20:56:49 4: Found matched Protocol id 8 -> TX3 Protocol
2017.02.09 20:56:49 5: Starting demodulation at Position 3
2017.02.09 20:56:49 5: restarting demodulation at Position 9+2
2017.02.09 20:56:49 5: restarting demodulation at Position 15+2
2017.02.09 20:56:49 5: restarting demodulation at Position 35+2
2017.02.09 20:56:49 5: restarting demodulation at Position 41+2
2017.02.09 20:56:49 5: restarting demodulation at Position 53+2
2017.02.09 20:56:49 4: Found matched Protocol id 16 -> Dooya shutter
2017.02.09 20:56:49 5: Starting demodulation at Position 3
2017.02.09 20:56:49 5: restarting demodulation at Position 9+2
2017.02.09 20:56:49 5: restarting demodulation at Position 15+2
2017.02.09 20:56:49 5: restarting demodulation at Position 35+2
2017.02.09 20:56:49 5: restarting demodulation at Position 41+2
2017.02.09 20:56:49 5: restarting demodulation at Position 53+2
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: /MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=/14521213
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=14521213/131312131312131313
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=14521213131312131312131313/121212121212121
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=14521213131312131312131313121212121212121/313121313
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=14521213131312131312131313121212121212121313121313/12121212
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=1452121313131213131213131312121212121212131312131312121212/1313131313131313;CP=1;SP=4;R=228;

2017.02.09 20:56:50 4: SIGNALduino/msg READ: MS;P1=462;P2=-1976;P3=-997;P4=-4068;P5=328;D=14521213131312131312131313121212121212121313121313121212121313131313131313;CP=1;SP=4;R=228;
2017.02.09 20:56:50 4: Found matched Protocol id 7 -> weatherID7
2017.02.09 20:56:50 5: Starting demodulation at Position 2
2017.02.09 20:56:50 5: Found wrong signal, aborting demodulation
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: /MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D/=0
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D=0/12121313121313121
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D=012121313121313121/212121313131313131
2017.02.09 20:56:50 5: SIGNALduino/RAW READ: MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D=012121313121313121212121313131313131/31314156;CP=1;R=219;

2017.02.09 20:56:50 4: SIGNALduino/msg READ: MU;P0=-488;P1=424;P2=-1984;P3=-1013;P4=-3992;P5=-8800;P6=168;D=01212131312131312121212131313131313131314156;CP=1;R=219;
2017.02.09 20:56:50 4: Found matched Protocol id 16 -> Dooya shutter
2017.02.09 20:56:50 5: Starting demodulation at Position -1
2017.02.09 20:56:52 5: SIGNALduino/RAW READ: /MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=012101210121212
2017.02.09 20:56:52 5: SIGNALduino/RAW READ: MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=012101210121212/121212121
2017.02.09 20:56:52 5: SIGNALduino/RAW READ: MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=012101210121212121212121/010121010101010121
2017.02.09 20:56:52 5: SIGNALduino/RAW READ: MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=012101210121212121212121010121010101010121/01210101012101012
2017.02.09 20:56:52 5: SIGNALduino/RAW READ: MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=01210121012121212121212101012101010101012101210101012101012/134;CP=1;R=229;

2017.02.09 20:56:52 4: SIGNALduino/msg READ: MU;P0=-2054;P1=449;P2=-4064;P3=-7528;P4=112;D=01210121012121212121212101012101010101012101210101012101012134;CP=1;R=229;

Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 17 Februar 2017, 21:54:01
Ich habe mir mit dem 3,3V 8 MHz pro mini und dem cc1101 einen Signalduino zusammengebaut. Dies hat den Vorteil, daß damit keine Levelshifter notwendig sind.

Hier habe ich was über die Baudrate beim AVR gefunden:
http://wormfood.net/avrbaudcalc.php?bitrate=9600%2C19.2k%2C28.8k%2C38.4k%2C57.6k%2C76.8k%2C115.2k%2C230.4k%2C250k&clock=8%2C16&databits=8

Demnach ist bei 8 MHz die Baudrate 57600 nicht so gut. Der error ist mit 2.1% zwischen recommended and absolute max error rates.
Weiß zufällig jemand ob mit diesem Baudraten error von 2,1% noch ein stabiler und zuverlässiger Betrieb möglich ist oder kann es bei ungünstigen Umständen zu Bitfehlern kommen?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: BlackStone am 18 Februar 2017, 19:56:00
ich habe noch einen nanocul bei mir rumstauben, mit RF1100SE (433 mhz variante), kann ich den einfach umflashen ?

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: rageltus am 18 Februar 2017, 21:35:32
Ja. Geht. Der signalduino ist dann analog dem Selbstbau cul im wiki. Dran denken, dass du die richtige Hex nimmst nanoc1101 aus dem dev33 Branch vom signalduino Modul!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: BlackStone am 18 Februar 2017, 22:29:21
hab zwar den source gefunden, nur leider kann ich hier grade ned kompilieren.
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101

ok, ich nutze mal die einfache variante. ^^
https://forum.fhem.de/index.php/topic,61774.msg554241.html#msg554241
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: rageltus am 18 Februar 2017, 23:52:19
Genau. Aber beachten, dass du bei dem Arzt model die c1101 Variante auswählst!!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: BlackStone am 19 Februar 2017, 00:38:37
nu, scheint zu funktionieren. jedoch noch keine signale reinbekommen, von meinen somfy`s (RTS)


ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:1500.13Baud) 2017-02-19 00:28:39
cmds V R t X F S P C r W x e 2017-02-19 00:29:17
config MS=1;MU=1;MC=1 2017-02-19 00:29:24
freeram 879 2017-02-18 23:05:45
ping OK 2017-02-19 00:31:48
raw  2017-02-19 00:06:35
state opened 2017-02-19 00:25:42
uptime 0 00:04:14 2017-02-19 00:29:56
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dela2017 am 20 Februar 2017, 10:44:54
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:
ZitatHi, 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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 25 Februar 2017, 17:27:55
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 25 Februar 2017, 18:29:46
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.
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 25 Februar 2017, 19:08:04
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Februar 2017, 19:36:33
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.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 26 Februar 2017, 00:37:50
Guten Abend,

Zitat von: Ralf9 am 25 Februar 2017, 18:29:46
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 26 Februar 2017, 19:58:03
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 26 Februar 2017, 20:20:23
Hi,
Schau  mal hier https://forum.fhem.de/index.php/topic,58396.msg521044.html#msg521044.
Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 Februar 2017, 21:08:25
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 26 Februar 2017, 23:38:05
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 27 Februar 2017, 18:33:45
Hallo,

Zitat von: Ralf9 am 25 Februar 2017, 18:29:46
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.
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
Zitatupdate 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.

Zitat2017-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
Zitat2017-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.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Februar 2017, 20:53:37
Zitatdanach 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.

ZitatWar 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 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 03 März 2017, 12:38:01
Hallo und danke Ralf,

Zitat von: Ralf9 am 27 Februar 2017, 20:53:37
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 (https://forum.fhem.de/index.php/topic,68327.msg598149.html#msg598149) wird nun alles diesbezüglich gesammelt und weiter darüber berichtet.
Hoffentlich mit einem Erfolg  :-\.

LG
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 12 März 2017, 01:23:08
Zitat von: Ralf9 am 30 Oktober 2016, 18:59:47
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 12 März 2017, 09:39:59
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

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 12 März 2017, 15:18:42
Hi,

ja das kenn ich und hab keine anpassung zum C1101.
Ich meine aber den Anschluss an den D1 mini mit ESP8622.
Hier ist im Bild auch ein Spannungteiler. Ich möchte den nano mit dem D1 mini ESP8622 verbinden.
Auf dem bild ist ein mini mit dem D1mini verbunden.

Brauch ich den Spannungsteiler?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 12 März 2017, 15:47:07
Ich würde sagen, nein.
Kannst aber mal nachmessen, wenn du 3,3v hast dann nicht

Gesendet von meinem E6653 mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 März 2017, 17:38:50
Beim nano und beim 5V 16MHz pro mini ist ein Spanunngsteiler notwendig.
Beim 3,3V 8MHz pro mini ist der Spanunngsteiler nicht notwendig.

Die Werte 22K und 10K habe ich von der Schaltung von @hjgode, Du kannst auch 10k und 4,7K nehmen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 12 März 2017, 19:23:56
Ok danke.
Dann muss ich mir noch widerstände holen...
Ich dachte beim Nano wären die Datenleitungen auch nur 3,3V.
Kann ja auch nochmal messen.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 12 März 2017, 20:21:23
Hi,
aber besser wäre 470 Ohm / 1k Ohm - schau mal im Thread der Sammelbestellung für den NanoCUL, da gibt es Bilder über die Signaleigenschaften!
Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 12 März 2017, 21:17:01
Ok danke Arnd, dann nehme ich die.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: anfichtn am 28 März 2017, 19:22:52
Guten Abend zusammen.

mein System hat keine Lust zum compilieren... Kann mir jemand das aktuelle Build für den cc1101 am Mini Pro 3v3 zusammenwerfen und zukommen lassen?

Danke und Grüße

anfichtn
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 März 2017, 22:34:32
Zitat von: anfichtn am 28 März 2017, 19:22:52
mein System hat keine Lust zum compilieren... Kann mir jemand das aktuelle Build für den cc1101 am Mini Pro 3v3 zusammenwerfen und zukommen lassen?

SIGNALduino_promini328_3v3 mit cc1101 Support:
https://drive.google.com/file/d/0B3UU1FxM6ZDUUWluOW9LSUpXMmM/view?usp=sharing
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: anfichtn am 29 März 2017, 00:08:52
Zitat von: Sidey am 28 März 2017, 22:34:32
SIGNALduino_promini328_3v3 mit cc1101 Support:
https://drive.google.com/file/d/0B3UU1FxM6ZDUUWluOW9LSUpXMmM/view?usp=sharing

Danke :)

Version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 28 2017 22:31:59

Grüße

anfichtn
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Wallmeier am 31 März 2017, 21:35:15
Zitat von: Sidey am 28 März 2017, 22:34:32
SIGNALduino_promini328_3v3 mit cc1101 Support:
https://drive.google.com/file/d/0B3UU1FxM6ZDUUWluOW9LSUpXMmM/view?usp=sharing

Ich habe die angehängt Firmware auf einen miniCUL von locutus geflasht. Das Flashen selber hat funktioniert. Allerdings empfängt der miniCUL mit der Firmware nichts. Dies liegt vermutlich daran, dass sich miniCUL und nanoCUL in der Beschaltung des CC1101 leicht unterscheiden - CC1100_OUT_PIN und CC1101_IN_PIN sind genau vertauscht. Bei den Sourcen der a-culfw wüsste ich mir selber zu helfen - aber ich finde gerade die passende Stelle in den Sourcen des SignalDuinos nicht :( Könnte mich bitte jemand in die richtige Richtung schupsen...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 01 April 2017, 23:47:28
Zitat von: Wallmeier am 31 März 2017, 21:35:15
Ich habe die angehängt Firmware auf einen miniCUL von locutus geflasht.

Welcher Chip wird da verwendet und mit welcher Taktrate läuft er?
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 02 April 2017, 07:29:18
Hi,
Aus anderem Thread:
"Der miniCUL besteht in wesentlichen aus einem AVR-Mikrocontroller und einem Funkmodul:
- ATMEGA328P (8 MHz / 3,3 V)
- CC1101"
Quelle: https://forum.fhem.de/index.php?topic=55705.msg473015#msg473015
bzw. "Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328"
Quelle: https://forum.fhem.de/index.php/topic,26487.msg194747.html#msg194747
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Wallmeier am 02 April 2017, 09:50:21
Der miniCUL verwendet den Atmega 328P (8MHz, 3,3V) mit dem CC1101 - allerdings sind GDO0 und GDO2 genau getauscht zum nanoCUL. Das sieht man gut in den entsprechenden board.h-Definitionen der a-culfw.

nanoCUL:
#define CC1100_OUT_PORT         PORTD
#define CC1100_OUT_PIN          PD3

#define CC1100_IN_PORT          PIND
#define CC1100_IN_PIN           PD2


miniCUL:
#define CC1100_OUT_PORT PORTD
#define CC1100_OUT_PIN 2

#define CC1100_IN_PORT PIND
#define CC1100_IN_PIN 3
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 April 2017, 11:00:03
Zitat von: Wallmeier am 31 März 2017, 21:35:15
Dies liegt vermutlich daran, dass sich miniCUL und nanoCUL in der Beschaltung des CC1101 leicht unterscheiden - CC1100_OUT_PIN und CC1101_IN_PIN sind genau vertauscht. Bei den Sourcen der a-culfw wüsste ich mir selber zu helfen - aber ich finde gerade die passende Stelle in den Sourcen des SignalDuinos nicht :( Könnte mich bitte jemand in die richtige Richtung schupsen...

Wegen der Vertauschung von CC1100_OUT_PIN und CC1101_IN_PIN, wird es nur mit selbst compilieren funktionieren. Dazu musst Du in der  RF_Receiver.ino die Zeilen 48 - 50 anpassen
https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101/RF_Receiver/RF_Receiver.ino

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Wallmeier am 02 April 2017, 11:50:21
Wunderbar - das war der Schups den ich gebraucht habe! Die anderen Pin-Definitionen für den CC1101 waren alle in der Datei cc1101.h, da habe ich die Datei RF_Receiver.ino komplett übersehen...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 April 2017, 19:06:15
Zitat von: anfichtn am 30 März 2017, 10:21:19
Meine Logfiles füllen sich... leider nicht mit besonders brauchbaren Dingen.

Bitte versuch es mal mit der Firmware in der Anlage. Diese Firmware ist nur für den 3,3V promini.
- Ins Fimware Verzeichnis kopieren
- attr sduino hardware promini3v3
- set flash
- factory reset mit "get raw e" oder im seriellen Monitor "e" (nur falls vorher schon eine andere Firmware geflasht war)
- evtl noch ein "set cc1101_bWidth" 500 oder 600 (ist evtl bei Sensoren mit der Protocol Id 7 notwendig)

Nachtrag:
Falls Du die empfangenen Nachrichten mit dem seriellen Monitor oder Putty anschaust, nicht wundern.
Dies ist eine Version in der die seriell übertragenen Daten reduziert werden.
Die Reduktion wird mit "CER" eingeschaltet und mit "CDR" ausgeschaltet.
Ohne die Datenreduktion kann es vorkommen, daß die Daten im FIFO, in dem die vom Empfänger empfangenen Daten gepuffert werden, nicht schnell genug verarbeitet und übertragen werden.

Dies ist eine Vorabversion vom "dev-r33_messagecompression" branch. 
Außer der messagecompression wurde der FIFO auf 100 erhöht.
Es wurden auch Fehler bei der Verarbeitung von MS- und MC-Nachrichten beseitigt.

Hier sind einige Schaltungsvarianten
https://forum.fhem.de/index.php/topic,69042.0.html

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: anfichtn am 02 April 2017, 22:35:41
Ist geflasht.

Was erhoffst du dadurch?
Bzw worauf sollte ich jetzt achten?

Grüße

anfichtn
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 April 2017, 23:37:00
Ich wollte damit ausschließen, das es an der Firmware liegt.
Matched MS Protocol id 7 -> weatherID7
Das hier deutet auf einen Sensor mit der Protocol ID 7 hin. Meine Eurochon EAS800z und FreeTec NC-7345 werden damit sehr gut durch eine Betondecke empfangen.
Falls Du einen anderen Temperatursensor hast, besteht auch die Möglichkeit, daß dieser vom Signalduino nocht nicht unterstützt wird.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: anfichtn am 08 April 2017, 11:07:05
Moin,

Ich konnte das Problem jetzt lösen. Ich habe testweise die 5cm Stabantenne sie dem Modul beilag durch herumfliegende 34cm Draht ersetzt... Das entspricht einer Antennenlänge von 1/2 lambda, und führte zu einer signifikant gestiegenen Empfangsleistung.

Jetzt habe ich zwar mehr unerkannte Signale, kann aber meine Sensoren sicher zuordnen.

Grüße

anfichtn
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 13 April 2017, 21:06:54
Hi Ralf,

ich stocke gerade etwas mit deiner Anleitung hier:
Zitat von: Ralf9 am 30 Oktober 2016, 18:59:47
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

Ich habe den arduino nano mit sduino geflashed, den wemos verkabelt mit Wiederständen wie beschrieben.
Was muss ich nun auf den Wemos flashen?

Auch hat der nano anstatt TX0 und RX1 nur TX1 und RX0. Ist das egal?

Noch ein Problem, schließe ich 5V und GND an leuchtet der Nano und der Wemos. Sobald ich D8 an RX0 anschließe ist die LED dunkler und geht aus. Warum braucht nur TX1 einen Spannungsteiler RX0 nicht?

Bin über Hilfe sehr dankbar.

Viele Grüße und frohe Ostern,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 13 April 2017, 22:04:22
Zitat von: stefanru am 13 April 2017, 21:06:54
Hi Ralf,

ich stocke gerade etwas mit deiner Anleitung hier:
Ich habe den arduino nano mit sduino geflashed, den wemos verkabelt mit Wiederständen wie beschrieben.
Was muss ich nun auf den Wemos flashen?

Auch hat der nano anstatt TX0 und RX1 nur TX1 und RX0. Ist das egal?

Noch ein Problem, schließe ich 5V und GND an leuchtet der Nano und der Wemos. Sobald ich D8 an RX0 anschließe ist die LED dunkler und geht aus. Warum braucht nur TX1 einen Spannungsteiler RX0 nicht?

Bin über Hilfe sehr dankbar.

Viele Grüße und frohe Ostern,
Stefan
Habe sowas auch verbaut. Habe auf den wemos esp Link geflasht. Man kann sich dann über WLAN Firmwareupdate durchführen.

Gruß Sascha

Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 13 April 2017, 22:24:32
Hi,
Spannungsteiler braucht man nur in der einen Richtung, wo 5V auf 3,3 V runter müssen. Beim Rückweg werden nur 3,3V geliefert und machen an einem 5V Chip nichts kaputt, reichen aber um ein High-Pegel zu signalisieren.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 April 2017, 01:50:46
Hat Irgendjemand ein link zu ner Anleitung zum flashen von esp link auf den wemos d1 mini? Ich such mir hier einen Wolf....
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: PeMue am 14 April 2017, 08:15:46
Zitat von: stefanru am 14 April 2017, 01:50:46
Hat Irgendjemand ein link zu ner Anleitung zum flashen von esp link auf den wemos d1 mini? Ich such mir hier einen Wolf....
https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=68630 Kapitel 4  ;)

Gruß PeMue
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 April 2017, 12:44:46
Danke!

Wow das tut ja, coole Sache.

Habe aber ein Problem.
Wenn ich TX und RX beim Strom drauf geben angeschlossen habe startet der WEMOS nicht richtig.
Ich kann nicht zu ESP Link, also zur IP verbinden.

Lasse ich RX und TX ab geht es. Schließe ich sie dann an geht auch der signalduino in der uC anzusprechen und alles funktioniert.
Jemand eine Idee wieso das so ist?
Gibts ne möglichkeit das zu ändern?

Ich habe jetzt auch noch versucht das ganze anstatt mit einem sender empfänger mit cc1101 zu starten.
Der Sduino mit cc1101 läuft und die settings passen. Schließe ich ihn aber per WLAN an bekomme ich bei der Abfrage des CC1101:
ccconf: freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB (DataRate:24.80Baud)
Woran liegt das? Geht der CC1101 nicht am WEMOS?

Klaue ich dem CC1101 den Strom und schließe ich ihn wieder an wird er dann doch erkannt.

Gibt jetzt ne ziemlich schwierige startup Prozedur.
RX, TX vom Wemos abziehen. Strom drauf. RX, TX anschließen. VCC vom CC1101 abziehen und wieder anstecken.
Wie beim Space-Shuttle ;-)

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 14 April 2017, 14:11:33
Schaue mal hier nach.


http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/
(http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/)

Habe mich daran gehalten.
Bei mir läuft in moment der sduino mit cc1101 und wlan Anbindung ohne Probleme.

Gruß Sascha


Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 April 2017, 14:37:48
Na es läuft ja.
Nur dass die Bauteile nicht auf anhieb initialisieren wenn sie angeschlossen sind.
Hast du einen China Nano oder original?
Hast du wirklich alles so wie im Schaltplan dort?

Ich hab nur einen Spannungsteiler wie vorne von Ralf beschrieben.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 14 April 2017, 14:43:45
Ich habe erst den sduino mit dem cc1101 ohne spannungsteiler aufgebaut und geflasht. Funktioniert!
Dann den wemos mit esplink geflasht und konfiguriert. Funktioniert. (jetzt erst nur der Zugriff)
Dann den wemos "über" den arduino nano gelötet und verbunden. Auch alle 5v und gnd Leitungen.
TX mir rx und Rx mit tx des einen Baustein mit dem jeweils anderen Baustein.
Dann noch die rst Leitung gelötet. Diese ist wichtig, damit esplink den nano vom cul flashen kann.

Habe hier auch ein thread erstellt - > wlanduino

Gruß Sascha

Gesendet von meinem SM-T560 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 April 2017, 19:23:04
Ok danke Sash,

habe es nach dem Bild von Ralf auf der ersten Seite aufgebaut.
TX und RX vom Nano mit D7 und D8 vom Wemos mini verbunden.
In der TX Leitung ist ein Spannungsteiler 1kOhm / 470 Ohm.
+5V und GND verbunden. Power kommt vom Nano.
Rst habe ich nicht. Wo muss das denn an den Wemos?
Wie gesagt ich habe den Wemos D1 mini.

Laufen tut er ja, aber ich muss immer TX und RX trennen wenn der Strom weg war.

Gruß und Danke,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 14 April 2017, 19:38:41
Zitat von: stefanru am 14 April 2017, 19:23:04
Rst habe ich nicht. Wo muss das denn an den Wemos?
Wie gesagt ich habe den Wemos D1 mini.

Laufen tut er ja, aber ich muss immer TX und RX trennen wenn der Strom weg war.

Ich verwende den promini da musste ich TX und RX noch nie trennen.

Ich habe es hier mal aufgezeichnet:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 14 April 2017, 19:39:52
Zitat von: stefanru am 14 April 2017, 19:23:04
Ok danke Sash,

habe es nach dem Bild von Ralf auf der ersten Seite aufgebaut.
TX und RX vom Nano mit D7 und D8 vom Wemos mini verbunden.
In der TX Leitung ist ein Spannungsteiler 1kOhm / 470 Ohm.
+5V und GND verbunden. Power kommt vom Nano.
Rst habe ich nicht. Wo muss das denn an den Wemos?
Wie gesagt ich habe den Wemos D1 mini.

Laufen tut er ja, aber ich muss immer TX und RX trennen wenn der Strom weg war.

Gruß und Danke,
Stefan
WEMOS PIN D3 auf RESET des Arduino  auf D3

Gruß Sascha

Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 April 2017, 19:42:00
Ok werd ich probieren.
D3 des Wemos auf RST des Nano.

Danke!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 15 April 2017, 16:34:06
Muss in die RST noch ein Spannungsteiler?
Auf dem Bild von Ralf ist da ein 10k eingezeichnet.

Auf deinem fehlt RST. Wie mach ich das denn?
Habe in TX 470 Ohm und zu GND 1KOhm.
Jetzt müsste ich doch das selbe im RST machen oder geht RST anders rum und es ist kein Spannugsteiler bei mir nötig?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 15 April 2017, 17:15:04
Habe keinen Widerstand eingelötet. Schaue mal in den Kommentaren bei hjgode nach. Hatte da mit ihm auch geschrieben.

WeMos D3 an dem rst vom arduino
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 15 April 2017, 17:23:53
Ja hab ich gemacht.
Leider bleibt es dabei dass ich beim ersten mal hochfahren, also strom drauf, der Wemos nicht richtig startet. Auch reset hilft nix.
Ausweg: RX und Tx trennen, also D7 und D8 am Wemos und nochmal Wemos reset. Danach Rx und TX wieder dran.

Was hast du denn für Wiederstände in der TX Leitung?

Gruß,
Stefan

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 15 April 2017, 17:35:35
Gar keine

Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 15 April 2017, 19:11:12
Ok, dann versuche ich das auch nochmal.

Danke...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 15 April 2017, 19:55:28
Zitat von: stefanru am 15 April 2017, 17:23:53
Ja hab ich gemacht.
Leider bleibt es dabei dass ich beim ersten mal hochfahren, also strom drauf, der Wemos nicht richtig startet. Auch reset hilft nix.
Ausweg: RX und Tx trennen, also D7 und D8 am Wemos und nochmal Wemos reset. Danach Rx und TX wieder dran.

Was hast du denn für Wiederstände in der TX Leitung?

Ich verwende in der TX Leitung 4,7K und 10K. Der Levelshifter ist erforderlich, da laut spec die Eingänge des ESP8266 nicht 5V tolerant sind
http://bbs.espressif.com/viewtopic.php?t=1076

Wahrscheinlich wird es in den meisten Fällen auch ohne Levelshifter funktionieren.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 16 April 2017, 00:02:05
Ok,

ich habe 470ohm und 1 kOhm drin. Das sollte eigentlich genauso gehen.
Trotzdem initialisiert sich der Wemos beim starten mit Tx und Rx dran nicht.
Ohne schon.
Sobald ich das Teil mal wieder ausmache experimentier ich mal mit den Level Shiftern, bzw versuche es auch mal ohne.
Einfach um zu sehen ob sich dann daran was ändert...

Gruß und Danke,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 16 April 2017, 16:52:59
Ok,habe nun auch ohne Spannungsteiler versucht selbes Ergebnis.

Hab nun aber etwas rumgespielt.
Es liegt an der RX0 vom Nano <-> D8 am Wemos.
Ist der beim Strom drauf geben angeschlossen startet der Wemos nicht. Ist er nicht dran gehts.

Warum denn der Rx? Jemand noch eine Idee?

Verkabelung ist nun:
Nano        Wemos
+5V <-> +5V
GND <-> GND
RST <->  D3
Rx0 <->  D8
Tx1 <-> D7

Dabei spielt es keine rolle ob ich den Strom über den Wemos oder den Nano anschließe.

Was ist eigentlich die richtige Einstellung im Wemos?
RX Pull up an oder aus? Hab hier beides gesehen...
Und der Reset GPIO0? oder disabled?
Ist GPIO0 = D3?


Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 16 April 2017, 17:17:02
Hast Du es auch mal ohne die Reset Verkabelung versucht?
Alles auf disabled und Uartpin swapped.
Der RX Pull ist wahrscheinlich egal.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 16 April 2017, 17:20:19
Hi Ralf,

ja ohne RST hatte ich es am Anfang auch, das Verhalten war das selbe.
Das seltsame ist ja wenn ich den RX nach der Initializierung des Wemos anschließe tut alles super.

Muss ich mich wohl mit abfinden dass ich beim Anmachen den RX abziehen muss. So oft macht man das ja nicht.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 16 April 2017, 18:53:39
dies ist nicht normal, wenn hier niemand eine Idee hat, dann kannst Du evtl auch mal bei ESP8266 nachfragen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 16 April 2017, 19:17:20
Ok, muss ich dann bei Wemos nachfragen?
Habe mir noch 2 Bestellt für Füllstandsmessung.
Die kann ich ja auch mal probieren wenn sie da sind. Vielleicht hat der einfach einen hau weg...

Hätte da noch ne Frage. Bei deinem Bild geht TX auf D7 und RX auf D8.
Bei anderen habe ich gesehen RX vom Nano an TX vom ESP und TX vom Nano an RX vom ESP.
Geht das auch beim Wemos?
Könnte ich auch RX und TX am ESP probieren anstatt D7 und D8.
Hab ich nicht wirklich verstanden warum das auf den einen Schaltplänen mit den D's gemacht ist und bei den anderen mit RX / TX.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 16 April 2017, 20:07:04
Du kannst im Unterboard ESP8266 nachfragen.
Uartpin swapped bedeuted TX auf D7 und RX auf D8
Wenn Du Uartpin änderst, müsste auch RX und TX am ESP funktionieren.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 17 April 2017, 01:11:47
Ok vielen Dank.
Das kann ich dann alles noch ausprobieren wenn ich ihn wieder mal ins Haus hole :-)

Vielen Dank für die viele Hilfe hier!

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 19 April 2017, 01:18:34
Zitat von: stefanru am 16 April 2017, 16:52:59
Es liegt an der RX0 vom Nano <-> D8 am Wemos.
Ist der beim Strom drauf geben angeschlossen startet der Wemos nicht. Ist er nicht dran gehts.

Ich habe es bei mir nochmals versucht. Wenn ich den Strom wegnehme dauert es einige Minuten bis es der Signalduino merkt.
Wenn ich den Strom wieder anschließe kann es ein paar Minuten dauern bis der sduino wieder connected

2017.04.19 00:55:17.077 3 : sduino/KeepAlive not ok, retry = 2 -> get ping
2017.04.19 00:56:17.080 3 : sduino/KeepAlive not ok, retry = 3 -> get ping
2017.04.19 00:57:17.086 3 : sduino/keepalive not ok, retry count reached. Reset
2017.04.19 00:57:17.086 3 : sduino reset
2017.04.19 00:57:17.087 3 : Opening sduino device 192.168.xxx
2017.04.19 00:57:20.091 3 : Can't connect to 192.168.xxx: Datei oder Verzeichnis nicht gefunden
2017.04.19 00:57:20.091 3 : Can't connect to 192.168.xxx: connect to http://192.168.xxx timed out
2017.04.19 00:57:20.091 3 : SIGNALduino sduino: connect to http://192.168.xxx timed out
2017.04.19 00:58:20.041 1 : sduino/define: 192.168.0.xxx
2017.04.19 00:58:20.042 1 : sduino/init: 192.168.xxx
2017.04.19 00:58:20.042 1 : 192.168.0.xxx reappeared (sduino)
2017-04-19 00:58:20.045 SIGNALduino sduino CONNECTED
2017.04.19 00:58:21.544 3 : sduino/init: disable receiver (XQ)
2017.04.19 00:58:22.043 3 : sduino/init: get version, retry = 0
2017-04-19 00:58:22.060 SIGNALduino sduino opened
2017.04.19 00:58:22.060 2 : sduino: initialized. v3.3.1-dev
2017.04.19 00:58:22.070 3 : sduino/init: enable receiver (XE)


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 19 April 2017, 15:46:36
Danke Ralf,

ich kann gerne nochmal versuchen einfach 5 minuten zu warten.
Ich habe immer versucht direkt auf die IP des WEMOS zu kommen, bzw. in der Fritzbox zu schauen ob sich der WEMOS schon am WLAN angemeldet hat.

Mit angeschlossener Leitung gab es keine Anmeldung im WLAN und natürlich keine Antwort vom WEMOS Webinterface.

Ohne Leitung sofort nach einstöpseln.

Hatte jetzt noch die Idee dass es eventuell am arduino nano liegt.
Ich habe so ein nachbau, da gabs doch probleme wenn man den Raspberry durchstartet dass der nanao auch nicht richtig initialisiert wurde.
Ich hatte damit eigentlich nie graß Probleme, wenn eiener mal nicht tat hab ich eben USB ab und wieder angeschlossen, aber eventuell hat das auch eine auswirkung auf den WEMOS?

Trotzdem vielen Dank nochmal.
Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 19 April 2017, 19:15:35
Hi,
ja die Verbindung des Reset Pin am FT232 Chip auf Ground (direkt daneben) fehlt häufig.
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 April 2017, 22:55:57
ZitatEs liegt an der RX0 vom Nano <-> D8 am Wemos.
Ist der beim Strom drauf geben angeschlossen startet der Wemos nicht. Ist er nicht dran gehts.

Zitatich kann gerne nochmal versuchen einfach 5 minuten zu warten.

Mit angeschlossener Leitung gab es keine Anmeldung im WLAN und natürlich keine Antwort vom WEMOS Webinterface.

Ohne Leitung sofort nach einstöpseln.

Wenn er sich nicht am WLAN anmeldet und der Ping nicht funktionert, macht es auch keinen Sinn 5 Minuten zu warten.
Hast Du D3 (GPIO 0) nicht angeschlossen? Du kannst mal testweise an D3 einen 10K Widerstand nach 3,3V anschließen.
Wenn der D3 beim Starten auf 0 geht, dann geht der ESP8266 in den flash Modus.
Den Effekt, daß sich der Wemos nicht am WLAN anmeldet, wenn "RX0 vom Nano <-> D8 am Wemos" verbunden hatte ich noch nie.

@hjgode
liest Du hiert mit? oder hat jemand anders eine Idee?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 20 April 2017, 23:59:21
Hi Ralf,

danke für deine Hilfe.
Zur Zeit habe ich D3 an RST vom Nano.
Hatte ihn aber auch gar nicht angeschlossen.
Das hatte nix geändert.

Ok mit 10k an 3,3V versuche ich mal.

Ich werde berichten.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 23 April 2017, 15:16:16
Hi Ralf,

habe ich nun auch probiert. an 3,3V -> 10k -> D3.
Leider brachte das auch nichts. Nach wie vor geht es nur wenn ich din D8 bzw RX0 ablasse beim einschalten.

Bin für jede weitere Idee dankbar.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: luftdieb am 24 April 2017, 23:09:40
Hallo,
ich möchte den Signalduino zum Empfang meiner Wetterstation WH1080 einsetzen. Diese Station arbeitet mit 868 Mhz, weshalb ich das ELV Empfangsmodul RX868SH ( https://www.elv.de/elv-empfangsmodul-rx868sh-dv.html  (https://www.elv.de/elv-empfangsmodul-rx868sh-dv.html)) eingesetzt habe.
Als Basis dient ein Arduino Nano, welcher sich auch per eindeutiger FDDI ID ansprechen und flashen lässt. Jedoch funktioniert der Signalduino nicht so, wie ich es erwartet hätte...
Verschaltet wurden die Komponenten, wie es hier beschrieben wurde: https://wiki.fhem.de/wiki/FHEMduino. Die EN pins habe ich dauerhaft auf 5V gelegt.
Kompiliert bzw geflasht wurde die Version V 3.3.1-dev SIGNALduino.
Der state wechselt zu "opened". Jedoch empfange ich keine Daten, bzw. kann ich kein Register auslesen.
Als Hardware habe ich im fhem ein "nano328" konfiguriert... Hier bin ich mir unsicher, ob dass beim Empfangsmodul RX868SH so seine Richtigkeit hat...

Vielleicht hat jemand auch diese Wetterstation im Einsatz und empfängt schon Wetterdaten mit seinem SignalDuino und kann mir ein paar Tips geben.

Gruß
luftdieb


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 25 April 2017, 07:30:43
@luftdieb

Schau mal hier https://forum.fhem.de/index.php/topic,39451.msg363597.html#msg363597 in die anlage oder auch hier
https://forum.fhem.de/index.php/topic,58396.msg521044.html#msg521044

Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: luftdieb am 25 April 2017, 20:29:09
@Pejonp
Danke für die beiden Links. Die Verdrahtung habe ich exakt wie referenziert ausgeführt.
Im Logbuch erscheint
2017.04.25 20:14:56.113 4 : sduino/KeepAliveOk: 0
2017.04.25 20:14:56.115 3 : sduino/KeepAliveOk: 0 retry = 1 -> get ping
2017.04.25 20:14:56.117 4 : sduino/keepalive retry = 1
2017.04.25 20:14:56.220 5 : sduino SW: P
2017.04.25 20:14:56.234 4 : sduino/msg READ: OK
2017.04.25 20:14:56.235 5 : sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2017.04.25 20:14:56.534 4 : sduino/HandleWriteQueue: nothing to send, stopping timer

Im Batteriefach des Senders ist ein Aufkleber PASS A14C. Demnach sollte diese Wetterstation mit dem Empfänger RX868SH-DV kompatibel sein. Aber soweit bin ich ja noch nicht.

Das Device im fhem habe ich wie folgt angelegt:
defmod sduino SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700RF8S-if00-port0@57600
attr sduino flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino hardware nano328
attr sduino verbose 5

als config wird mir folgendes angezeigt:
setstate sduino opened
setstate sduino 2017-02-16 20:48:12 config MS=0;;MU=0;;MC=0
setstate sduino 2017-04-25 20:22:56 ping OK
setstate sduino 2017-04-25 20:11:56 state opened
setstate sduino 2017-02-16 20:48:03 uptime 0 00:03:49
setstate sduino 2017-04-25 20:11:56 version V 3.3.1-dev SIGNALduino - compiled at Jan  3 2017 23:59:32

Wie kann ich die Funktion verifizieren? Einen 433Mhz Steckdosen Sender habe ich... Aber diesen werde ich mit dem 868Mhz Modul nicht empfangen können, oder? Im fhem Eventviewer erscheint kein Eintrag von irgend welchen Funksignalen, wie ich es erwartet hätte.

Ich habe auch noch mal geflasht: flashing Arduino sduino
hex file: ./FHEM/firmware/SIGNALduino_nano328.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700RF8S-if00-port0
log file: ./log/SIGNALduino-Flash.log
sduino closed
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700RF8S-if00-port0 -p atmega328p -vv -U flash:w:./FHEM/firmware/SIGNALduino_nano328.hex 2>./log/SIGNALduino-Flash.log

--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700RF8S-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/SIGNALduino_nano328.hex"
avrdude: input file ./FHEM/firmware/SIGNALduino_nano328.hex auto detected as Intel Hex
avrdude: writing flash (17500 bytes):

Writing | ################################################## | 100% 4.89s

avrdude: 17500 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/SIGNALduino_nano328.hex:
avrdude: load data flash data from input file ./FHEM/firmware/SIGNALduino_nano328.hex:
avrdude: input file ./FHEM/firmware/SIGNALduino_nano328.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/SIGNALduino_nano328.hex contains 17500 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.57s

avrdude: verifying ...
avrdude: 17500 bytes of flash verified

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino opened


Aber wie schon gestern geschrieben, bin ich mir nicht sicher, ob die gewählte Hardware "nano328" zu meinem RX868SH-DV Empfänger passt. Und der uno oder promini hört sich auch nicht so passend an. In der fhem Modulbeschreibung vom SIGNALduino gibt es hierzu keine weitere Information. Auch google oder das Forum hat hierzu verständliche Informationen geliefert...

Edit: Ich habe eben noch mal eine USB Verlängerung angeschlossen, sowie eine ordentliche 868 Mhz Antenne angelötet und siehe da... es funktioniert ;-)

Vielen Dank trotzdem für die Unterstützung

Gruß
luftdieb
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 25 April 2017, 22:00:51
@luftdieb

falls noch Fragen zur WH1080 auftretten, einfach hier reinschreiben. https://forum.fhem.de/index.php/topic,39451.msg316447.html#msg316447.

Hier ist auch noch etwas https://forum.fhem.de/index.php/topic,67587.msg590469.html#msg590469.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 26 April 2017, 20:18:37
Zitat von: stefanru am 23 April 2017, 15:16:16
habe ich nun auch probiert. an 3,3V -> 10k -> D3.
Leider brachte das auch nichts. Nach wie vor geht es nur wenn ich din D8 bzw RX0 ablasse beim einschalten.

ich habe dafür ein neues Thema aufgemacht:
https://forum.fhem.de/index.php/topic,71059.0.html

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 10 Mai 2017, 16:31:58
Hallo Ralf,

da dass Senden von langen raw Befehlen ( 321 Bytes ) an meine FERNOTRON Rollladen mit den neuen Versionen nicht zuverlässig funktioniert,
den SIGNALduino geht nach einige Zeit einfach der Speicher aus ( freeram < 250), habe ich aufbauend auf deinen Quellcode eine Version für den ESP8266 erstellt.

Diese Version läuft jetzt schon einige Tage völlig Problemlos. Als Hardware kommt ein Wemos D1 Mini und ein RF1100SE Modul 433MHz zum Einsatz.
Das Senden von Befehlen an Intertechno-Steckdosen,  Brennstuhl  Steckdosen, Intertechno CMR-500 und Fernotron Rolladen klappt.
Der Empfang vom Handsender ITZ-500,  Brennstuhl RCS1000SN, sowie die von einen SIGNALduino gesendeten Befehle funktioniert auch.
Mehr Systeme habe ich leider nicht zum Testen. Ich hänge den Quellcode und eine kompilierte Bin-File zum Flashen an.

Ich habe am meinem Prod.  System einen SIGNALduino mit CC1101 (V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50)
und am Test System den Wemos D1 Mini mit RF1100SE (V 3.3.1-dev SIGNALduino cc1101 - compiled at May 7 2017 16:29:29) laufen,
in der Logfile auf beiden Systemen werden die gleichen Daten von unbekannten Geräten aus der Nachbarschaft gelogt.

Der Wemos ist wie folgt mit den RF1100se Modul verbunden.

  Wemos D1 Mini       RF1100se mit  cc1101 433MHz

     VDD                    --------       VDD    3.3V
     GPIO4  / D2        --------      GDO0
     GPIO5  / D1        --------      GDO2
     GPIO12 / D6       --------      MISO  --|  SPI Bus
     GPIO13 / D7       --------      MOSI  --|
     GPIO14 / D5       --------      SCLK  --|
     GPIO15 / D8       --------      CSn    --|
     GND                    --------      GND
     
     Led GPIO16 / D0

Zum Kompilieren alle Dateien in ein Verzeichnis kopieren, als Version habe ich die ARDUINO IDE 1.8.2 verwendet.
Zum Einrichten der WLan Verbindung kommt der ESP WifiManager zu einsatz, damit kann man die SID und sein Passwort einrichten.

Dieser muss installiert sein siehe Link:

   https://github.com/tzapu/WiFiManager

Beim erstmaligen Einrichten mit den WLAN Netz des ESP verbinden und die Oberfläche des Wifi Managers über 192.168.4.1 aufrufen.

Gruß
Klaus

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 10 Mai 2017, 19:53:13
Hi,
Warum geht das beim Signalduino mit dem nativen ESP? Beim CUL gab es doch Timingprobleme, die eine Portierung unmöglich machen, oder? Liegt dS daran, das FHEM die Entschlüsselung macht und nicht der Arduino/ESP selbst?
Finde ich jedenfalls Mega Cool! Danke werde testen!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 Mai 2017, 21:32:27
Hallo Klaus,

Sidey hat es auch schon mit einen ESP8266 Signalduino versucht, er hat es aber nicht stabil hinbekommen, der ESP hat sich recht häufig resetet.
https://github.com/RFD-FHEM/SIGNALESP/tree/master/SIGNALESP

Hast Du mal darauf geachtet ob sich bei Dir der ESP auch von selbst resetet? Dies ist u.a. an der uptime erkennbar

Das Problem dabei ist, daß ESP regelmäßig Zeit braucht, damit er sich u.a. ums WLAN kümmern kann. Wenn er nicht ausreichend Zeit bekommt, macht der Watchdog einen reset.

https://forum.fhem.de/index.php/topic,69042.msg622564.html#msg622564

Es kann sein, daß es einigermaßen funktioniert wenn er nicht so viele und kurze Nachrichten empfängt.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 11 Mai 2017, 08:33:53
Hallo Ralf,

ich habe zur Zeit eine Uptime von > 3 Tagen ohne Reset im laufenden System.
Das mit den Reseten liegt an der Interrupt Routine, die Routine muß wie folgt definiert werden :

void ICACHE_RAM_ATTR handleInterrupt()

wichtig ist das Attribute

ICACHE_RAM_ATTR 

ZitatWell, attachInterrupt is not in IRAM, so calling it from an interrupt handler is not safe.

Das Senden und Empfangen in meiner Umgebung funktioniert bis jetzt fehlerfrei.

Gruß
Klaus


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 11 Mai 2017, 15:31:54
Hallo. Ich habe den Signalduino mit 433MHz bei mir am laufen und steuere damit meine Somfy Rollläden, ein paar IT Steckdosen sowie eine Markise mit Dooya Motor. Die Somfy's und Dooya funktionieren einwandfrei.
Bei den IT Steckdosen habe ich ein Problem. Wenn ich diese einzeln schalte funktionieren diese Einwandfrei.

Wenn ich dagegen diese in einem DOIF verwende und diese nacheinander schalten möchte
DOELSE
(set ElroB off, set ElroD off, set KerzenlichtWohnzimmer off, set WifiLightKueche off 10)


wird "ElroD" zu 99% nicht ausgeschaltet.

Etwas besser wird es wenn ich zwischen den beiden Befehlen für die Elro's etwas anderes machen lasse. So zum Beispiel.

DOELSE
(set ElroB off, set KerzenlichtWohnzimmer off, set ElroD off, set WifiLightKueche off 10)


Die Definition des zweiten Elro's sieht so aus.
defmod ElroD IT 0FF0FFFF0F 0F F0
attr ElroD IODev sduinoCC1101
attr ElroD model itswitch
attr ElroD room 2.1_Licht

setstate ElroD off
setstate ElroD 2017-04-09 13:36:59 protocol V1
setstate ElroD 2017-05-11 06:31:37 state off


Der state steht auch auf off aber tatsächlich ist die Seckdose noch an. Da ich diese sofort einzeln schalten kann, schließe ich Sende/Empfangsprobleme aus.
Habe ich jetzt noch etwas in der Definition und/oder den Atributen vergessen oder übersehen? Oder an was kann es noch liegen?


Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 11 Mai 2017, 15:58:32
Hi,
Wenn man schreibt
A off, B off, C off
Wird alles parallel gemacht. Da müssen Pausen rein ;-)
Ausserdem sehe ich gar kein Repetition (3 oder 6) für ElroD. Das könnte aber auch helfen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 Mai 2017, 19:00:32
Beim Signalduino wird nicht parallel gesendet. Es gibt eine Sende Warteschlange

Ich habe zum Testen eine structure mit 3 ITv1 Steckdosen angelegt.

In der dev-r33 Version wird nach dem Senden gewartet bis vom sduino eine Antwort kommt, daß gesendet wurde.

2017-05-11 18:07:52.498 structure SchalterStruc off
2017.05.11 18:07:52.498 3 : sduino IT_set: IT_0F0000000F off
2017.05.11 18:07:52.501 5 : sduino/write: adding to queue sendMsg P3#is0F0000000FF0#R6
2017.05.11 18:07:52.501 3 : sduino IT_set: IT_0F000F000F off
2017.05.11 18:07:52.503 5 : sduino/write: adding to queue sendMsg P3#is0F000F000FF0#R6
2017.05.11 18:07:52.503 3 : sduino IT_set: IT_0F00F0000F off
2017.05.11 18:07:52.505 5 : sduino/write: adding to queue sendMsg P3#is0F00F0000FF0#R6

2017.05.11 18:07:52.612 4 : sduino SendFromQueue: msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404040404040404040404042304230404;
2017.05.11 18:07:52.839 4 : sduino/read sendraw answer: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404040404040404040404042304230404;

2017.05.11 18:07:52.849 4 : sduino SendFromQueue: msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404040423040404040404042304230404;
2017.05.11 18:07:53.101 4 : sduino/read sendraw answer: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404040423040404040404042304230404;

2017.05.11 18:07:53.111 4 : sduino SendFromQueue: msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404230404040404040404042304230404;
2017.05.11 18:07:53.363 4 : sduino/read sendraw answer: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01040404230404040404230404040404040404042304230404;


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 11 Mai 2017, 22:15:20
Das mit dem ICACHE_RAM_ATTR Parameter finde ich interessant.

Ich werde das ausprobieren. Wäre ja super, wenn der ESP dann läuft.

Was das Senden über die Warteschlange angeht, diese haben wir. Allerdings habe ich das schon öfters gelesen, dass es Probleme gibt. Irgendwas haben wir da vielleicht über sehen.

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 12 Mai 2017, 08:08:12
In einem anderen Post habe ich ja vermutet, dass die internen (im Signalduino eingestellten) 0,23s Wartezeit nicht reicht.


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 12 Mai 2017, 11:34:18
Alles klar. Danke für die Info. Da werde ich versuchen das anders zu lösen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 Mai 2017, 12:23:42
Zitat von: majorshark am 12 Mai 2017, 11:34:18
Alles klar. Danke für die Info. Da werde ich versuchen das anders zu lösen.
Mit der dev-r33 müsste es mit den IT Steckdosen eigentlich funktionieren
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Bei der dev-r33 Version gibt es keine feste Wartezeit. Mit dem Senden der nächsten Sendenachricht wird gewartet bis die vorherige Sendenachricht vollständig gesendet wurde (sduino/read sendraw answer: ..)

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 12 Mai 2017, 13:31:19
Ich habe das Update gemacht und das DOIF wieder geändert. Kann jetzt aber noch nicht nachsehen ob es funzt.
Die FW auf dem Stick ist wie vorher auch V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 Mai 2017, 18:54:09
ZitatWenn ich dagegen diese in einem DOIF verwende und diese nacheinander schalten möchte

DOELSE
(set ElroB off, set ElroD off, set KerzenlichtWohnzimmer off, set WifiLightKueche off 10)


wird "ElroD" zu 99% nicht ausgeschaltet.

Hat alles was Du mit 433MHz gemeinsam schaltest das gleiche IODev sduinoCC1101?

Mit unterschiedlichen IODevs funktioniert es nicht

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 13 Mai 2017, 18:43:48
Hallo Ralf,
Hallo Sidey,

ich hänge mal 2 neue Versionen zum Flashen für den Wemos D1 Mini und den Quellcode an.
Die Version SIGNALduino_C1101.bin  ist wie der Name es schon sagt  für das CC1101 Modul ,
die SIGNALEsp.bin  ist für 433Mhz Empfänger MX-FS und Sender FS1000A.
(Wemos Pin D3 / GPIO 0 Sendedaten, Pin D4 GPIO 2 Empfangsdaten)

Ich habe noch einige kleine Änderungen und Optimierungen für den ESP eingefügt. 
Ins besondere habe ich die Fifo Länge auf 255 erhöht, damit klappt bei mir der Empfang sehr gut.

Ich habe eine Uptime von über 5 Tagen ohne Neustarts oder Abstürze des ESP.
Gruß

Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: majorshark am 13 Mai 2017, 21:00:45
Zitat von: Ralf9 am 12 Mai 2017, 18:54:09
Hat alles was Du mit 433MHz gemeinsam schaltest das gleiche IODev sduinoCC1101?

Mit unterschiedlichen IODevs funktioniert es nicht

Gruß Ralf

Hat es . Geht alles über den SignalDuino 433MHz mit CC1101 raus.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Mai 2017, 23:18:40
Zitat von: trebron106 am 13 Mai 2017, 18:43:48
Ich habe noch einige kleine Änderungen und Optimierungen für den ESP eingefügt. 
Ins besondere habe ich die Fifo Länge auf 255 erhöht, damit klappt bei mir der Empfang sehr gut.

Hallo Klaus,
Danke für deinen Beitrag. Kannst Du die Änderungen in Form von Pull Requests in github beisteuern?
Da können wir uns die einzelnen Anpassungen dann separat ansehen, was jetzt so leider nicht möglich ist.

Den ICACHE_RAM_ATTR habe ich schon ausprobiert. Leider spinnt meine Maus rum, wenn ich den ESP anbinde. Das muss ich noch herausfinden, was dafür verantwortlich ist.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 14 Mai 2017, 10:06:31
Hallo Sidey,

da ich keinen GIT HUB Account habe, hänge mal die Diffs von meinen Änderungen an.
Ich hoffe so kannst du meine Änderungen nach vollziehen.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 15 Mai 2017, 22:27:37
Zitat von: trebron106 am 14 Mai 2017, 10:06:31
da ich keinen GIT HUB Account habe, hänge mal die Diffs von meinen Änderungen an.
Ich hoffe so kannst du meine Änderungen nach vollziehen.

Hallo Klaus,

Danke. Das macht es natürlich etwas leichter.
Nur das Diskutieren ist nicht so komfortabel.  :-\

Ich versuche mal eben zusammenzufassen was ich so beim ersten durchschauen erkannt habe:

cc1101.h

Hier hast Du die SPI Bibliothek eingebaut. Gibt es dafür einen besonderen Grund? Hat diese vorteile gegenüber der aktuellen Implementierung?

output.h

Ausgaben für den ESP angepasst. Ist soweit klar.

RF_Receiver.ino


SignalDecoder.cpp
Die RSSI Callback nur aufrufen, wenn ein CC1101 erkannt wurde.


Habe ich etwas übersehen?

Was mich am meisten Interessiert. Wieso hast Du die Anpassungen nicht vom SIGNALESP gemacht.
Was ich nun wo übernehme weiss ich noch nicht genau.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 16 Mai 2017, 11:21:21
Hallo Sidey,

deine Zusammenfassung stimmt soweit.

cc1101.h

Die SPI.H Lib. habe ich genommen, weil diese mit den ESP8266 funktioniert, die Aufrufe gut dokumentiert sind
und beim ESP8266 ja kein Speichermangel besteht.

Das EEPROM Handling habe ich an den ESP8266  angepasst.

RF_Receiver.ino

Den WiFiManager und die benötigten Lib's  für das WLan Handling eingefügt.
Die FiFO Länge habe ich auf 255 gesetzt.
Weil beim ESP die FiFo beim Empfang immer sehr schnell voll lief.

ZitatWas mich am meisten Interessiert. Wieso hast Du die Anpassungen nicht vom SIGNALESP gemacht.


Ich hatte ein C1101 Modul an einen Wemos D1 angeschlossen und dort mit
den Programm ESP8266-Arduino-C1101 zum Spaß getestet.

   https://github.com/kissste/ESP8266-Arduino-CC1101

Für das Schalten meiner Fernotron-Steuerungen über den SIGNALduino, werden lange Raw Sequenzen benötigt ( 330 Byte ).
Bei den neueren SIGNALduino Versionen funktioniert dies nach einiger Zeit nicht mehr, weil den Arduino-Nano der Speicher ausgeht.
Erst nach einem Hardware Reset funktioniert es wieder.

Ich habe mir den aktuellen SIGNALduino-C1101 Quellcode genommen und diesen entsprechend angepasst
und dabei Teile aus der ESP8266-Arduino-C1101 übernommen.


Gruß
Klaus


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 31 Mai 2017, 15:59:51
Kann man eigentlich auch einen Arduino Pro Mini 3,3V/8MHz verwenden? Und wenn ja auch in Kombination mit dem CC1101?
Wäre jedenfalls praktisch, weil man sich dann die Pegelanpassungen sparen könnte.

lg, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 31 Mai 2017, 16:26:25
@Sabine:
Ich habe das schon mal gemacht (nicht als SIGNALDUINO sondern als CUL). Wenn ich mich noch richtig erinnere muss man eine Leitung anlöten und beim Bootloader hatte ich anfangs auch Probleme.
Ich bin grad im Urlaub, ab Sonntag kann ich Dir noch die Details geben.

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 31 Mai 2017, 17:45:13
Zitat von: SabineT am 31 Mai 2017, 15:59:51
Kann man eigentlich auch einen Arduino Pro Mini 3,3V/8MHz verwenden? Und wenn ja auch in Kombination mit dem CC1101?
...
Hi Sabine,

schau mal ab hier (https://forum.fhem.de/index.php/topic,58396.msg572210.html#msg572210) ich glaube Sidey hat für den Pro Mini auch schon etwas vorbereitete.
bei attr kannst du doch schon einen promini328 auswählen.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 31 Mai 2017, 18:12:36
Zitat von: pejonp am 31 Mai 2017, 17:45:13
Hi Sabine,

schau mal ab hier (https://forum.fhem.de/index.php/topic,58396.msg572210.html#msg572210) ich glaube Sidey hat für den Pro Mini auch schon etwas vorbereitete.
bei attr kannst du doch schon einen promini328 auswählen.

pejonp
den Pro Mini gibt's ja als 5V/16MHz und 3.3V/8MHz, jetzt weis ich halt nicht, ob die Frequenz da einen Einfluss hat.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Mai 2017, 18:43:41
ZitatKann man eigentlich auch einen Arduino Pro Mini 3,3V/8MHz verwenden? Und wenn ja auch in Kombination mit dem CC1101?

Ja das funktioniert mit den Anpassungen und Optimierungen mit der aktuellen Version im Github recht gut.
Bei der 8MHz Variante hat sich anfänglich die etwas geringere Geschwindigkeit bei der Verarbeitung der empfangenden Signale bemerkbar gemacht.

Siehe:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 31 Mai 2017, 21:24:42
Danke!
Soweit war ich eh auf der richtigen Spur. Hab mal am Steckbrett ESP8266 + ProMini + CC1101 zusammengeschalten. Flashen lässt sich dann der ProMini übers WLAN (zumindest meldet das verify keinen Fehler), aber irgendwie tut sich danach nix. Werde dann morgen mal einen anderen ProMini probieren, muss da aber erst die Stiftleiste anlöten.

Hab aber zumindest schon mal ESP8266+nanoPro+CC1101 erfolgreich laufen.

lg, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 01 Juni 2017, 18:51:34
Zitataber irgendwie tut sich danach nix
Welche Firmware hast Du verwendet? Hast Du beachtet, daß die Firmware für den 16 MHz promini auf dem 8MHz promini nicht funktioniert?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 01 Juni 2017, 20:04:38
Zitat von: Ralf9 am 01 Juni 2017, 18:51:34
Welche Firmware hast Du verwendet? Hast Du beachtet, daß die Firmware für den 16 MHz promini auf dem 8MHz promini nicht funktioniert?

Gruß Ralf
naja, im Verzeichnis FHEM/firmware finde ich nur 1 Datei mit promini im Namen drinnen: SIGNALduino_promini328.hex
Für welche Frequenz die jetzt compiliert ist geht da nicht hervor.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 01 Juni 2017, 20:12:28
Du kannst diese Firmware auch auf einem 8Mhz pro Mini laufen lassen.

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 01 Juni 2017, 20:50:06
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 01 Juni 2017, 21:01:05
Danke! Jetzt schaut das gleich viel besser aus:
V 3.3.1k-dev SIGNALduino cc1101 - compiled at Apr  2 2017 16:37:30

lg, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 05 Juni 2017, 19:23:13
Zitat von: SabineT am 01 Juni 2017, 21:01:05
Danke! Jetzt schaut das gleich viel besser aus:
V 3.3.1k-dev SIGNALduino cc1101 - compiled at Apr  2 2017 16:37:30

Du kannst auch mal zum Vergleich die Version von Sidey testen:
https://forum.fhem.de/index.php/topic,58396.msg613030.html#msg613030

@Sidey sehe ich das richtig, daß in dieser Version die messagecompression und die Optimierungen bei der Verarbeitung der empfangenen Signale noch nicht enthalten sind?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Juni 2017, 23:48:46
Zitat von: Ralf9 am 05 Juni 2017, 19:23:13
@Sidey sehe ich das richtig, daß in dieser Version die messagecompression und die Optimierungen bei der Verarbeitung der empfangenen Signale noch nicht enthalten sind?
Das ist korrekt, diese Anpassungen habe es bislang noch nicht durch die Unit Tests geschafft. Daher gibt es noch keine compilierte Firmware damit.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 06 Juni 2017, 09:50:59
Hi,

ich hätte ne kurze Frage.
Wie ist denn der Stand mit Sduino nur am ESP?

Hier gab es doch neue Erkentnisse von Klaus wie es auch ohne Arduino stabil geht.
Gibt es schon eine Version zum Flashen auf den ESP?

Zur Zeit benutze ich ESP Link mit nano dran.
Ohne nano wäre natürlich noch cooler, würde das gern mal testen.

Wie wird dann eigentlich die Firmware geflasht braucht es dann kein ESP Link mehr?

Gruß und Danke,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 06 Juni 2017, 11:45:02
Würde das Teil auch zum testen dann bauen....

Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 06 Juni 2017, 14:11:23
Hallo,

hier ist meine aktuelle SIGNALEsp Version,

folgende  Erweiterungen habe ich noch zusätzlich eingebaut,

- ESP8266 Watchdog
- OTA Update
- Reboot per Command

Aufruf OTA Update über


 
http://SIGNALEsp-IP/update

danach Anmelden mit

Username   :  admin
Password    : SIGNALEsp




Aufruf Reboot von fhem


get sduino raw b



Bei mir läuft diese Version seit über 14 Tagen ohne Probleme.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 06 Juni 2017, 16:07:21
Hi,

vielen Dank Klaus.
Ich habe bisher nur ESP Link und ESP Easy auf meine ESP's gespielt.
Wie bokomme ich deine C++ Files da rein? Sorry ist sicher ne blöde frage, bin ich abe rbisher noch nicht drüber gestolpert.

Mich würde natürlich auch interessieren ob deine Version auch ins repository wandert so dass ich updates dann auch mitbekomme ohne hier immer nachlesen zu müssen :-)
Aber klar das dauert auch...

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 06 Juni 2017, 16:41:52
Zitat von: trebron106 am 06 Juni 2017, 14:11:23
Hallo,

hier ist meine aktuelle SIGNALEsp Version,

folgende  Erweiterungen habe ich noch zusätzlich eingebaut,

- ESP8266 Watchdog
- OTA Update
- Reboot per Command

Aufruf OTA Update über


 
http://SIGNALEsp-IP/update

danach Anmelden mit

Username   :  admin
Password    : SIGNALEsp




Aufruf Reboot von fhem


get sduino raw b



Bei mir läuft diese Version seit über 14 Tagen ohne Probleme.

Gruß
Klaus
Hast du auch nen Schaltplan, wie du den cc1101 angeschlossen hast?

Gesendet von meinem SM-T560 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 06 Juni 2017, 18:27:05
Hallo,

am Anfang in der SIGNALEsp.ino sind als Kommentar die benötigten
Verbindungen beschrieben.



/*
*   ESP8266            cc1101 Modul
*   Wemos D1 Mini
*   
*   VDD           -------- VDD    3.3V
*   GPIO4  / D2   -------- GDO0
*   GPIO5  / D1   -------- GDO2
*   GPIO12 / D6   -------- MISO  --|  SPI Bus
*   GPIO13 / D7   -------- MOSI  --|
*   GPIO14 / D5   -------- SCLK  --|
*   GPIO15 / D8   -------- CSn   --|
*   GND           -------- GND
*   



Es sind einfach Direktverbindungen, ein Pegelwandler ist nicht nötig.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 Juni 2017, 19:04:11
Zitat von: Sidey am 05 Juni 2017, 23:48:46
Zitat@Sidey sehe ich das richtig, daß in dieser Version die messagecompression und die Optimierungen bei der Verarbeitung der empfangenen Signale noch nicht enthalten sind?
Das ist korrekt, diese Anpassungen habe es bislang noch nicht durch die Unit Tests geschafft. Daher gibt es noch keine compilierte Firmware damit.

Ja, ich habe auch den Eindruck, daß es bei einigen Protokollen noch nicht ganz passt.

Bei den MS-Nachrichten hat sich die Erkennung und Dekodierung deutlich verbessert.

Bei den Hama und Bresser Sensoren mit dem Hideki protocol hatte ich den Eindruck, daß sich die Erkennung und Dekodierung verschlechtert hat.
Bei meiner WS3080 Wetterstation (ID 9) konnte ich keine großen unterschiede feststellen.
Die FS10 Steckdosen (ID 61) werden mit RXB6 und dev-r33 deutlich besser empfangen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 06 Juni 2017, 19:06:49
Hallo Stefan,

die CC Files muss du mit der Arduino IDE complieren. Die "bin File" kannst du direkt flashen.

Die angehängte  Datei runterladen und in ein Verzeichnis deiner Wahl entpacken.
Danach Wemos D1 oder ESP8266 per USB anschliessen.

flash.cmd ausführen
Com Port Nr.  eingeben und Return drücken

dann sollte der Flashvorgang starten.

Zum Neustarten den ESP vom USB Anschluss trennen.

Einreichten der IP siehe

https://forum.fhem.de/index.php/topic,58396.msg633415.html#msg633415 (https://forum.fhem.de/index.php/topic,58396.msg633415.html#msg633415)

Gruß
Klaus

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 06 Juni 2017, 20:39:20
Ok,
vielen Dank Klaus.
Hätte ich tatsächlich auch mitlesen können.
Habe ich wohl übersehen.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 07 Juni 2017, 10:51:04
Zitat von: Ralf9 am 05 Juni 2017, 19:23:13
Du kannst auch mal zum Vergleich die Version von Sidey testen:
https://forum.fhem.de/index.php/topic,58396.msg613030.html#msg613030

@Sidey sehe ich das richtig, daß in dieser Version die messagecompression und die Optimierungen bei der Verarbeitung der empfangenen Signale noch nicht enthalten sind?

Gruß Ralf
So, ich hab jetzt endlich den SignalDuino mit dem mini fertig gebaut (sh. Foto) und im FHEM zusätzlich definiert. Funktioniert mit beiden Firmware-Versionen (SIGNALduino_promini3v3.hex und SIGNALduino_promini328_3v3.hex), wobei ich derzeit nur die Wetterstation WH1080 damit angebunden habe, also nur Empfangen tu und nix senden.

Die Version vom Ralf ist zum Mitlesen auf der µC Console ungewohnt wegen der komprimierung ;)

Hier mal das, was die WH1080 bei den Internals anzeigt:
sduino868_DMSG P9#FF48048270080C04B40980
sduino868_MSGCNT 12
sduino868_RAWMSG MU;P0=-32001;P1=479;P2=-983;P3=1449;D=012121212121212123212323212323232323232323212323212323232323212323212121232323232323232321232323232323232121232323232323232123232123212123212323232323232123232121232323232323;CP=3;R=7;
sduino868_RSSI -70.5
sduino868_TIME 2017-06-07 10:35:28
sduinoIP868a_DMSG P9#FF48048270080C04B40980
sduinoIP868a_MSGCNT 6
sduinoIP868a_RAWMSG MU;P0=-4408;P1=480;P2=-974;P3=1458;D=01212121212121212321232321232323232323232321232321232323232321232321212123232323232323232123232323232323212123232323232323212323212321212321232323232323212323212123232323232;CP=3;R=243;
sduinoIP868a_RSSI -80.5
sduinoIP868a_TIME 2017-06-07 10:35:25
sduinoIP868b_DMSG P9#FF48048270080C04B40980
sduinoIP868b_MSGCNT 10
sduinoIP868b_RAWMSG MU;P0=-32001;P1=477;P2=-991;P3=1451;D=012121212121212123212323212323232323232323212323212323232323212323212121232323232323232321232323232323232121232323232323232123232123212123212323232323232123232121232323232323;CP=3;R=249;
sduinoIP868b_RSSI -77.5
sduinoIP868b_TIME 2017-06-07 10:35:25


sduino868 ist ein Radino über USB angeschlossen (provisorisch mit einer Flächenantenne dran)
sduinoIP868a ist der neue mit dem Arduino Mini über esp-link angeschlossen
sduinoIP868b ist einer mit Arduino Nano auch über esp-link

Der Neue ist im Moment noch nicht am endgültigen Installationsort, daher noch mit dem schwächsten Signal.

lg, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Juni 2017, 21:27:06
ZitatDie Version vom Ralf ist zum Mitlesen auf der µC Console ungewohnt wegen der komprimierung

Die Reduktion wird mit "CER" eingeschaltet und mit "CDR" ausgeschaltet.
Die zusätzlichen Debug Ausgaben kannst Du mit "CDD" ausschalten.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 08 Juni 2017, 06:22:46
Zitat von: Ralf9 am 07 Juni 2017, 21:27:06
Die Reduktion wird mit "CER" eingeschaltet und mit "CDR" ausgeschaltet.
Die zusätzlichen Debug Ausgaben kannst Du mit "CDD" ausschalten.

Gruß Ralf
Gut zu wissen. Debug hab ich jetzt mal ausgeschaltet. Reduktion lass ich aber an, die Daten kann ich so und so nicht dekodieren wenn ich da mit lese. Und das Modul versteht's ja ;)

lg, Sabine
Titel: SIGNALESP CC1101 Shield für Wemos D1 mini
Beitrag von: locutus am 11 Juni 2017, 14:14:35
Hallo zusammen,
ich habe für Wemos D1 mini ein CC1101 Shield entworfen. Primäres Einsatzgebiet ist der SIGNALESP (https://github.com/RFD-FHEM/SIGNALESP).

Die Platine muss mit folgenden Bauteilen bestückt werden:
1x CC1101 Funkmodul
1x LED SMD Bauform 1206
1x LED-Vorwiderstand SMD Bauform 1206
2x Stift- oder Buchsenleisten 8-pol. RM 2,54 mm
1x Helixantenne oder SMA-Buchse

Der LED-Vorwiderstand variiert je nach LED-Farbe und Lichtstärke (mcd) zwischen 470 Ohm und 1k.

Unbestückte Platinen sind im Marktplatz verfügbar.
Im Anhang Gerberdaten für ITEAD Studio (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-color-pcb-5cm-x-5cm-max.html).

Die Verwendung der Daten für kommerzielle Zwecke, gewerbliche Herstellung oder Vertrieb ist untersagt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MothersFinest am 11 Juni 2017, 20:38:31
Hallo Klaus,

ESP8266 und CC1101 verbunden, Sketch kompiliert und hochgeladen.
Serieller Monitor zeigt:

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 10.1.1.65
connected....
3.3.1-dev SIGNALEsp - compiled at Jun 11 2017 20:05:56
Using sFIFO  Size: 255
Reading values fom eeprom
CCInit
SRES Started
POR Done
Write Defaults done
EEPROM writePatable
CCVersion=20
CCPartnum=0
cc1101 found
Starting timerjob
HTTPUpdateServer ready!
10.1.1.65
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled


Danach ist die LED ohne Unterbrechung an, es kommen keinerlei weitere Daten und der Versuch Kommandos zu schicken bleibt ohne Reaktion.

Hast Du einen Tipp für mich?

Danke & Gruß
Oliver
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 12 Juni 2017, 18:12:42
Hallo,
bin zur Zeit im Urlaub und habe nur eine sehr schlechte Internetverbindung.
Ich melde mich in 2 Wochen.
Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 12 Juni 2017, 19:11:22
Hi,
hast Du das übliche schon probiert?
set dev raw e
set dev reset
get dev  ccconf
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 12 Juni 2017, 22:12:53
Hallo,

ich glaube ich bräuchte mal hilfe.

ich habe ein nanocul ( arduino + cc1101 ) auf dem bisher die culfw lief . auf diesem wollte ich nun signalduino einrichten. soweit alles gut, gerät wird erkannt und als opened angezeigt .

das problem ist, das ich bei dem attr hardware nicht die entsprechende option angezeigt bekommen ( nanoCC1101 ).
stehe jetzt so auf dem schlauch, das ich nicht im ansatz weiss wo ich das problem suchen soll ?

gruss Byte09
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 12 Juni 2017, 22:33:09
Hast Du die Version dev-r33 von github installiert?

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 13 Juni 2017, 05:23:32
hallo Sidey,

ja habe sie per update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt installiert incl fhem update und neustart.

gruss Byte09
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 13 Juni 2017, 06:20:55
Du musst auch die richtige Firmware flashen (SIGNALduino_nanoCC1101.hex) wenn du einen CC1101 verwendest.
Was bekommst du denn bei den Internals als version angezeigt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Juni 2017, 08:03:24
Er kommt ja nicht zum flashen, da das Hardware Attribut nicht angezeigt wird.

Vermutlich hast Du devr33 Version mit einem FHEM Update wieder überschrieben.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: BlackStone am 13 Juni 2017, 08:17:08
Das erste Flashen muss klassisch gemacht werden.
Oder den stick einfach als sduino per hand deklarieren, dann ist die Flash geschicht auch möglich.

Gesendet von meinem SM-G935F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 13 Juni 2017, 08:18:07
Ich hab bei mir das Attribut hexFile entsprechend gesetzt (die für meine 3.3V promini notwendige Firmware ist ja auch nicht im devr33 Tree ;)).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 13 Juni 2017, 08:40:16
Zitat von: Sidey am 13 Juni 2017, 08:03:24
Er kommt ja nicht zum flashen, da das Hardware Attribut nicht angezeigt wird.

Vermutlich hast Du devr33 Version mit einem FHEM Update wieder überschrieben.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk
Hmm , das ist wohl möglich , da ich immer ein fhem update danach gemacht habe . Werde heute abend danach schauen und mich dann nochmal melden .
Gruss byte09

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 13 Juni 2017, 17:33:12
Zitat von: Sidey am 13 Juni 2017, 08:03:24
Er kommt ja nicht zum flashen, da das Hardware Attribut nicht angezeigt wird.

Vermutlich hast Du devr33 Version mit einem FHEM Update wieder überschrieben.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk


..... genauso war es , danke für den hinweis. Jetzt passt es.

gruss Byte09
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MothersFinest am 14 Juni 2017, 19:23:43
Hi Arnd,

so weit in FHEM zu testen gehe ich gar nicht, ich bin direkt mit einem Terminal auf dem SignalESP und versuche mit ihm zu kommunizieren.
Die Meldungen beim Start kommen und er hängt sich auch ins WLAN, aber er reagiert auf keine Eingaben.

Wie wäre den die korrekte Definition in FHEM? Als "nanoCC101"?

Gruß
Oliver
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 14 Juni 2017, 21:00:02
Hi,
was macht ein
define sduinoESP SIGNALduino 10.1.1.65:23

Den richtigen Port weiss ich nicht!? Nehmt Ihr 23 bei den ESPSignalduinos?

Edit: Danke locutus! Meine Suche hat länger gedauert als Dein Post ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: locutus am 14 Juni 2017, 21:13:05
... steht doch im Sketch (https://github.com/RFD-FHEM/SIGNALESP/blob/master/SIGNALESP/SIGNALESP.ino), Zeile 104: WiFiServer Server(23); // port 23 = telnet

Die Definition lautet:
define <name> SIGNALduino <ip-adresse>:<port>
Bsp.:
define SIGNALESP SIGNALduino 192.168.4.1:23
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MothersFinest am 15 Juni 2017, 12:58:26
Danke - Ganz offensichtlich hatte ich das Konzept nicht verstanden.

Gruß
Oliver
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: matzefisi am 20 Juni 2017, 19:31:53
Hallo zusammen,

ich habe mal eine kurze, evtl. doofe Frage. Ich habe hier noch einen original CUL433 V3.4 liegen. Ist es möglich dort die Signalduino C1101 Firmware aus dem dev branch draufzuflashen oder sind dabei Probleme mit der PIN Belegung etc. zu erwarten? Ggf. hat das ja schon mal jemand versucht.

Vielen Dank schon mal.

MfG
Matthias
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 20 Juni 2017, 20:15:48
Nee, geht nicht! vielleicht sollten wir das mal bauen ;-)

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: matzefisi am 22 Juni 2017, 20:59:03
Hallo zusammen,

in einem Anflug von Wahnsinn habe ich es gerade einfach mal probiert und der Stick ist zumindest ansprechbar. Ich habe dafür das Image SIGNALDuino_radinoCC1101.hex verwendet. Der C1101 wird auch wohl erkannt, aber bei der Kommunikation gibt es wohl noch Probleme:

Reading values fom eeprom
CCVersion=15
CCPartnum=15
CC1101 found
Starting timerjob
cc1101 is not correctly set. Please do a factory reset via command e


Auch die LED funktioniert nicht, hängt also wohl auf dem falschen PIN.

Ich werde mal weiter testen.

MfG
Matthias
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FEHMPiDi am 23 Juni 2017, 09:33:00
Hallo,

ich glaube ich stell mich gerade zu doof an.
Ich wollte nach langer Zeit mal wieder meinen Signalguino auf den aktuellen Stand bringen.
Ich habe einen ArduinoMini mit einem standard 433Mhz Sender und Empfänger, also keinen C1101.
Wenn ich mir die aktuelle Version lade mit:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
und danach den flash Befehl starte, bekomme ich folgene fehlermeldung:
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/SIGNALduino_nano328.hex"
avrdude: error opening ./FHEM/firmware/SIGNALduino_nano328.hex: No such file or directory
avrdude: input file ./FHEM/firmware/SIGNALduino_nano328.hex auto detected as invalid format
avrdude: can't open input file ./FHEM/firmware/SIGNALduino_nano328.hex: No such file or directory
avrdude: read from file './FHEM/firmware/SIGNALduino_nano328.hex' failed


Die Datei kann also nicht gefunden werden.
Tatsächlich gibt es die Datei für den nano328 nicht.

Ich habe im Fhem/Firmware/ nur folgende Dateien (siehe Bild)

Kann mir jemand sagen was ich falsch mache?

Danke

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 23 Juni 2017, 10:12:28
Seltsam. Aber Du kannst Dir ja den ganzen Zweig von

https://github.com/RFD-FHEM/RFFHEM/tree/dev-r33

herunterladen und ins richtige Verzeichnis verschieben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Juni 2017, 10:42:18
Moin,

was hast Du denn für ein Hardware Attribut ausgewählt? Einen ArduinoMini kenne ich so nicht, die Firmware für den Nano wird da auch nicht die passende sein.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FEHMPiDi am 23 Juni 2017, 10:50:02
Sorry,

ich habe einen Arduino nano, nicht mini.
Internals:
   Clients    :IT:CUL_TCM97001:SIGNALduino_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09:SD_WS:RFXX10REC:Dooya:SOMFYSIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL011CM6-if00-port0@57600
   DMSG       P9#FE9A8A74C424343E1C2BB0
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL011CM6-if00-port0@57600
   FD         17
   Interval   300
   MSGCNT     5
   NAME       sduino
   NR         56
   PARTIAL
   RAWMSG     MU;P0=-160;P1=444;P2=-1096;P3=1405;P4=-32001;D=01212121212121232123232121232123212323232123212323212121232123232121232323212323232321232321232323232121232123232323212121212123232323212121232323232123212321212123212123214121212121212121212321232321212321232123232321232123232121212321232321212323232123;CP=1;O;
   STATE      opened
   TIME       1498207721
   TYPE       SIGNALduino
   unknownmessages
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     11:SD_WS09 ^P9#[A-Fa-f0-9]+
     12:SD_WS   ^W\d+#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^YsA[0-9A-F]+
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SIGNALduino_RSL ^r[A-Fa-f0-9]+
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[uP]\d+#.*
   QUEUE:
   Readings:
     2016-05-15 20:14:06   Version         V 3.2.0-b24 SIGNALduino - compiled at May 14 2016 00:06:40
     2017-06-23 10:46:13   cmds            ?UseoneofViRtXFSPCG
     2016-05-15 20:53:17   ping            OK
     2016-07-03 12:50:48   raw             is0F0F00FFFFF0
     2017-06-23 10:48:41   state           opened
     2017-06-23 10:47:31   version         V 3.2.0-b24 SIGNALduino - compiled at May 14 2016 00:06:40
   mcIdList:
     10
     11
     12
     18
     43
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     6
     7
   muIdList:
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     42
     5
     8
     9
Attributes:
   DbLogExclude .*
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nano328
   icon       cul_usb
   room       Server
   verbose    1


Ich werde das mal mit dem direkten Kopieren versuchen.

Danke


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 23 Juni 2017, 11:13:01
Kann es sein, dass es beim SignalDuino aktuell in FHEM nur ein "Close" gibt aber kein "Open" oder "Reopen" um sich erneut mit dem SignalESP zu verbinden?

Wie oft wird eigentlich das "Ping" ausgeführt? Würde gerne einen Watchdog dranhängen um die Verbindung zu überwachen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Juni 2017, 17:22:09
Zitatkann es sein, dass es beim SignalDuino aktuell in FHEM nur ein "Close" gibt aber kein "Open" oder "Reopen"
Es gibt ein reset was auch ein reopen macht.

ZitatWie oft wird eigentlich das "Ping" ausgeführt?
Nach 3 erfolglosen Ping wird ein reset durchgeführt
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 23 Juni 2017, 21:52:19
Was kann ich denn mit folgender Nachricht anfangen:

2017.06.23 17:04:26 2: SIGNALESP IT: IT_V3_5210040 (0000101001000010000000001000000) not defined (Address: 00001010010000100000000010 Group: 0 Unit: 0000 Switch code: 0)


Handelt es sich hierbei um eine Selbstlernende Funksteckdose die ich mit einem CUL schalten könnte?

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Juni 2017, 22:13:55
Ja, da ist etwas wie eine Funk Steckdose erkannt worden.

Das Gerät wird in Fhem angelegt, wenn zwei mal hinter einander das on signal erkannt wurde.

Schalten kannst Du diese dann auch über den SignalESP, sobald ich dort die Senderoutienen eingebaut habe.

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 29 Juni 2017, 18:22:24
Hallo, ich habe mich heute auch mal an dem SIGNALDuino versucht und bin nach der Anleitung im WIKI vorgegangen. Leider ist die Hardware nicht dazu zu bewegen ein connect zu liefern  :(
Habe mit
ls -l /dev/serial/by-id
die USB Schnittstelle ermittelt und dann mit:
define sduino SIGNALduino dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
das device definiert. Leider steht es permanent auf disconnected. Gibt es irgendein Kniff den ich übersehen habe?

Hier mal ein list vom device:
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   DMSG       nothing
   DevState   disconnected
   DeviceName dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   LASTDMSG   nothing
   NAME       sduino
   NR         2079
   PARTIAL
   STATE      disconnected
   TIME       1498752494.61316
   TYPE       SIGNALduino
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   Readings:
     2017-06-29 18:08:14   state           disconnected
     2017-06-29 18:02:58   version         0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     51
     55
     6
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       System


Gerade im Log gefunden:

2017.06.29 18:08:14 3: sduino: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 41 51 55 6 7
2017.06.29 18:08:14 3: sduino: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 34 36 37 39 40 44 44.1 45 46 48 49 5 50 56 59 60 61 62 63 64 65 66 8 9
2017.06.29 18:08:14 3: sduino: IDlist MC 10 11 12 18 43 47 52 57 58
2017.06.29 18:08:14 3: Opening sduino device dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0
2017.06.29 18:08:14 3: Can't open dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0: No such file or directory


Mmh?

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 29 Juni 2017, 18:29:46
Zitat von: franky08 am 29 Juni 2017, 18:22:24
define sduino SIGNALduino dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
da fehlt ein / vor dem "dev"
Richtig müsste es so heissen:
define sduino SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600

lg, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 29 Juni 2017, 18:47:53
Grrrrrr, man sollte eben doch C&P machen!

Danke!

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 29 Juni 2017, 22:24:04
So, der Sgnalduino läuft jetzt und steht auf connected, nun schnell mal das RX868SH RX Teil verbunden aber die Wetterstation wird nicht empfangen, ist eine WH1080 und die sollte doch über autocreate eigentlich angelegt werden. Merkwürdigerweise finde ich weder im Log noch im Event Monitor irgendwas über die Sensoren, dass RX Teil ist mit dem Datenausgang am Eingang dea Arduino D2 verbunden, sollte laut WIKI passen, oder?

VG
Frank

P.S. Habe schon eine usb Verlängerung drann und müsste die Sensoren eigentlich empfangen
P.S.2 der Arduino blinkt auch nicht mehr, hat er heute vor dem flashen noch gemacht

Internals:
   Clients    :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   FD         96
   NAME       sduino
   NR         2079
   PARTIAL
   STATE      opened
   TIME       1498758764.7006
   TYPE       SIGNALduino
   version    V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     11:SD_WS09 ^P9#[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^YsA[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[uP]\d+#.*
   QUEUE:
   Readings:
     2017-06-29 19:55:01   ITParms         ITParams: 6 300
     2017-06-29 20:17:17   config          MS=0;MU=0;MC=0
     2017-06-29 22:29:09   ping            OK
     2017-06-29 22:04:08   state           opened
     2017-06-29 22:04:08   version         V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
   Getcmd:
   Keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     45
     6
     7
   muIdList:
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     42
     44
     46
     48
     49
     5
     50
     51
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nano328
   room       System

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 30 Juni 2017, 06:51:17
Mach mal verbose 5 und zeige den log. Evtl hat er sie noch nicht gefunden. Frequenz stimmt? Entfernung nicht zu hoch?


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 30 Juni 2017, 07:15:24
Zitat von: franky08 am 29 Juni 2017, 22:24:04
P.S.2 der Arduino blinkt auch nicht mehr, hat er heute vor dem flashen noch gemacht
dass die LED nicht blinkt ist beim SIGNALDuino normal.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Juni 2017, 07:16:54
damit kann nichts empfangen werden
config          MS=0;MU=0;MC=0
mit "set sduino enableMessagetype ..." kannst Du die einzelnen Messagetypen enablen.

Damit bekommst Du die aktuellen Versionen der Module
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Wenn Du dann für die WH1080 die folgenden Attribute setzt
WS09_WSModel = WH1080
WS09_CRCAUS = 2
dann müsste es passen.


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 08:37:03
Hallo Ralf, danke für den Tipp. Habe jetzt die Attribute mal geändert, empfangen kann ich iMo leider nur eine Wetterstation vom Nachbarn:
2017-06-30 08:31:58 SIGNALduino sduino DMSG u63AA4AA8508A124501
2017-06-30 08:31:58 SIGNALduino sduino UNKNOWNCODE u63AA4AA8508A124501
2017-06-30 08:31:58 CUL_TX CUL_TX_115 T: 17.5 H: 60.0
2017-06-30 08:31:58 CUL_TX CUL_TX_115 temperature: 17.5
2017-06-30 08:31:58 SIGNALduino sduino DMSG u63AA4AA8508A124501
2017-06-30 08:31:58 SIGNALduino sduino UNKNOWNCODE u63AA4AA8508A124501
2017-06-30 08:31:59 SIGNALduino sduino DMSG u63AA48428A452AA4515
2017-06-30 08:31:59 SIGNALduino sduino UNKNOWNCODE u63AA48428A452AA4515
2017-06-30 08:31:59 CUL_TX CUL_TX_115 T: 17.5 H: 60.0
2017-06-30 08:31:59 CUL_TX CUL_TX_115 humidity: 59.0


Diese CUL_TX CUL_TX_115 ist definitiv etwas aus der Nachbarschaft, die WH1080 von mir ist leider nicht dabei.

Hier noch mal ein list:
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   DMSG       u638A2842D00
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   FD         96
   LASTDMSG   u638A2842D00
   MSGCNT     27
   NAME       sduino
   NR         2079
   PARTIAL
   RAWMSG     MU;P0=116;P1=-1005;P2=1262;P3=574;P4=-108;P5=172;P6=-724;D=01213131212131312121313131213131312134563121213131313131313;CP=3;
   STATE      opened
   TIME       1498804496.71564
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
   Doublemsgids:
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   Readings:
     2017-06-29 19:55:01   ITParms         ITParams: 6 300
     2017-06-29 22:46:21   cmds            V i R t X F S P C G
     2017-06-30 07:45:25   config          MS=1;MU=1;MC=1
     2017-06-30 08:00:48   ping            OK
     2017-06-30 08:25:22   state           opened
     2017-06-30 00:18:40   uptime          0 00:47:15
     2017-06-30 08:25:23   version         V 3.3.0 SIGNALduino - compiled at Sep 18 2016 00:28:28
   Keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     51
     55
     6
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     8
     9
Attributes:
   WS09_CRCAUS 2
   WS09_WSModel WH1080
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nano328
   room       Sduino,System


Habe nach dem update noch mal neu geflasht:
V 3.3.1-dev SIGNALduino - compiled at Jan 3 2017 23:59:32

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 30 Juni 2017, 08:58:40
Hi Frank,

bitte das hier beachten: https://forum.fhem.de/index.php/topic,39451.msg363597.html#msg363597 Die weiteren Links beziehen sich darauf.

SignalDuino: https://forum.fhem.de/index.php/topic,14786.msg615271.html#msg615271
JeeLink: https://forum.fhem.de/index.php/topic,14786.msg363766.html#msg363766

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 09:09:46
Habe mir gerade mal die verlinkten Beiträge angesehen, bei mir handelt es sich um eine "FreeTec Model: Wh1080" wie sie von PEARL vertrieben wird. Wenn ich dazu komme werde ich die Station mal öffnen um zu sehen was da für ein RX Modul verbaut ist.

VG
Frank

Sieht aus wie der: Bild 12: WX-2008 868MHz FSK Empfänger (wahrscheinlich RFM01)

Dann funktioniert das mit dem Signalduino und dem RX868SH-DV wohl nicht?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 30 Juni 2017, 09:39:26
Würde mal sagen der Empfänger ist ein rfm11 und empfängt FSK moduliert.
Kann zur Zeit nur ein jeelink. 
Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 09:52:23
Mmh, Schade, da bin ich wohl auf einige Beiträge hier im Forum "hereingefallen", wo beschrieben wird das die Sensoren der WH1080 mit einem Signalduino und einem RX868SH-DV empfangen werden können.

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 30 Juni 2017, 11:07:27
Ganz falsch, es wurde schon frühzeitig darauf hingewiesen das es verschiedene Varianten gibt.
Einmal mit OOK Modulation, diese kann der signalduino empfangen und einmal mit FSK Modulation diese kann der signalduino nicht empfangen, sondern der jeelink.

https://forum.fhem.de/index.php/topic,38831.msg358572.html#msg358572
https://forum.fhem.de/index.php/topic,39451.msg611774.html#msg611774



Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 11:48:53
Ja, habe ich auch gerade nachgelesen aber ich kann ja den alduino nano mit der JeeLink_LaCrosse.hex flashen und als RX Modul das RFM12B, 868MHz nehmen, dann müsste das doch funktionieren.

P.S. bin mit der WH1080 vom falschen Model ausgegangen

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 30 Juni 2017, 12:23:36
Hi Frank,

Dann nehm am besten den rfm69cw. Neu Version und wird besser unterstützt.
Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 16:51:50
Hallo, jetzt muss ich doch noch mal fragen. Versuche gerade den ARDUINO nano auf JeeLink_LaCrosse um zu flashen. Was vorher mit dem flash Aufruf als Signalduino vollkommen problemlos ging, macht jetzt Probleme. Das JeeLink device ist angelegt aber da ist natürlich noch die Signalduino Firmware drauf. Avrdude meldet dann einen Fehler:
flashing JeeLink jlink
detected Firmware: LaCrosse.hex
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0
log file: ./log/JeeLinkFlash.log
jlink closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log

--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

jlink opened


Der JeeLink ist so definiert:
Internals:
   CFGFN
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   FD         4
   NAME       jlink
   NR         9315
   PARTIAL
   STATE      opened
   TYPE       JeeLink
   Matchlist:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   Readings:
     2017-06-30 16:36:49   state           opened
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       Jeelink


Kann man das Teil nicht mit /dev/serial/by-id einbinden aber warum wird es dann angelegt?

VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 30 Juni 2017, 16:56:11
Hi, die CULs muss man ja per raw B01 in den Flash Bootöoader Modus bringen, wie kommt man beim Signalduino dahin? Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 16:59:25
Mit set .... raw B01, oder? Hab ich ja schon probiert  ;)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: franky08 am 30 Juni 2017, 17:16:20
Habe ihn als signalduino auf lacrosse umgeflasht, da geht avrdude  ;)
Internals:
   CFGFN
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
   FD         96
   NAME       jlink
   NR         2293
   PARTIAL
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
   Matchlist:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   Readings:
     2017-06-30 17:13:38   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]


VG
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 01 Juli 2017, 17:02:03
Ich habe heute einen SignalESP mit CC1101 mit 868MHz aufgebaut.
Gibt es irgendeine Möglichkeit den SignalESP zu testen ob er irgendwas empfängt.

Das List sieht so aus:

Internals:
   Clients    :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
   DEF        192.168.1.36:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.1.36:23
   FD         35
   NAME       SIGNALESP868
   NR         563
   PARTIAL
   STATE      opened
   TIME       1498917195.80216
   TYPE       SIGNALduino
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   Matchlist:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     11:SD_WS09 ^P9#[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^YsA[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[uP]\d+#.*
   QUEUE:
   Readings:
     2017-07-01 17:00:49   ping            OK
     2017-07-01 15:55:31   state           opened
     2017-07-01 15:55:47   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   Getcmd:
   Keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     45
     6
     7
   muIdList:
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     42
     44
     46
     48
     49
     5
     50
     51
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       SignalESP


Könnte ich mit einem NanoCUL etwas senden, was der SignalESP empfängt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 01 Juli 2017, 19:38:33
Hi,
Klar lege ein IT Device an und stell den SignalESP auf 433.92 MHZ und verbose 5.

define IT_TEST IT 00F0000F00 0F F0
attr IT_TEST ioDev NanoCUL
attr SIGNALESP868 verbose 5
set SIGNALESP868 cc1101_freq 433.92
set IT_TEST on

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 01 Juli 2017, 19:49:21
Ich glaube den Set-Befehlt gibt es in der SignalESP Firmware nicht:

Unknown argument cc1101_freq, choose one of ITClock close disableMessagetype enableMessagetype flash raw reset sendMsg

Scheinbar kommt aber trotzdem etwas an:

017.07.01 19:59:38 4: SIGNALESP868/msg READ: MS;P1=1257;P2=-417;P3=415;P4=-1296;P5=-10052;D=35341234123412341234123412341234123412341234123412;CP=3;SP=5;R=35;O;
2017.07.01 19:59:38 4: SIGNALESP868: Matched MS Protocol id 45 -> revolt
2017.07.01 19:59:38 5: SIGNALESP868: Starting demodulation at Position 2
2017.07.01 19:59:38 4: SIGNALESP868: Decoded MS Protocol id 45 dmsg i555555 length 24
2017.07.01 19:59:38 5: SIGNALESP868: converted Data to (i555555)
2017.07.01 19:59:38 5: SIGNALESP868: dispatch i555555
2017.07.01 19:59:38 4: SIGNALESP868 IT: message "i555555" (7)
2017.07.01 19:59:38 4: SIGNALESP868 IT: msgcode "FFFFFFFFFFFF" (12) bin = 010101010101010101010101
2017.07.01 19:59:38 5: SIGNALESP868 IT: V1 housecode = FFFFFFFFFF  onoffcode = FF


Sieht nach einer IT Message. Scheinbar funktioniert es auch ohne Umschalten der Frequenz.
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 01 Juli 2017, 22:44:43
Hi,
also bei mir schon ;-)
Aber das erscheint erst, wenn man

attr SIGNALESP868 hardware nanoCC1101
attr SIGNALESP868 cc1101_frequency 868

setzt.

Und dann schau mal auf was der aktuell steht:
get SIGNALESP868 ccconf

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...[/code]
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 02 Juli 2017, 07:38:41
Okay scheinbar hatte ich noch nicht ein Update gemacht:

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

Jetzt klappt auch das setzen der Frequenz über set cc1101_freq 868.3

Allerdings werden die Daten durchs nächste Update wieder überschrieben. Gibt es hierfür eine "Lösung" oder einen Link wo geschrieben steht wie alles eingebunden werden muss?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 02 Juli 2017, 09:13:09
Ja, siehe wiki Signalduino

Mach mal die update zeile mit add statt mit all ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 02 Juli 2017, 11:32:28
Bisschen blöd ist es trotzdem. Jetzt gibt es immer den Kampf zwischen dem FHEM SVN und dem von Signalduino:

fhem
List of new / modified files since last update:
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/14_SD_WS.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/14_SD_WS09.pm
UPD FHEM/14_SD_WS_Maverick.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/90_SIGNALduino_un.pm
UPD FHEM/98_Dooya.pm
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_uno.hex

fhemtabletui
nothing to do...

signalduino
nothing to do...


Ich möchte aber auch ungern die ganzen Dateien auf die Ignore-Liste setzen. Wie ist es denn wirklich gedacht?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 02 Juli 2017, 14:19:20
Kennt ihr nicht das global attr "exclude_from_update"?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 Juli 2017, 14:21:45
Wenn Du es mit Update add einfügst, dann wird auch immern die Entwicklungsversion mit aktualisiert.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 02 Juli 2017, 22:33:41
Also meine Update Liste sieht jetzt so aus:

http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt


Update check sieht so aus vor einem Update:

fhem
List of new / modified files since last update:
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/14_SD_WS.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/14_SD_WS09.pm
UPD FHEM/14_SD_WS_Maverick.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/90_SIGNALduino_un.pm
UPD FHEM/98_Dooya.pm
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_uno.hex

fhemtabletui
nothing to do...

signalduino
nothing to do...


Ein Log des Updates sieht so aus:

2017.07.02 22:30:02 1 :
2017.07.02 22:30:02 1 : fhem
2017.07.02 22:30:02 1 : UPD FHEM/00_SIGNALduino.pm
2017.07.02 22:30:02 1 : UPD FHEM/14_Hideki.pm
2017.07.02 22:30:02 1 : UPD FHEM/14_SD_WS.pm
2017.07.02 22:30:02 1 : UPD FHEM/14_SD_WS07.pm
2017.07.02 22:30:02 1 : UPD FHEM/14_SD_WS09.pm
2017.07.02 22:30:02 1 : UPD FHEM/14_SD_WS_Maverick.pm
2017.07.02 22:30:02 1 : UPD FHEM/41_OREGON.pm
2017.07.02 22:30:02 1 : UPD FHEM/90_SIGNALduino_un.pm
2017.07.02 22:30:02 1 : UPD FHEM/98_Dooya.pm
2017.07.02 22:30:02 1 : UPD FHEM/firmware/SIGNALduino_nano328.hex
2017.07.02 22:30:02 1 : UPD FHEM/firmware/SIGNALduino_promini328.hex
2017.07.02 22:30:02 1 : UPD FHEM/firmware/SIGNALduino_uno.hex
2017.07.02 22:30:02 1 : saving fhem.cfg
2017.07.02 22:30:02 1 : saving ./log/fhem.save
2017.07.02 22:30:03 1 :
2017.07.02 22:30:03 1 :
2017.07.02 22:30:03 1 : fhemtabletui
2017.07.02 22:30:03 1 : nothing to do...
2017.07.02 22:30:03 1 :
2017.07.02 22:30:03 1 :
2017.07.02 22:30:03 1 : signalduino
2017.07.02 22:30:03 1 : UPD ./FHEM/14_Hideki.pm
2017.07.02 22:30:03 1 : UPD ./FHEM/00_SIGNALduino.pm
2017.07.02 22:30:03 1 : UPD ./FHEM/14_SD_WS09.pm
2017.07.02 22:30:03 1 : UPD ./FHEM/90_SIGNALduino_un.pm
2017.07.02 22:30:03 1 : UPD ./FHEM/98_Dooya.pm
2017.07.02 22:30:04 1 : UPD ./FHEM/14_SD_WS_Maverick.pm
2017.07.02 22:30:04 1 : UPD ./FHEM/14_SD_WS07.pm
2017.07.02 22:30:04 1 : UPD ./FHEM/41_OREGON.pm
2017.07.02 22:30:04 1 : UPD ./FHEM/firmware/SIGNALduino_nano328.hex
2017.07.02 22:30:04 1 : UPD ./FHEM/firmware/SIGNALduino_promini328.hex
2017.07.02 22:30:04 1 : UPD ./FHEM/firmware/SIGNALduino_uno.hex
2017.07.02 22:30:04 1 : UPD ./FHEM/firmware/SIGNALduino_nanoCC1101.hex
2017.07.02 22:30:05 1 : UPD ./FHEM/firmware/SIGNALDuino_radinoCC1101.hex
2017.07.02 22:30:05 1 : UPD ./FHEM/14_SD_WS.pm
2017.07.02 22:30:05 1 : saving fhem.cfg
2017.07.02 22:30:05 1 : saving ./log/fhem.save
2017.07.02 22:30:05 1 :
2017.07.02 22:30:05 1 : New entries in the CHANGED file:
2017.07.02 22:30:05 1 : 05.12.2016
2017.07.02 22:30:05 1 : Bugfix weong return in SIGNALduino_un ParseFn
2017.07.02 22:30:05 1 : 09.10.2016
2017.07.02 22:30:05 1 : improve Send queue: Send not before response of previous
2017.07.02 22:30:05 1 : 30.09.2016
2017.07.02 22:30:05 1 : SIGNALduino is now nonblocking
2017.07.02 22:30:05 1 : improved init and keepalive
2017.07.02 22:30:05 1 : some fixes providing more messages instad of fewer.
2017.07.02 22:30:05 1 : fixed some manchester realted things
2017.07.02 22:30:05 1 : added protocol 43 Somfy RTS
2017.07.02 22:30:05 1 : increased number of pattern from 6 to 8 to support dooya shutter protocol better
2017.07.02 22:30:05 1 : Rised the allowd numbers in protocol check
2017.07.02 22:30:05 1 : fixed a possible bug, that append a 0 nibble in mc message
2017.07.02 22:30:05 1 : added a new information field in mc messages, providing exact number of
2017.07.02 22:30:05 1 : provided bits
2017.07.02 22:30:05 1 : fixed incomplete mc output (last nibble was not delivered)
2017.07.02 22:30:05 1 : decoding mc signals > message buffer is now possible
2017.07.02 22:30:05 1 : max 340 bits are currently suppored
2017.07.02 22:30:05 1 : small improvement in processMessage (if MS decoding fails,
2017.07.02 22:30:05 1 : mc or mu decoding is called)
2017.07.02 22:30:05 1 : corrected readings for firmware version.
2017.07.02 22:30:05 1 : new sendMsg Function
2017.07.02 22:30:05 1 : 14_SD_WS09.pm WH1080 CRC-Berechung angepaßt--> automatische Modelauswahl
2017.07.02 22:30:05 1 : 15.01.2016
2017.07.02 22:30:05 1 : - Added 14_SD_WS09.pm Module for WH1080 (WS-0101, TFA30.3189) & CTW600 868MHz OOK/AS
2017.07.02 22:30:05 1 : 08.11.2015
2017.07.02 22:30:05 1 : ... rest of lines skipped.
2017.07.02 22:30:05 1 : Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while


Nach dem Update sieht es wieder so aus:

fhem
List of new / modified files since last update:
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/14_SD_WS.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/14_SD_WS09.pm
UPD FHEM/14_SD_WS_Maverick.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/90_SIGNALduino_un.pm
UPD FHEM/98_Dooya.pm
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_uno.hex

fhemtabletui
nothing to do...

signalduino
nothing to do...


Kann doch nicht Sinn der Sache sein, dass mir das Update Check jetzt immer Updates anzeigt die erst aus dem Haupt-SVN geladen werden und anschließend vom Signalduino SNV direkt wieder überschrieben werden.

Gibt es einen Grund die Daten nicht ins FHEM-SVN einzuchecken?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 Juli 2017, 08:40:42
Niemand mit dem gleichen Problem?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Juli 2017, 08:46:55
Über das FHEM Update kommen die "finalen" Versionen. Das ist die aktuelle stabile Version.

Über das git kommt eine in Entwicklung befindliche Version. Die muss nicht immer funktionieren und ist meist auch nicht ganz fehlerfrei.

Wenn die development Version fertig und stabil ist, kommt dieser Stand auch wieder ins SVN und ist damit über das Fhem Update verfügbar.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 Juli 2017, 09:14:52
Das heißt eigentlich brauch ich das Update aus dem Dev SNV garnicht?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Jarnsen am 18 Juli 2017, 01:18:59
Hallo,

Bin seit langem mal wieder hier. Und es hat sich viel getan. Welcher der vielen Versionen des SignalDuino /SignalESP ist jetzt die beste. Sendeleistung,Stabilität, Zuverlässigkeit usw.


Jarnsen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 18 Juli 2017, 13:25:20
Hi,
wenn der USB Port frei ist, die nanoCUL Hardware mit SMA Antennenanschluss ;-) der läuft stabil und man kann die Frequenzen und Antennen der eigenen Situation anpassen.

Wenn man den ESP8266 nutzen will, spart man sich den USB Port, hat aber evtl. noch einige Softwaretests in den nächsten Monaten ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 05 August 2017, 13:15:26
Hi,

kurze Frage zum SignalESP.
Wie würde man denn einen 433 Sender und Empfänger anschließen?
Also jeweils mit Power Ground und Data. Wo müssten die 2 Data Leitungen hin?
Ich meine nicht einen cc1101? Geht das auch? Finde dazu keine Info.

Vielen Dank,
Stefan


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 05 August 2017, 18:05:24
Hallo Stefan,

hier sind die benutzten Ein- und Ausgänge



*   
*   VDD           -------- VDD    3.3V
*   GPIO4  / D2   -------- GDO0   = Senden (433Mhz Sender)
*   GPIO5  / D1   -------- GDO2   = Empfangen (433Mhz Empfänger)
*   GPIO12 / D6   -------- MISO  --|  SPI Bus für C1101
*   GPIO13 / D7   -------- MOSI  --|
*   GPIO14 / D5   -------- SCLK  --|
*   GPIO15 / D8   -------- CSn   --|
*   GND           -------- GND
*   
*   
*   Led GPIO16 / D0
*



Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 05 August 2017, 20:55:00
Ja für den cc1101, er fragte aber nach den normalen Sendern Empfängern.

Mir ist nicht bekannt, das der SignalESP ohne cc1101 schon gebaut wurde.

Die alte Signalduino Hardware hat ja auch keine Vorteile gegenüber dem cc1101, oder? Mal abgesehen von Preis oder das man die Bauteile halt hat ;-)

Oder will sich jemand outen?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 05 August 2017, 21:33:25
Hallo Arnd,

die alten 433MHz Empfänger und Sender werden an GPIOI4  Sender und  GPIO5 Empfänger angeschlossen.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 05 August 2017, 21:47:34
Hi Klaus, Uups! Ja Danke, überlesen <In der Ecke schämend>. Hat das wer im Einsatz? Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 07 August 2017, 16:46:28
Hallo,

ich habe einen SignalESP erstanden. Der soll in ein WIFI Netzwerk eingebunden werden, welches mit statischen IP Adressen arbeitet. Über das WEBIF kann ich aber keine IP angeben sondern nur die SSID und das Passwort. Ist geplant das zu erweitern oder kann man im Sketch irgendwo die IP fest eingeben, neu compilieren und flashen?

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 August 2017, 17:41:39
Hmm, das mit der festen IP war jetzt nicht geplant.

Wie würdest Du dir das inkl. Erstinbetriebnahme denn vorstellen?

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 07 August 2017, 18:42:47
Hallo,

ich würde das in den Teil ohne SSID scan reinpacken. Wenn ich das richtig gelesen habe, besteht die Möglichkeit einer festen IP seitens der Bibliothek schon. Man müste eben IP, GW und Mask übergeben und dann erst versuchen sich am WLAN anzumelden.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 08 August 2017, 16:47:05
Hallo Christoph,

als Anlage eine neue Version von SIGNALEsp,

folgende Änderungen sind enthalten:

- bei SIGNALEsp-CC1001 PIN D3 auf Gnd beim Booten AP Einstellungen werden zurück gesetzt und die Config Page gestartet
- bei SIGNALEsp-433MHz PIN D1 auf Gnd beim Booten AP Einstellungen werden zurück gesetzt und die Config Page gestartet

- wenn noch keine IP gesetzt wurde wird grundsätzlich DHCP gemacht
- nach den einmal eine IP vergeben wurde, kann diese auf der Config Page geändert werden
- somit kann eine statische IP eingestellt werden.

- Aufruf der Config Page durch siehe oben

Gruß
Klaus
 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 08 August 2017, 20:30:58
Würde es Sinn machen, für den Signal esp einen eigenen thread aufzumachen?

Gesendet von dem teuren ding in meiner hand

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 08 August 2017, 21:05:06
Zitat von: trebron106 am 08 August 2017, 16:47:05
Als Anlage eine neue Version von SIGNALEsp,

Hallo Trebron,

ich finde es gut, dass Du dich an der Entwicklung beteiligt. Ich fände es aber noch besser, wenn Du deine Änderungen bei github beisteuern würdest.
Was hältst Du davon?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 08 August 2017, 21:38:08
Vorab schon mal Sorry für den Crosspost (https://forum.fhem.de/index.php/topic,68234.0.html), weiß nicht ganz wo ich am besten aufgehoben bin!

Gibt es irgendwo Details, Artikellisten usw. für den SIGNALEsp-CC1001 damit ich weiß, wie ich mir einen zusammenbauen kann? Bin leider Laie, würde mich aber freuen Unterstützung zu bekommen :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 08 August 2017, 21:53:09
Hallo,

jetzt bitte mal für doofe. Ich habe die ZIP Datei heruntergelden und entpackt. Wie bekomme ich die jetzt auf den Wemos? Welche Datei muss ich nehmen?

Gruß Christoph

Edit: alles gut - hab es hinbekommen - klasse Umsetzung - Danke
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: locutus am 08 August 2017, 22:18:05
Zitat von: Bennemannc am 08 August 2017, 21:53:09
Ich habe die ZIP Datei heruntergelden und entpackt. Wie bekomme ich die jetzt auf den Wemos? Welche Datei muss ich nehmen?
Die bin-Datei wird mit esptool
esptool.py --port /dev/ttyUSB1 write_flash SIGNALEsp-CC1101.bin
oder mit NodeMCU Flasher (https://github.com/nodemcu/nodemcu-flasher) geflasht.

Zitat von: prodigy7 am 08 August 2017, 21:38:08
Gibt es irgendwo Details, Artikellisten usw. für den SIGNALEsp-CC1001 damit ich weiß, wie ich mir einen zusammenbauen kann? Bin leider Laie, würde mich aber freuen Unterstützung zu bekommen :)
https://forum.fhem.de/index.php/topic,58396.msg646685.html#msg646685
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 08 August 2017, 22:39:23
Danke, bin ich eben drüber gestolpert und habe schon meine Fußspuren in deinem Thread für das Shield hinterlassen :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 09 August 2017, 10:00:49
Danke Trebron106 und RaspiLED,

das hilft mir weiter.
Zur Zeit habe ich den ESP <=> arduino <=> 433 Sender und 433 Empfänger.
Ich werde den arduino da mal rausnehmen und es direkt mit SignalESP versuchen.
Ich berichte dann mal kurz ob das gut klappt. Kann aber noch etwas dauern.

Das Setup habe ich so gewählt weil der 433 Sender meine Somfy Lichtsteuerung schalten kann, solange ich ihn nah genug am Empfänger der Somfy anlage habe.
Mit dem cc1101 klappt das leider nicht.

Gruß,
Stefan
Titel: Antw:SIGNALESP CC1101 Shield für Wemos D1 mini
Beitrag von: gloob am 09 August 2017, 10:10:34
Zitat von: locutus am 11 Juni 2017, 14:14:35
Hallo zusammen,
ich habe für Wemos D1 mini ein CC1101 Shield entworfen. Primäres Einsatzgebiet ist der SIGNALEsp (https://github.com/RFD-FHEM/SIGNALESP).

Hallo,

Wärst du so nett und würdest die Gerber-Dateien bereit stellen, damit man die Platinen selber bestellen kann?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 09 August 2017, 10:18:30
Hallo Sidey,

ich werde mich in die github Doku einlesen, da ich damit noch nicht gearbeitet habe.
Habe als Rentner leider nicht soviel Zeit, da ich viel im Ausland unterwegs bin und dort einige
Projekte betreue und es gibt dort auch nicht überall einen Internetzugang bzw. Mobilfunk.

Werde mich dann noch einmal melden.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 09 August 2017, 16:23:17
ZitatHabe als Rentner leider nicht soviel Zeit,

Das hört man immer wieder... 8)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 09 August 2017, 18:00:52
Hallo,

gibt es irgendwo ein passendes Gehäuse ? Oder wie verpackt ihr die Teile ?

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: micky0867 am 14 August 2017, 17:06:59
Hallo,

ich habe ein LaCrosseGateway.
Das ist vom Prinzip ein ESP8266, an dessen serieller Schnittstelle ein miniCUL hängt.
Die serielle ist per SerialBridge und IP erreichbar.

Kann ich dieses Konstrukt auch als SignalESP missbrauchen?
Ich habe gestern mal zu Spaß die Signalduino Source für den ProMini kompiliert und auf den miniCUL geflasht.
Aber beim Anlegen des SignalDuino in FHEM hat mich dann der Optimismus verlassen...könnte mann da einfach IP-Adresse:Port angeben?

Micky
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 14 August 2017, 21:35:01
Hallo,

wenn auf dem ESP ESP-Link oder ESP-Easy läuft, kann man den über IP:Port@Baudrate ansprechen.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 August 2017, 21:42:20
Hi,
brauche mal wieder eure Hilfe.
Wollte mein SignalESP flashen für 433MHZ Sender und Empfänger.
Habe Ihn angeschlossen und die letzte Version von trebron106 verwendet.

Mim NodeMCU flasher auf Adresse 0X00000 geflashed.

ESP startet und die LED blinkt. Es geht aber kein WLAN Netz auf noch meldet er sich an meinem an.

Habe noch keinen Sender und Empfänger angeschlossen. Ist das nötig damit er hoch bootet?

Gruß,
Stefan

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 15 August 2017, 22:06:58
Hallo zusammen,

ich habe mir eine aktuelle Arduino IDE, VisualStudio (Community Edition) und Visual Micro Version installiert. Anschließend SignalDuino und SignalESP von Github als ZIP heruntergeladen, im gleichen Ordner entpackt (jeweils Verzeichnisse SIGNALDuino und SIGNALESP) und dann im SIGNALESP Verzeichnis die SLN Datei mit VisualStudio geöffnet. Dann bei Erstellen auf "SIGNALESP erstellen" angeklickt und dann kommt das:Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\SIGNALESP\configwifi.h
Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\src\_micro-api\libraries\WIFIManager\WiFiManager.cpp
Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\src\_micro-api\libraries\WIFIManager\WiFiManager.h
Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\SIGNALESP\configwifi.h
Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\src\_micro-api\libraries\WIFIManager\WiFiManager.cpp
Ignoring source code that is included in the project but can not be located: C:\Users\Manuel\Downloads\SIGNALESP\src\_micro-api\libraries\WIFIManager\WiFiManager.h
Visual Micro free version. CTRL+click for secure purchase http://www.visualmicro.com/page/shop.aspx

Compiling 'SIGNALESP' for 'NodeMCU 1.0 (ESP-12E Module)'

signalDecoder.cpp:34: In file included from
signalDecoder.cpp: In member function void SignalDetectorClass::printMsgStr(const String*, const String*, const String*)

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:826: note  in expansion of macro MSG_PRINT
   MSG_PRINT(*first)

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:827: note  in expansion of macro MSG_PRINT
   MSG_PRINT(*second)

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:828: note  in expansion of macro MSG_PRINT
   MSG_PRINT(*third)
signalDecoder.cpp: In member function int8_t SignalDetectorClass::printMsgRaw(uint8_t, uint8_t, const String*, const String*)

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:834: note  in expansion of macro MSG_PRINT
   MSG_PRINT(*preamble)

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:842: note  in expansion of macro MSG_PRINT
   MSG_PRINT(message[m_start])

output.h: 13:21: error: 'Client' was not declared in this scope
   #define MSG_PRINTER Client \\ Not Implemented at this time
output.h:24: note  in expansion of macro MSG_PRINTER
   #define MSG_PRINT(...) { MSG_PRINTER.print(__VA_ARGS__); }
signalDecoder.cpp:848: note  in expansion of macro MSG_PRINT
   MSG_PRINT(*postamble)

WiFiUdp.cpp:29: In file included from

WiFiUdp.h: 27:7: error: redefinition of 'class WiFiUDP
class WiFiUDP *: public UDP {

wifi_drv.h:26: In file included from
WiFiUdp.cpp:26: from

WiFiUdp.h: 32:7: error: previous definition of 'class WiFiUDP
class WiFiUDP *: public UDP, public SList<WiFiUDP> {
WiFiUdp.cpp: In constructor WiFiUDP::WiFiUDP()

WiFiUdp.cpp: 35:22: error: class 'WiFiUDP' does not have any field named '_sock
WiFiUDP*: WiFiUDP() : _sock(NO_SOCKET_AVAIL) {}
WiFiUdp.cpp: In member function virtual uint8_t WiFiUDP::begin(uint16_t)

WiFiUdp.cpp: 45:9: error: '_sock' was not declared in this scope
   _sock = sock

WiFiUdp.cpp: 46:9: error: '_port' was not declared in this scope
   _port = port
WiFiUdp.cpp: In member function virtual int WiFiUDP::available()

WiFiUdp.cpp: 56:7: error: '_sock' was not declared in this scope
   if (_sock != NO_SOCKET_AVAIL)
WiFiUdp.cpp: In member function virtual void WiFiUDP::stop()

WiFiUdp.cpp: 66:8: error: '_sock' was not declared in this scope
   if (_sock == NO_SOCKET_AVAIL)

WiFiUdp.cpp: 69:26: error: '_sock' was not declared in this scope
    ServerDrv*: stopClient(_sock)
WiFiUdp.cpp: In member function virtual int WiFiUDP::beginPacket(IPAddress, uint16_t)

WiFiUdp.cpp: 88:7: error: '_sock' was not declared in this scope
   if (_sock == NO_SOCKET_AVAIL)

WiFiUdp.cpp: 90:7: error: '_sock' was not declared in this scope
   if (_sock != NO_SOCKET_AVAIL)
WiFiUdp.cpp: In member function virtual int WiFiUDP::endPacket()

WiFiUdp.cpp: 101:32: error: '_sock' was not declared in this scope
  return ServerDrv*: sendUdpData(_sock)
WiFiUdp.cpp: In member function virtual size_t WiFiUDP::write(const uint8_t*, size_t)

WiFiUdp.cpp: 111:27: error: '_sock' was not declared in this scope
  ServerDrv*: insertDataBuf(_sock, buffer, size)
WiFiUdp.cpp: In member function virtual int WiFiUDP::read()

WiFiUdp.cpp: 125:23: error: '_sock' was not declared in this scope
    ServerDrv*: getData(_sock, &b)
WiFiUdp.cpp: In member function virtual int WiFiUDP::read(unsigned char*, size_t)

WiFiUdp.cpp: 137:31: error: '_sock' was not declared in this scope
    if (!ServerDrv*: getDataBuf(_sock, buffer, &size))
WiFiUdp.cpp: In member function virtual int WiFiUDP::peek()

WiFiUdp.cpp: 152:22: error: '_sock' was not declared in this scope
   ServerDrv*: getData(_sock, &b, 1)
WiFiUdp.cpp: In member function virtual IPAddress WiFiUDP::remoteIP()

WiFiUdp.cpp: 166:25: error: '_sock' was not declared in this scope
  WiFiDrv*: getRemoteData(_sock, _remoteIp, _remotePort)
WiFiUdp.cpp: In member function virtual uint16_t WiFiUDP::remotePort()

WiFiUdp.cpp: 176:25: error: '_sock' was not declared in this scope
  WiFiDrv*: getRemoteData(_sock, _remoteIp, _remotePort)

spi_drv.cpp: 21:17: fatal error: SPI.h: No such file or directory
   #include <SPI.h>
   compilation terminated
Error compiling libraries
Build failed for project 'SIGNALESP'
Was fehlt denn noch in meinen Schritten um SIGNALESP für NodeMCU (LoLin) zu compilieren?

p7
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 15 August 2017, 22:48:02
Dir fehlt configwifi.h.

Die hatte ich nicht eingecheckt :(

Ich würde dir gerne eine Beispiel Datei senden, aber mir hat es den Internet Zugang heute gegrillt.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 15 August 2017, 22:53:32
So hab jetzt mal beim booten nen seriellen Monitor dran gemacht: D1 ist an GND um den WIFI Manager zu resetten.
Trotzdem bekomme ich diese Ausgabe:
mounted file system
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 10.0.1.56
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0

Exception (29):
epc1=0x4000e1c3 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000018 depc=0x00000000

ctx: cont
sp: 3fff17f0 end: 3fff1ca0 offset: 01a0

>>>stack>>>
3fff1990:  4024921d 00000017 60000200 401077cc 
3fff19a0:  40221565 40245b92 00000001 4021a492 
3fff19b0:  b30fd5cc 4021ca57 3fff3d94 3fff38f4 
3fff19c0:  402217a6 3fff3d94 3fff38f4 3fff0a50 
3fff19d0:  00000000 3ffee760 3ffee6dc 3fff38f4 
3fff19e0:  3fff0a50 3fff0a50 00000001 3fff0a50 
3fff19f0:  00000018 00000064 21a620a2 fffeffff 
3fff1a00:  3ff20a00 0000ffff 3fff1a28 4021d0fa 
3fff1a10:  3ffee6dc 3fff38f4 3fff38f4 3fff0a50 
3fff1a20:  21a620a2 3fffc3c6 00000000 00000000 
3fff1a30:  00000000 00000000 00000000 00000000 
3fff1a40:  00000000 00000000 00000000 00000000 
3fff1a50:  00000000 00000000 00000000 4021e24c 
3fff1a60:  3fff38f4 00000001 00000000 4021e294 
3fff1a70:  00000000 3ffee760 3ffef4e8 00000000 
3fff1a80:  4022dc4d 00000003 00000003 000003fd 
3fff1a90:  4022dd9d 00000003 00000001 3fff0a50 
3fff1aa0:  3fff346c 4022de12 00000003 3ffe8a44 
3fff1ab0:  4020bb2d 00000000 00000000 3ffe9768 
3fff1ac0:  00000000 3ffe9768 3fff1b50 40211353 
3fff1ad0:  3fff0b94 000001f4 000001f4 4010020c 
3fff1ae0:  00000000 3ffe8a44 3fff1b1c 4010068c 
3fff1af0:  3ffe92d4 4024ef24 3fff0bbc 00000000 
3fff1b00:  00000000 3ffe8a44 3fff1b50 402114d9 
3fff1b10:  00000000 00000000 00000000 00000000 
3fff1b20:  00000000 00000000 3fff0bbc 40213c1c 
3fff1b30:  feefeffe 3fff1cc4 3fff1b50 3fff0c78 
3fff1b40:  3fffdad0 3ffe8984 3fff0bbc 40209b7a 
3fff1b50:  00000000 00000000 3ffe914c 00000000 
3fff1b60:  3fff2574 0000000f 00000000 3fff3454 
3fff1b70:  0000000f 00000000 00000000 00000000 
3fff1b80:  00000000 3ffe9768 00000000 3ffe9768 
3fff1b90:  00000000 3ffe9768 00000000 3ffe9768 
3fff1ba0:  3801000a 3ffe9768 0101000a 3ffe9768 
3fff1bb0:  00ffffff 00000000 ffffffff fe000001 
3fff1bc0:  3ffe92d4 00000000 fe01ef35 00000000 
3fff1bd0:  40206b18 feefeffe feefeffe feefeffe 
3fff1be0:  feefeffe feefeffe feefeffe feefeffe 
3fff1bf0:  feefeffe feefeffe feefeffe 3ffe9768 
3fff1c00:  00ffffff feefeffe feefeffe feefeffe 
3fff1c10:  feefeffe 3ffe9768 0101000a feefeffe 
3fff1c20:  feefeffe 3ffe9768 3801000a feefeffe 
3fff1c30:  feefeffe feefeffe feefeffe feefeffe 
3fff1c40:  3ffe9768 00ffffff 3ffe9768 0101000a 
3fff1c50:  3ffe9768 3801000a feefeffe feefeffe 
3fff1c60:  feefeffe feefeffe feefeffe feefeffe 
3fff1c70:  feefeffe feefeffe feefeffe 3fff0c78 
3fff1c80:  3fffdad0 00000000 3fff0c70 40214f74 
3fff1c90:  feefeffe feefeffe 3fff0c80 40100718 
<<<stack<<<



Irgendjemand eine Idee?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 15 August 2017, 22:57:03
Zitat von: Sidey am 15 August 2017, 22:48:02
Dir fehlt configwifi.h.

Die hatte ich nicht eingecheckt :(

Ich würde dir gerne eine Beispiel Datei senden, aber mir hat es den Internet Zugang heute gegrillt.
Kein Streß! Wenn er die Tage wieder funktioniert, schick die Datei einfach nach und gib hier kurz bescheid. Ich würde dann auch wenn die Zeit es zulässt, mal dokumentieren von Anfang bis Ende wie ich dann alles zum laufen bekommen habe, ich denke das würde einigen helfen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 15 August 2017, 23:27:37
Zitat von: stefanru am 15 August 2017, 22:53:32
So hab jetzt mal beim booten nen seriellen Monitor dran gemacht: D1 ist an GND um den WIFI Manager zu resetten.
Trotzdem bekomme ich diese Ausgabe:
mounted file system
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 10.0.1.56
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0

Exception (29):
epc1=0x4000e1c3 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000018 depc=0x00000000

ctx: cont
sp: 3fff17f0 end: 3fff1ca0 offset: 01a0

>>>stack>>>
3fff1990:  4024921d 00000017 60000200 401077cc 
3fff19a0:  40221565 40245b92 00000001 4021a492 
3fff19b0:  b30fd5cc 4021ca57 3fff3d94 3fff38f4 
3fff19c0:  402217a6 3fff3d94 3fff38f4 3fff0a50 
3fff19d0:  00000000 3ffee760 3ffee6dc 3fff38f4 
3fff19e0:  3fff0a50 3fff0a50 00000001 3fff0a50 
3fff19f0:  00000018 00000064 21a620a2 fffeffff 
3fff1a00:  3ff20a00 0000ffff 3fff1a28 4021d0fa 
3fff1a10:  3ffee6dc 3fff38f4 3fff38f4 3fff0a50 
3fff1a20:  21a620a2 3fffc3c6 00000000 00000000 
3fff1a30:  00000000 00000000 00000000 00000000 
3fff1a40:  00000000 00000000 00000000 00000000 
3fff1a50:  00000000 00000000 00000000 4021e24c 
3fff1a60:  3fff38f4 00000001 00000000 4021e294 
3fff1a70:  00000000 3ffee760 3ffef4e8 00000000 
3fff1a80:  4022dc4d 00000003 00000003 000003fd 
3fff1a90:  4022dd9d 00000003 00000001 3fff0a50 
3fff1aa0:  3fff346c 4022de12 00000003 3ffe8a44 
3fff1ab0:  4020bb2d 00000000 00000000 3ffe9768 
3fff1ac0:  00000000 3ffe9768 3fff1b50 40211353 
3fff1ad0:  3fff0b94 000001f4 000001f4 4010020c 
3fff1ae0:  00000000 3ffe8a44 3fff1b1c 4010068c 
3fff1af0:  3ffe92d4 4024ef24 3fff0bbc 00000000 
3fff1b00:  00000000 3ffe8a44 3fff1b50 402114d9 
3fff1b10:  00000000 00000000 00000000 00000000 
3fff1b20:  00000000 00000000 3fff0bbc 40213c1c 
3fff1b30:  feefeffe 3fff1cc4 3fff1b50 3fff0c78 
3fff1b40:  3fffdad0 3ffe8984 3fff0bbc 40209b7a 
3fff1b50:  00000000 00000000 3ffe914c 00000000 
3fff1b60:  3fff2574 0000000f 00000000 3fff3454 
3fff1b70:  0000000f 00000000 00000000 00000000 
3fff1b80:  00000000 3ffe9768 00000000 3ffe9768 
3fff1b90:  00000000 3ffe9768 00000000 3ffe9768 
3fff1ba0:  3801000a 3ffe9768 0101000a 3ffe9768 
3fff1bb0:  00ffffff 00000000 ffffffff fe000001 
3fff1bc0:  3ffe92d4 00000000 fe01ef35 00000000 
3fff1bd0:  40206b18 feefeffe feefeffe feefeffe 
3fff1be0:  feefeffe feefeffe feefeffe feefeffe 
3fff1bf0:  feefeffe feefeffe feefeffe 3ffe9768 
3fff1c00:  00ffffff feefeffe feefeffe feefeffe 
3fff1c10:  feefeffe 3ffe9768 0101000a feefeffe 
3fff1c20:  feefeffe 3ffe9768 3801000a feefeffe 
3fff1c30:  feefeffe feefeffe feefeffe feefeffe 
3fff1c40:  3ffe9768 00ffffff 3ffe9768 0101000a 
3fff1c50:  3ffe9768 3801000a feefeffe feefeffe 
3fff1c60:  feefeffe feefeffe feefeffe feefeffe 
3fff1c70:  feefeffe feefeffe feefeffe 3fff0c78 
3fff1c80:  3fffdad0 00000000 3fff0c70 40214f74 
3fff1c90:  feefeffe feefeffe 3fff0c80 40100718 
<<<stack<<<



Irgendjemand eine Idee?

Gruß,
Stefan

Ja ich
Hatte eben auch das Problem. Du musst den USB-Stecker einstecken, und dann direkt danach die Pins bruecken. vorher geht nicht. Hat bei mir dann aber sofort auf Anhieb geklappt!
Gruss und viel Erfolg
Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 15 August 2017, 23:47:32
Hi,

das hat bei mir leider auch nicht geholfen.
Hast du die 433 mit D1 an GND oder die cc1101 mit D3 an GND?

Also ich habe die 433 und D1 auf GND bewirkt nichts. Siehe log von oben.
D3 auf GND bewirkt dass nur noch diese Meldung im Log erscheint.
Aber auch kein Netzwerk sichtbar wird:
ets Jan  8 2013,rst cause:2, boot mode:(1,7)

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 16 August 2017, 08:47:34
Moin
Ich habe den CC1101. Wie gesagt hatte ich auch das Problem, und ich habe dann wohl gluecklicherweise genau den Zeitpunkt getroffen, den D3 auf GND zu ziehen. Bei Dir muesste das dann D1 sein. Ob ich es mit dem Reset gemacht habe kann ich nicht genau sagen. Auf jeden Fall anschalten (Reset?) und direkt dann die Bruecke.
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 16 August 2017, 18:08:04
Hallo,

ich habe diese Version vom SignalESP  (https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497) von trebron106 im Einsatz.
Arduino IDE 1.8.1 + esp8266, nach dieser Anleitung (http://www.mikrocontroller-elektronik.de/nodemcu-esp8266-tutorial-wlan-board-arduino-ide/).
Der Code wird auch per Arduino IDE auf den esp8266 (NODEMCU) gebracht.

Beim starten kommt das in der IDE-Console (CC1101)

mounted file system
reading config file
opened config file
{"ip":"192.168.2.101","gateway":"192.168.2.1","subnet":"255.255.255.0"}
parsed json
setting custom ip from config
192.168.2.101
*WM:
*WM: AutoConnect
*WM: Connecting as wifi clienô.nN
*WM: Custom STA IP/GW/Subnet
*WM: 192.168.2.101
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.2.101
connected....
3.3.1-dev SIGNALEsp - compiled at Aug 13 2017 22:22:08
Using sFIFO  Size: 255
Reading values fom eeprom
CCInit
SRES Started
POR Done
Write Defaults done
EEPROM writePatable
CCVersion=20
CCPartnum=0
cc1101 found
Starting timerjob
HTTPUpdateServer ready!
192.168.2.101
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled


und bei einem nackten esp8266 (NODEMCU) ohne zusätzliche Komponeten das hier. Das starten ging auch erst nach dem 2. flashen.

mounted file system
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 192.168.2.101
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.2.101
connected....
3.3.1-dev SIGNALEsp - compiled at Aug 16 2017 18:02:14
Using sFIFO  Size: 255
Reading values fom eeprom
CCInit
SRES Started
POR Done
Write Defaults done
EEPROM writePatable
CCVersion=255
CCPartnum=255
no CC11xx found!

Starting timerjob
HTTPUpdateServer ready!
192.168.2.101
receiver enabled
New client:
CMD: XQ
CMD: V
CMD: XE
CMD: P


vielleicht hilft es ja.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 16 August 2017, 18:52:55
Ich finde es ungünstig, wenn Änderungen, die nicht im SignalESP Repo eingecheckt werden.

Jetzt haben wir eine SignalESP Version von X und bald eine von Y.
Wer soll da noch durchblicken?

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 16 August 2017, 20:11:19
Zitat von: Sidey am 16 August 2017, 18:52:55
Ich finde es ungünstig, wenn Änderungen, die nicht im SignalESP Repo eingecheckt werden.
...
Hallo sidey,

Das ist richtig. Dann sollten wir diese Version einchecken. Weil die zur Zeit hinterlegte Version läuft bei mir auch nicht.
Das kann ja vielleicht als extra branch erfolgen.

Jörg
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 16 August 2017, 20:16:58
Hallo sidey
Du weisst doch wie das ist. Wenn man dann alles beisammen  hat, dann will man auch loslegen. Und bei Deiner Version (eingecheckt) fehlt(e?) ja noch das wificonfig, so dass man nicht weiterkam. Also nimmt man das was evtl. funktioniert, und dann kommt so etwas dabei heraus. Ich glaube es sind nur alle heiss, auf das Teil!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 16 August 2017, 21:00:21
Also ich freue mich, wenn es eine compilierbare Version des Source Codes gibt :) Habe 433 MHz Geräte außerhalb der Reichweite meines Rpi und würde die gerne "einfangen"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 16 August 2017, 21:02:08
[emoji106]
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 16 August 2017, 21:24:54
Hi,
ich finde Sidey hat recht. Er steckt viel Arbeit in die FW rein. Insofern ist es doch okay, ihm die Änderungen zur Verfügung zu stellen, damit im dev Branch des Signalduinos der Input ebenfalls drin ist. Damit haben wir alle was davon!

Sidey DANKE [emoji1303]
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 16 August 2017, 22:38:24
Ja klar, da wäre ich auch dafür.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 16 August 2017, 22:57:46
Zitat von: prodigy7 am 15 August 2017, 22:06:58
Hallo zusammen,

ich habe mir eine aktuelle Arduino IDE, VisualStudio (Community Edition) und Visual Micro Version installiert. Anschließend SignalDuino und SignalESP von Github als ZIP heruntergeladen,

Okay, Fehler gefunden.

Da Du das Projekt als ZIP geladen hast, fehlt dir jetzt ein submodul.
Ein GIT Client kann das automatisch, alle submodule rekursiv mitladen.

Du müsstest nur das eingebundene submodul laden und in den Ordner SIGNALESP\src\_micro-api\libraries\WIFIManager entpacken:

https://github.com/tzapu/WiFiManager/tree/master

@all
Was das Anpassen angeht: Ich bin für anpassungen dankbar. Das ist open source. Ich finde es nur schade, wenn hier jeder eine eigene Signalesp Version generiert. In einem halben Jahr weiss doch niemand mehr, welche Version was kann oder auch nicht.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 17 August 2017, 06:58:38
Wenn ich es richtig verstanden habe, läuft die Version auf github nicht überall /richtig? Wäre dankbar, wenn ihr die Modifikationen noch zur Verfügung stellen könntet
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 17 August 2017, 07:48:12
Dass der Sketch aus dem Repo nicht läuft ist mir so erst mal nicht bekannt. Hat man alle Bibliotheken klappts.

Soweit ich mich erinnere wurde in einem Fork der cc1101 Support eingebaut.
In einem anderen Support wurde was mit WLAN und statischen IP Adressen gemacht.

Statische IP Adressen finde ich so in Zeiten von IOT und IPV6 schwierig.

Wie ihr seht, blicke ich da schon nicht mehr durch :(

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 17 August 2017, 09:52:44
Zitat von: Sidey am 17 August 2017, 07:48:12Soweit ich mich erinnere wurde in einem Fork der cc1101 Support eingebaut.
Genau den bräuchte ich z.B. Wäre schön, wenn jeder der Änderungen gemacht hat, diese als Pull Requests einreichen würde!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 17 August 2017, 10:12:10
Zitat von: Sidey am 17 August 2017, 07:48:12
Dass der Sketch aus dem Repo nicht läuft ist mir so erst mal nicht bekannt. Hat man alle Bibliotheken klappts.
Sorry, aber es klappt eben nicht, da eine Include-Datei referenziert wird, welche nicht im Repo ist:
Strolchi ~/Development/esp8266 $ git clone --recursive https://github.com/RFD-FHEM/SIGNALESP.git
Cloning into 'SIGNALESP'...
remote: Counting objects: 153, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 153 (delta 4), reused 7 (delta 2), pack-reused 144
Receiving objects: 100% (153/153), 76.89 KiB | 0 bytes/s, done.
Resolving deltas: 100% (71/71), done.
Checking connectivity... done.
Submodule 'src/_micro-api/libraries/WIFIManager' (https://github.com/tzapu/WiFiManager.git) registered for path 'src/_micro-api/libraries/WIFIManager'
Cloning into 'src/_micro-api/libraries/WIFIManager'...
remote: Counting objects: 718, done.
remote: Total 718 (delta 0), reused 0 (delta 0), pack-reused 718
Receiving objects: 100% (718/718), 221.96 KiB | 0 bytes/s, done.
Resolving deltas: 100% (391/391), done.
Checking connectivity... done.
Submodule path 'src/_micro-api/libraries/WIFIManager': checked out '60c22d672fadfdcf139853f766d1824730944e13'
Strolchi ~/Development/esp8266 $ cd SIGNALESP
Strolchi ~/Development/esp8266/SIGNALESP $ grep -r include .|grep -i wificlient
./src/_micro-api/libraries/output/src/output.h:#include <wificlient.h>
Strolchi ~/Development/esp8266/SIGNALESP $ find . -iname wificlient.h
Strolchi ~/Development/esp8266/SIGNALESP $



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 17 August 2017, 10:21:57
Nachtrag:
gleiches gilt wohl auch für "configwifi.h"...
Strolchi ~/Development/esp8266/SIGNALESP $ find . -iname configwifi.h
Strolchi ~/Development/esp8266/SIGNALESP $ find . -iname *.h
./SIGNALESP/__vm/.SIGNALESP.vsarduino.h
./src/_micro-api/libraries/SimpleFIFO/src/SimpleFIFO.h
./src/_micro-api/libraries/WIFIManager/WiFiManager.h
./src/_micro-api/libraries/WIFIManager/extras/template.h
./src/_micro-api/libraries/bitstore/src/bitstore.h
./src/_micro-api/libraries/output/src/output.h
./src/_micro-api/libraries/signalDecoder/src/signalDecoder.h
Strolchi ~/Development/esp8266/SIGNALESP $
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 17 August 2017, 12:30:06
Sidey, Ich habe nun mal Dein Repo geforkt: https://github.com/susisstrolch/SIGNALESP
Der Branch "trebron106" enthält die Änderungen, die "trebron106" seit November durchgeführt wurden und ist auf dem Stand vom 08.08.2017.

Die einzelnen commits basieren auf den Sourcen, die er hier im Forum veröffentlicht hat.

Die Anpassungen für Visual Studio / Visual Micro habe ich NICHT durchgeführt (Linux only Desktop).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 17 August 2017, 14:40:09
Moin
Leider muss ich dem zustimmen! Du hast selbst in diesem post https://forum.fhem.de/index.php/topic,58396.msg672595.html#msg672595 geschrieben, dass etwas fehlt. Ich konnte dieses aber per Internet-Suche nicht finden, so dass sich der Sketch nicht kompilieren liess. Mit der Version von Klaus war es dann eher unproblematisch!
Natuerlich sollte es am Ende nur eine Software geben, aber wir sind halt alle immer so ungeduldig!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 17 August 2017, 14:52:37
Zitat von: prodigy7 am 17 August 2017, 09:52:44
Wäre schön, wenn jeder der Änderungen gemacht hat, diese als Pull Requests einreichen würde!
Nun, da die Repostruktur auf Visual Schiessmichtot ausgelegt ist, vereinfacht es die Sache nicht unbedingt bei denen, die mit bspw. Arduino UI oder PlatformIO arbeiten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 17 August 2017, 16:19:15
Zitat von: prodigy7 am 17 August 2017, 09:52:44
Genau den bräuchte ich z.B. Wäre schön, wenn jeder der Änderungen gemacht hat, diese als Pull Requests einreichen würde!
gibt es (https://github.com/RFD-FHEM/SIGNALESP/pulls)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 19 August 2017, 09:18:58
Danke an Sidey und alle beteiligten, der SignalESP Branch lässt sich jetzt compilieren! NodeMCU hat sich erfolgreich flashen und mit meinem WLAN verbinden lassen, als nächstes baue ich dann mal die Schaltung zusammen.

Binary hänge ich mal anbei, vielleicht kann jemand den aktuellen Stand gebrauchen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 August 2017, 10:17:45
Gerne, das war erst mal Schritt #1.
Die Unterstützung für den cc1101 habe ich in einen eigenen Branch gepackt und die Libs auf den aktuellsten Stand gebracht.
Compilieren lässt dieser sich auch, aber ich habe es noch nicht ausprobieren können.

Wenn das fertig ist, könnten die anderen Erweiterungen aufgenommen werden.


Gruß Sidey



Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 19 August 2017, 16:28:15
Ah okay, dass das in einem eigenen Branch ist, hatte ich zuerst übersehen. Der CC1101 Branch lässt sich aktuell nicht compilieren, habe ein Issue dafür eröffnet.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 13:47:31
Anbei eine aktuelle Version für NodeMCU aus dem CC1101 Branch.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 August 2017, 13:50:31
Läuft die bei dir? Ich habe gestern Abend noch festgestellt, dass der Watchdog den ESP sehr oft neu startet

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 14:19:26
Zitat von: Sidey am 20 August 2017, 13:50:31Läuft die bei dir? Ich habe gestern Abend noch festgestellt, dass der Watchdog den ESP sehr oft neu startet
Habe geflashed und er hat sich auch schon via Wifi verbunden, weiter kam ich aber noch nicht da ich momentan einen "Hänger" habe bei der Transferleistung, wie ich das beim NodeMCU stecken muss.

Habe mal Bilder angehängt. Auf den ersten zwei Bildern ist die Verkabelung zu erkennen wie es derzeit bei mir mit CC1011 + Arduino direkt am USB Anschluss funktioniert. Mich als Laie irritiert jetzt, dass es andere Ein-/Ausgänge gibt beim NodeMCU.

Verwendet wird aktuell:
D13 (blaues Kabel)
D12 (gelbes Kabel)
D11 (braunes Kabel)
D10 (orangenes Kabel)
D3 (pinkes Kabel)
D2 (türkises Kabel)
GND (schwarzes Kabel)
3V3 (rotes Kabel)

Vermute dass das D3 und D2 ist (von der Reihenfolge der Beschriftung, kann es leider nicht auf der Platine entziffern)

Wenn ich von der Unterseite meiner CC1101 Platine ausgehe, die keine Beschriftungen hat und die markierte (extra eingegrenzte) Ecke 0 ist, sind die Kabel wie folgt angeschlossen:

+---+---+---+---+---+
| 5 | 6 | 7 | 8 | 9 |
+---+---+---+---+---+
|[0]| 1 | 2 | 3 | 4 |
+---+---+---+---+---+


0 (rotes Kabel)
1 (braunes Kabel)
2 (gelbes Kabel)
3 (oranges Kabel)
4 (schwarzes Kabel)
5 (- nichts -)
6 (blaues Kabel)
7 (türkises Kabel)
8 (pinkes Kabel)
9 (- nichts -)

Finden tu ich auf dem NodeMCU
G (wird wohl GND sein, vermutlich kann ich ein beliebiges G nehmen)
3V (wird wohl das Gegenstück zu 3V3 sein, kann ich auch beliebiges nutzen?)

Bei den D Eingängen frage ich mich, ob ich die 1:1 umsetzen kann. Beim Node gibt es D0, beim Arduino sehe ich keinen solchen beschriftet.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 20 August 2017, 14:35:26
@prodigy7

so ist meine Beschaltung, das steht so in der souce von trebron106 drin.
Und hier die Beschaltung des ESP8266 (NodeMCU) http://www.mikrocontroller-elektronik.de/wp-content/uploads/2017/01/NodeMCU-pinbelegung.png

/*
*   ESP8266            cc1101
*   
*   VDD           -------- VDD    3.3V
*   GPIO4  / D2   -------- GDO0
*   GPIO5  / D1   -------- GDO2
*   GPIO12 / D6   -------- MISO  --|  SPI Bus
*   GPIO13 / D7   -------- MOSI  --|
*   GPIO14 / D5   -------- SCLK  --|
*   GPIO15 / D8   -------- CSn   --|
*   GND           -------- GND
*   
*   Led GPIO16 / D0
*/

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 15:33:10
ggf. sind die Platinen baugleich
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 16:06:08
Danke für eure Hilfe! Habe es soweit verkabelt und mir ist noch nichts um die Ohren geflogen nach dem Anschließen! :-P

Jetzt die Fragen,

a) kann ich irgendwie Quick & Dirty testen ob prinzipiell alles funktioniert? Via Telnet angemeldet bekomme ich Rückmeldung auf einzelne BefehleV^MV 3.3.1-dev SIGNALESP  - compiled at Aug 19 2017 23:37:37
t^M377
R^M41368


b) Liege ich richtig damit, das Device dann mit define signalESP SIGNALduino 192.168.100.148 anzulegen? Habe ich gemacht, aber aktuell steht bei Status "disconnected". Schaue ich ins Log, sehe ich 2017.08.20 15:58:08.663 3: signalESP: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 41 51 55 6 68 7
2017.08.20 15:58:08.664 3: signalESP: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 34 36 37 39 40 44 44.1 45 46 48 49 5 50 56 59 60 61 62 63 64 65 66 67 8 9
2017.08.20 15:58:08.664 3: signalESP: IDlist MC 10 11 12 18 43 47 52 57 58
2017.08.20 15:58:08.665 3: Opening signalESP device 192.168.100.148
2017.08.20 15:58:08.666 3: Can't open 192.168.100.148: Datei oder Verzeichnis nicht gefunden
was mir wohl zeigt, dass die einfache IP Angabe wohl nicht so ganz richtig ist. Evtl. Prefix oder ähnliches notwendig? Wenn ich mal erfolgreich durch bin, dokumentiere ich das mal alles im Wiki :-)

Edit: Okay, Verbindung nimmt FHEM jetzt auf. Es fehlte der Port 23 bei der Angabe. Habe Verbose mal auf 3 gesetzt, kommen aber keine Meldungen rein. Musst ich evtl. noch irgendeinen bestimmten Hardware-Typ auswählen?

2017.08.20 16:22:19.666 3: signalESP433_CC1101/init: get version, retry = 1
2017.08.20 16:22:22.480 3: signalESP433_CC1101 reset
2017.08.20 16:22:22.481 3: Opening signalESP433_CC1101 device 192.168.100.148:23
2017.08.20 16:22:22.568 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:22:22.569 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:22:22.570 3: signalESP433_CC1101 device opened
2017.08.20 16:22:24.072 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:22:24.572 3: signalESP433_CC1101/init: get version, retry = 0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 20 August 2017, 16:22:08

define signalESP SIGNALduino 192.168.100.148:23  den Port noch mit angeben.

pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 16:26:44
Scheint nicht stabil irgendwie zu laufen wenn ich mir die diversen Verbindungsversuche ansehe:2017.08.20 16:25:15.130 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:15.132 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:15.133 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:16.635 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:18.952 2: (return undef) FALSE 2: 404 Error HELP Counter: 3
2017.08.20 16:25:19.905 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:19.941 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:19.952 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:19.973 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:19.983 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:19.984 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:19.985 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:21.488 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:21.987 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:22.013 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:22.024 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:22.036 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:22.052 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:22.053 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:22.055 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:23.557 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:24.057 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:24.084 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:24.095 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:24.107 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:24.121 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:24.122 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:24.123 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:25.626 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:26.125 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:26.145 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:26.156 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:26.167 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:26.182 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:26.183 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:26.184 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:27.686 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:28.186 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:28.206 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:28.217 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:28.229 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:28.243 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:28.244 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:28.245 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:31.318 2: (return undef) FALSE 2: 404 Error HELP Counter: 3
2017.08.20 16:25:32.103 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:32.113 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:32.244 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:32.254 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:32.265 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:32.273 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:32.274 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:32.274 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:33.776 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:34.276 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:34.368 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:34.379 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:34.391 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:34.403 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:34.404 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:34.405 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:35.905 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:36.406 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:36.432 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:36.443 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:36.454 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:36.469 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:36.470 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:36.471 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)
2017.08.20 16:25:37.973 3: signalESP433_CC1101/init: disable receiver (XQ)
2017.08.20 16:25:38.473 3: signalESP433_CC1101/init: get version, retry = 0
2017.08.20 16:25:38.493 2: signalESP433_CC1101: initialized. v3.3.1-dev
2017.08.20 16:25:38.504 3: signalESP433_CC1101/init: enable receiver (XE)
2017.08.20 16:25:38.515 1: 192.168.100.148:23 disconnected, waiting to reappear (signalESP433_CC1101)
2017.08.20 16:25:38.529 1: signalESP433_CC1101/define: 192.168.100.148:23
2017.08.20 16:25:38.529 1: signalESP433_CC1101/init: 192.168.100.148:23
2017.08.20 16:25:38.530 1: 192.168.100.148:23 reappeared (signalESP433_CC1101)

Anbei die Verkabelung, vielleicht fällt euch noch was auf?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 16:31:09
Was steht den in der seriellen Konsole?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 16:36:27
Serielle Konsole:�d�l܄���l`�섃n��


Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff

Try connecting to WiFi with SSID 'WLAN'
                                             ......
                                                   Connected successful to SSID 'WLAN'
                                                                                            *WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148
receiver enabled
New client:
New client:
New client:
New client:
New client:
Die Zeile mit "New client" wiederholt sich regelmäßig bei jedem Verbindungsversuch von FHEM
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 16:58:05
der cc1101 wird nicht erkannt

es fehlen zwei Zeilen:

*WM: IP Address:
*WM: 192.168.10.38
connected...)
local ip
192.168.xxx.xxx
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
New client:


scheinbar sind D6 und D7 vertauscht!

welchen branch hast du in Arbeit?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 17:10:25
D6 und D7 getauscht, aber keine Änderung. Ich habe den dev-cc1101 Branch verwendet gehabt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 17:16:25
probier mal bitte folgende Änderung in cc1101.h

alt:

#define CC1101_PARTNUM      0xF0 // Chip ID
#define CC1101_VERSION 0xF1 // Chip ID

neu:

#define CC1101_PARTNUM      0x30 // Chip ID
#define CC1101_VERSION 0x31 // Chip ID
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 17:28:26
Zitat von: habeIchVergessen am 20 August 2017, 17:16:25
probier mal bitte folgende Änderung in cc1101.h

alt:

#define CC1101_PARTNUM      0xF0 // Chip ID
#define CC1101_VERSION 0xF1 // Chip ID

neu:

#define CC1101_PARTNUM      0x30 // Chip ID
#define CC1101_VERSION 0x31 // Chip ID

Geändert, compiliert, geflashed, aber kein Unterschied. Auch nochmal die beiden D getauscht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 18:01:28
anbei ein BIN-File.

Ausgabe:

Reading values fom eeprom

dump EEPROM:
33 1d 07 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found

Try connecting to WiFi with SSID ''
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 19:44:32
Geflashed, verkabelung geprüft, jetzt kommen ständige Reboots vermutlich durch den Watchdog:
ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
   ▒


Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
SRES Started
POR Done
CCVersion=0xff
CCPartnum=0x0
no CC11xx found!


Try connecting to WiFi with SSID 'WLAN'
                                             ..
                                               Connected successful to SSID 'WLAN'
                                                                                        *WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 19:56:20
ein BIN-File mit den 0x30 Registern
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 20:19:48
Keine Watchdog Reboots mehr, CC1101 wird dennoch nicht erkannt.▒d{▒▒oc▒l▒d▒▒▒d▒d`▒▒g▒



Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
SRES Started
POR Done
CCVersion=0xff
CCPartnum=0xff
no CC11xx found!


Try connecting to WiFi with SSID 'WLAN'
                                             ......
                                                   Connected successful to SSID 'WLAN'
                                                                                            *WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148
receiver enabled
New client:
Ich habe extra mal die CC1100 Module getauscht, d.h. das dass am SignalDUINO funktionierte an den SignalESP angeschlossen und umgekehrt. Am SignalDUINO läufts, SignalESP mag das Modul nicht erkennen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 August 2017, 21:03:11
Ich habe mir mal die Pinouts genauer angesehen:

https://goo.gl/images/CJMZpo

Ich bin nicht ganz sicher, aber vermutlich werde die falschen Ports verwendet.
Ich habe es jetzt mal auf die GPIO12-15 gestellt.

Die WDT Resets habe ich vermutlich besser in den Griff bekommen. Aktualisierung liegt wie üblich in github
ub

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 21:17:48
kann nicht die Ursache sein, da es bei mir auf einem NodeMCU1.0 und Wemos D1 mini funktioniert. Würde auch davon abraten, die Defaults der Hardware-Umgebung nicht zu verwenden.

@p7: prüfe bitte mal die Spannungsversorgung und die Verkabelung
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 August 2017, 21:23:25
Weißt Du welche Pins bei MOSI,MISO,SCK und CS hinterlegt sind?

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 21:24:29
Aktualisiert, aber keine Änderung.▒d▒l▒▒▒▒l ▒'▒▒


Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff

Try connecting to WiFi with SSID 'WLAN'
                                             scandone
                                                     f 0, scandone
                                                                  state: 0 -> 2 (b0)
                                                                                    state: 2 -> 3 (0)
                                                                                                     state: 3 -> 5 (10)
                                                                                                                       add 0
                                                                                                                            aid 3
                                                                                                                                 cnt

                                                                                                                                     connected with WLAN, channel 8
dhcp client start...
                     .ip:192.168.100.148,mask:255.255.255.0,gw:192.168.100.254
                                                                              .
                                                                               Connected successful to SSID 'WLAN'
                                                                                                                        *WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148
receiver enabled
pm open,type:2 0
                New client:
New client:


@habeIchVergessen: Ich hatte heute Mittag mal alle verwendeten Kabel durchgemessen, weil ich tatsächlich auch mal ein Kabel hatte in der Vergangenheit, dass einen Kabelbruch hatte. Schienen soweit aber alle Kabel okay zu sein. Verkabelung ist gleich wie auf deinem Bild zu sehen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 August 2017, 21:25:49
Du musst //#define CMP_CC1101  wieder aktivieren :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 21:28:38
Zitat von: Sidey am 20 August 2017, 21:25:49
Du musst //#define CMP_CC1101  wieder aktivieren :)
In SIGNALESP.ino Kommentierung raus genommen, jetzt Compilefehler:Visual Micro free version. CTRL+click for secure purchase http://www.visualmicro.com/page/shop.aspx

Compiling 'SIGNALESP' for 'NodeMCU 1.0 (ESP-12E Module)'

Error linking for board NodeMCU 1.0 (ESP-12E Module)
Build failed for project 'SIGNALESP'

SIGNALESP.cpp.o*: In function storeFunctions(signed char, signed char, signed char)
SIGNALESP.ino:922: undefined reference to cmdstringPos2int(unsigned char)

SIGNALESP.cpp.o*: In function configCMD()
SIGNALESP.ino:922: undefined reference to cmdstringPos2int(unsigned char)

collect2.exe*: error: ld returned 1 exit status
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 August 2017, 21:32:09
:(

Ich sollte vielleicht doch mehr testen..

Fehler ist behoben.. war zum Glück nur ein Tippfehlerchen.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 20 August 2017, 21:38:42
Wieder Watchdog resets ...*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148

ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
   ▒


Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
SRES Started
POR Done
scandone
        state: 0 -> 2 (b0)
                          state: 2 -> 3 (0)
                                           state: 3 -> 5 (10)
                                                             add 0
                                                                  aid 3
                                                                       cnt

                                                                           connected with WLAN, channel 8
                                                                                                               dhcp client start...
                                                                                                                                   CCVersion=0xff
CCPartnum=0x0
no CC11xx found!

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 20 August 2017, 21:51:12
Zitat von: Sidey am 20 August 2017, 21:23:25
Weißt Du welche Pins bei MOSI,MISO,SCK und CS hinterlegt sind?

Gesendet von meinem XT1650 mit Tapatalk
die Konstanten MOSI, MISO, SCK und SS werden in packages\esp8266\hardware\esp8266\2.3.0\libraries\SPI\SPI.cpp verwendet

void SPIClass::begin() {
    pinMode(SCK, SPECIAL);  ///< GPIO14
    pinMode(MISO, SPECIAL); ///< GPIO12
    pinMode(MOSI, SPECIAL); ///< GPIO13

    SPI1C = 0;
    setFrequency(1000000); ///< 1MHz
    SPI1U = SPIUMOSI | SPIUDUPLEX | SPIUSSE;
    SPI1U1 = (7 << SPILMOSI) | (7 << SPILMISO);
    SPI1C1 = 0;
}

void SPIClass::end() {
    pinMode(SCK, INPUT);
    pinMode(MISO, INPUT);
    pinMode(MOSI, INPUT);
    if(useHwCs) {
        pinMode(SS, INPUT);
    }
}

void SPIClass::setHwCs(bool use) {
    if(use) {
        pinMode(SS, SPECIAL); ///< GPIO15
        SPI1U |= (SPIUCSSETUP | SPIUCSHOLD);
    } else {
        if(useHwCs) {
            pinMode(SS, INPUT);
            SPI1U &= ~(SPIUCSSETUP | SPIUCSHOLD);
        }
    }
    useHwCs = use;
}


rein zufällig stehen die echten Ports in den Kommentaren der Entwickler
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 22 August 2017, 16:58:05
Ich hab mir jetzt mal ein passendes Steckbrett inkl. Zubehör bestellt und werde es damit erst nochmal sauber aufbauen. Die Leute, die einen NodeMCU verwenden der funktioniert: Was genau ist das für ein Modell? Habt ihr irgendwelche Beschriftungen oder ähnliches, wo ich vergleichen kann ob ich evtl. ein anderes Modell habe oder so?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 August 2017, 17:52:57
NodeMCU DevKit 1.0 (https://www.amazon.de/gp/product/B00XJG7GEK/ref=ox_sc_act_title_1?smid=A6CMTM77NPXN&psc=1)
anbei noch ein BIN-File mit Sidey's letzten Änderungen (exkl. Bugs).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 22 August 2017, 17:54:41
Zitat von: habeIchVergessen am 22 August 2017, 17:52:57
NodeMCU DevKit 1.0 (https://www.amazon.de/gp/product/B00XJG7GEK/ref=ox_sc_act_title_1?smid=A6CMTM77NPXN&psc=1)
anbei noch ein BIN-File mit Sidey's letzten Änderungen (exkl. Bugs).

Funktioniert die BIN jetzt aber nur auf NodeMCU oder auch auf der Variante mit Wemos D1 mini?
Ich habe hier so langsam den Überblick verloren welche Version man mit welcher Hardware nutzen kann.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 22 August 2017, 18:07:22
Also, auf Breadbord alles zusammengesteckt, noch mit alter Firmware: Ging nichts!

Dann jetzt deine neue Firmware geflashed und siehe da, das sieht viel besser aus!�d�l����l ��n�)


Reading values fom eeprom

dump EEPROM:
33 1d 07 37 32 33 62 31 36 36 36 39 39 38 33 32
39 63 36 32 64 34 65 64 62 36 35 66 32 38 32 32
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0xff
CC1101 found (rev. 01)

Try connecting to WiFi with SSID ''

                                   Could not connect to WiFi. state='0'
                                                                       Please press WPS button on your router
WPS config start
wifi_wps_enable
               wps scan
                       build public key start
                                             build public key finish
                                                                    f r0, wps discover [WLAN]
                                                                                                   scandone
                                                                                                           WPS: neg start
                                                                                                                         f r0, scandone
                                                                                                                                       state: 0 -> 2 (b0)
                                                                                                                                                         state: 2 -> 3 (0)
                                                                                                                                                                          state: 3 -> 5 (10)
                                                                                                                                                                                            add 0
                                                                                                                                                                                                 aid 1
                                                                                                                                                                                                      cnt
                                                                                                                                                                                                          proct
                                                                                                                                                                                                              h
                                                                                                                                                                                                              ]
                                                                                                                                                                                                              d
                                                                                                                                                                                                              )
                                                                                                                                                                                                              0
                                                                                                                                                                                                              e
                                                                                                                                                                                                              )
                                                                                                                                                                                                              '
                                                                                                                                                                                                              e
                                                                                                                                                                                                              e
                                                                                                                                                                                                              )
                                                                                                                                                                                                              )
                                                                                                                                                                                                              )
                                                                                                                                                                                                              0
                                                                                                                                                                                                              1
                                                                                                                                                                                                               

                                                                                                                                                                                                              8
                                                                                                                                                                                                              .
                                                                                                                                                                                                              4
                                                                                                                                                                                                              .
                                                                                                                                                                                                              t
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.100.148
connected...)
local ip
192.168.100.148
CC1100_PKTCTRL0=57 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=255 vs EEPROM IOCFG2=13
cc1101 is not correctly set. Please do a factory reset via command e
pm open,type:2 0
Merkwürdig ist, dass wenn ich ihn via WPS verbunden habe, er sich nach drücken des Reset-Knopfes die Konfiguration nicht gemerkt hat. Der Reset-Knopf war ja nur ein Neustart, kein vollständiges Zurücksetzen der Konfiguration oder? Wenn ich das USB Kabel ziehe nach erfolgreicher Konfiguration und wieder einstecke, rebootet sich der NodeMCU. Sieht dann in etwa so aus:
ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 August 2017, 18:20:32
Zitat von: gloob am 22 August 2017, 17:54:41
Funktioniert die BIN jetzt aber nur auf NodeMCU oder auch auf der Variante mit Wemos D1 mini?
sollte auch auf dem Wemos D1 mini funktionieren. Wenn nicht, dann kann ich auch noch eine bauen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 22 August 2017, 18:22:52
Zitat von: habeIchVergessen am 22 August 2017, 18:20:32
sollte auch auf dem Wemos D1 mini funktionieren. Wenn nicht, dann kann ich auch noch eine bauen.

Ist denn geplant, dass es irgendwo einen zentralen Punkt gibt, wo man die aktuelle Firmware findet, außer hier im Thread verteilt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 August 2017, 18:27:27
Sidey baut immer die Text-Dateien  (z.B. hier) (https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt) für ein update via fhem

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


ich bin in seine Pläne nicht eingeweiht!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 August 2017, 21:50:06
Zitat von: prodigy7 am 22 August 2017, 18:07:22
Dann jetzt deine neue Firmware geflashed und siehe da, das sieht viel besser aus!
Am Code für den cc1101 (SPI) hat sich nichts geändert. Lediglich der rssi-Callback wird jetzt nur aufgerufen, wenn dieser ordentlich initialisiert wurde.
WPS kann ich nicht beurteilen. Würde vermuten, dass bei jedem Booten vom NodeMCU am Router das entsprechende Köpfchen zu drücken ist.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 22 August 2017, 21:54:18
Zitat von: habeIchVergessen am 22 August 2017, 21:50:06
WPS kann ich nicht beurteilen. Würde vermuten, dass bei jedem Booten vom NodeMCU am Router das entsprechende Köpfchen zu drücken ist.

Nein, WPS muss nicht jedes mal initialisiert werden. Ich hatte es aber auch schon, dass keine Verbindung zustande kam.
Dann habe ich erneut resettet.

In diesem Fall scheint mir aber schon die CC1101 Initialisierung abgeschlossen zu sein und dann schlägt der Watchdog zu.
Da ich immer wieder yield() aufrufe eingebaut habe, sollte das nicht passieren. Ist bei mir aber auch so.


Zitat von: gloob am 22 August 2017, 18:22:52
Ist denn geplant, dass es irgendwo einen zentralen Punkt gibt, wo man die aktuelle Firmware findet, außer hier im Thread verteilt?
Ja, ich muss mir für das Updaten der Firmware ohnehin etwas überlegen. Die SignalESP Firmware ist aber noch nicht so weit.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 August 2017, 22:59:42
Zitat von: Sidey am 22 August 2017, 21:54:18
Da ich immer wieder yield() aufrufe eingebaut habe, sollte das nicht passieren.
yield() muss an den richtigen Stellen aufgerufen wrden! z.B. nach dem Schreiben einer Nachricht in serverClient (MSG_PRINTLN-Marco wäre eine gute Stelle, wenn im Code konsequent genutzt).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 23 August 2017, 08:07:39
@sidey: Besteht vielleicht die Möglichkeit, zumindest temporär, dass du bei jedem Push von neuem Code automatisch ein BIN erstellst das mit im Repo abgelegt wird? Bin gerne bereit, regelmäßig und fleißig zu testen wenn dass dazu beiträgt, einer stabile und gut funktionierenden SignalESP Version näher zu kommen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 23 August 2017, 20:57:15
Leute, es funktioniert jetzt bei mir! Scheinbar hat der NodeMCU einen Schlag weg! Hat mich gefrustet, dass er sich nie die Wifi Konfiguration merken wollte und hab den anderen den ich hier liegen hatte, mal geflashed und siehe da: Ging sofort! Und es kommen auch Signale via CC1101 rein! Endlich! :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 August 2017, 22:51:07
Zitat von: prodigy7 am 23 August 2017, 08:07:39
@sidey: Besteht vielleicht die Möglichkeit, zumindest temporär, dass du bei jedem Push von neuem Code automatisch ein BIN erstellst das mit im Repo abgelegt wird?

Sodele, ich habe mich mal etwas mit dem automatischen compilieren beschäftigt.

Die aktuelle Version des SIGNALESP findet ihr jetzt erst mal hier (wird automatisch compiliert). Vermutlich stelle ich den Update Mechanismus generell um, so dass man dann auch für den signalDuino die Firmware auf github findet. Ich weiss nur leider noch nicht wie.
Hier der Link:
https://github.com/RFD-FHEM/SIGNALESP/releases
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 August 2017, 23:09:27
war ein hartes Stück Arbeit!
woher kommt devmc in den Releases?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 August 2017, 23:25:40
Zitat von: habeIchVergessen am 25 August 2017, 23:09:27
war ein hartes Stück Arbeit!
woher kommt devmc in den Releases?

Arbeit war es, Du hast mir ja zum Glück bei den compile Fehler gut geholfen.

Das devmc habe ich aus dem SIGNALduino übernommen, damit ich weiss dass ich hier schon den angepassten MC Decoder habe :)

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 28 August 2017, 11:21:07
@sidey: Vielen Dank für deine Arbeit! Da ich momentan krank im Bett liege, hab ich mir mal meinen Laptop geschnappt und mal die aktuellste Firmware die du als Release generiert hast, geflashed. Irgendwie klappt es aktuell mit dem Empfang bei mir nicht. Was mir aufgefallen ist, dass der Output wie dieser hier Ms;▒▒▒;▒Ї;▒ǁ;▒▒;dT44444T4T44T4444T4TTT4444444TT4T44TTT;C4;S0;R2;
                                                                Mu;▒▒▒;▒▒;▒▒▒;▒Ԁ;▒؂;▒▒▒;▒▒▒;▒▒▒;d#EepueeeuuueuueueueeeuueeeueeueeeeeeuuuueeeuCe
bei der Release Firmware oder selbst compilierten (devmc) Firmware nicht mehr auf der Telnet Konsole zu sehen ist sondern auf der seriellen. Ist hier irgendetwas durcheinander geraten? Ich vermute, dass das auf die Telnet Konsole gehört oder? Bei der letzten hier von habeIchVergessen veröffentlichten Binary hier ist das so und war auch bei den vorher compilierten Binarys aus dem CC1101 Branch so.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 August 2017, 12:17:08
Die Ausgabe sieht gut aus.
Das Ausgabeformat wurde komprimiert und daher ist es für Menschen schwer lesbar.

Gruß Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 28 August 2017, 12:23:56
Und es ist korrekt, dass die Ausgabe nicht via Telnet kommt sondern nur via USB/serieller Schnittstelle? Das gehört doch in die Telnet Ausgabe oder?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 28 August 2017, 13:24:44
Sollte via telnet kommen, wenn das nicht so ist, dann hast Du einen Fehler gefunden :)

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 28 August 2017, 13:45:42
Zitat von: Sidey am 28 August 2017, 13:24:44
Sollte via telnet kommen, wenn das nicht so ist, dann hast Du einen Fehler gefunden :)
Habe ein Issue bei Github eröffnet :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 28 August 2017, 23:57:50
Moin
Irgendwie spannt der kein Netz auf. Allerdings ist die IP-Adresse auch eher bloed! (0.0.0.0)
Mal sehen ob es per WPS funzt!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 29 August 2017, 06:56:33
Du kannst eine beliebige Firmware benutzen, um per GUI eine Netzwerkverbindung herzustellen. Anschließend wieder SIGNALESP flachen und Netzwerk sollte sich verbinden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 29 August 2017, 06:59:00
Hi,
Das mit dem Netz und IP 0.0.0.0 hatte ich auch, aber WPS worked like a charm!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 29 August 2017, 07:33:15
Zitat von: habeIchVergessen am 29 August 2017, 06:56:33
Du kannst eine beliebige Firmware benutzen, um per GUI eine Netzwerkverbindung herzustellen. Anschließend wieder SIGNALESP flachen und Netzwerk sollte sich verbinden.

Hmmm?
Da ich ja vorher eine andere drauf hatte, kann ich die Aussage so nicht bestaetigen! WPS hingegen habe ich leider nicht, da alles DD-WRT Router sind. Naja mal sehen, die vorgelagerte Fritzbox sollte gehen!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 August 2017, 07:41:46
Hmm, wenn WPS fehlt schlägt, sollte der ESP ein eigenes WLan aufbauen.

Bei mir hat das zuletzt auch nicht funktioniert. Das liegt dann wohl leider nicht an meinem ESP sondern doch im Code :(

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 29 August 2017, 09:34:40
Zitat von: pc1246 am 29 August 2017, 07:33:15
... da alles DD-WRT Router sind
das trifft bei mir auch zu! WPS habe ich noch nicht getestet. Ich habe allerdings noch nicht gelesen, dass das nicht geht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 29 August 2017, 17:53:07
Ich habe auch die Erfahrung mit einem ESP8266 in einem anderen Projekt gemacht, das WPS nicht mit jeder Fritzbox funktioniert. Ich hatte drei Varianten von Code aus dem Internet hier an einer Fritzbox 7390 durchprobiert. Nur eine davon funktionierte hier zuverlässig, aber mit einem älterem Typ Fritzbox funktionierte diese wiederum auch nicht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: cortmen am 29 August 2017, 18:57:21
 :)Hallo zusammen, vielleicht kann mir jemand einen
Tipp geben, warum mein Wemos D1 Mini  mit CC1101 (433Mhz) keine Daten aufzeichnet?

Ein anderen SignalDuino mit Nano mit C1101 zeichnet ne Menge Protokolle und Daten auf.

Hier ein Listing des Device:

Internals:
   CFGFN
   Clients    :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
   DEF        192.168.0.53:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.0.53:23
   FD         11
   NAME       SignalESP
   NR         144
   PARTIAL
   STATE      opened
   TIME       1504025013
   TYPE       SIGNALduino
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     11:SD_WS09 ^P9#[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^YsA[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[uP]\d+#.*
   QUEUE:
   READINGS:
     2017-08-29 18:44:51   ITParms         Unsupported command
     2017-08-29 18:43:35   state           opened
     2017-08-29 18:44:09   uptime          0 00:01:28
     2017-08-29 18:44:35   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     32
     33
     35
     38
     4
     41
     45
     6
     7
   muIdList:
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     42
     44
     46
     48
     49
     5
     50
     51
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]

 
verbose = 4   ist gesetzt

Auch eine neuere Version aus dem Development bringt keine Änderung.
Angeschlossen ist CC1101 exakt so:




Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 29 August 2017, 19:07:46
Was liefert denn ein

get ccconf

Bei mir sieht die Antwort so aus:

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Und ein vollständiges List, falls du vergleichen möchtest:

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        192.168.1.35:23
   DMSG       u635555550
   DevState   initialized
   DeviceName 192.168.1.35:23
   FD         29
   LASTDMSG   u635555550
   MSGCNT     83
   NAME       SIGNALESP433
   NR         547
   PARTIAL
   RAWMSG     MU;P0=-32001;P1=470;P2=-8327;P3=-2111;P4=-4260;P5=-1570;D=0121212121212121212121313131314131414131313131313141414131414131313141413141314141313141313131313131313141212131313131415;CP=1;R=238;
   RSSI       -83
   STATE      opened
   TIME       1504026394.66016
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-07-02 13:17:57   ITParms         Unsupported command
     2017-08-29 19:08:01   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-07-22 12:22:01   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2017-07-22 12:21:51   config          MS=1;MU=1;MC=1
     2017-08-29 19:05:14   ping            OK
     2017-08-29 11:01:07   state           opened
     2017-07-21 16:10:41   uptime          0 00:05:10
     2017-08-29 11:01:07   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     8
     9
Attributes:
   cc1101_frequency 433.92
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   icon       cul_cul
   room       Gateways,SignalESP
   verbose    0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: cortmen am 29 August 2017, 19:32:32
get SignalESP ccconf liefert:

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Habe noch mal den SignalESP gelöscht, im Listing zu Deinen gibt einige Werte die gefüllt sind:

Internals:
   CFGFN
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        192.168.0.53:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.0.53:23
   FD         15
   LASTDMSG   nothing
   NAME       SignalESP
   NR         27
   PARTIAL
   STATE      opened
   TIME       1504027589
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-08-29 19:27:47   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-08-29 19:29:31   ping            OK
     2017-08-29 19:26:31   state           opened
     2017-08-29 19:26:31   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       SignalESP
   verbose    4


Da scheint der CC1101 wohl nicht zu funktionieren, angeschlossen ist er richtig. ^^ Noch 3 x geprüft..
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 29 August 2017, 19:52:46
das compile-Datum ist schon recht alt. Auch sollte da SIGNALESP stehen.

SIGNALESP.bin (https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin) mal von hier laden und flashen.
poste mal bitte die Ausgabe der seriellen Schnittstelle.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: cortmen am 29 August 2017, 20:13:02
Habe mal geflash.

Jetzt gehen einige Befehle nicht mehr z.b ccconf etc

Internals:
   CFGFN
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        192.168.0.53:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.0.53:23
   FD         15
   LASTDMSG   nothing
   NAME       SignalESP
   NR         27
   PARTIAL
   STATE      opened
   TIME       1504027589
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Aug 28 2017 21:30:52
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-08-29 19:27:47   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-08-29 20:07:04   ping            OK
     2017-08-29 20:02:03   state           opened
     2017-08-29 20:02:03   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Aug 28 2017 21:30:52
   getcmd:
     cmd        ccconf
     timenow    1504030240
     asyncOut:
       Authenticated 0
       BUF
       FD         13
       FW_ID      108
       LASTACCESS 1504030260
       NAME       WEB_192.168.0.43_54953
       NR         108
       PEER       192.168.0.43
       PORT       54953
       SNAME      WEB
       SSL
       STATE      Connected
       TEMPORARY  1
       TYPE       FHEMWEB
       canAsyncOutput 1
   keepalive:
     ok         0
     retry      2
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       SignalESP
   verbose    4



Warum steht im Listing 868Mhz ?   2017-08-29 20:02:03   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Aug 28 2017 21:30:52

mit putty auf serial COM8 bekomme ich nichts rein.
Oder gibt noch eine andere Möglichkeit für Serial Console?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 29 August 2017, 20:19:37
Hi,
Mir fehlt:
attr SignalESP hardware nanoCC1101
Was sagt ein
get SignalESP cc1101_ccconf
Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: cortmen am 29 August 2017, 20:24:35
attr hardware ist gesetzt. Keine Änderung.
Mit der Firmware compiled at Jun  6 2017 12:37:19  .....haben die Befehle im WEB Interface ausgaben erzeugt.
ccconf, ccpatable etc geben keine Werte mehr aus.

Den Befehl get SignalESP cc1101_ccconf   gibt es nicht


Bring die Serial Console über Minicom mehr..bzw. wie rufe ich sonst die Serial Console beim SignalESP auf?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 29 August 2017, 20:43:23
Nein, kann es sein das Du ein FHEM update gemacht hast? Und danach die Entwicklerversion vom Signduino Modul nicht mehr eingespielt hast?



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 29 August 2017, 20:44:02
Zitat von: cortmen am 29 August 2017, 20:13:02
Warum steht im Listing 868Mhz ?   2017-08-29 20:02:03   

version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Aug 28 2017 21:30:52

Oder gibt noch eine andere Möglichkeit für Serial Console?
da wird die Version der Hardware ausgewertet. Ggf. sind meine Annahmen bzgl. der gelesenen Werte nicht zutreffend.
Die serielle Konsole wird über USB ausgegeben. Da steht noch einiges, das bei der Initialisierung ausgegeben wird ( u.a. die Version).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: cortmen am 29 August 2017, 20:46:52
* Danke für die schnelle Hilfe, habe mal mit ESP8266Flasher unter Windows einem flash durchgeführt.
Läuft, Protokolle fühlen sich.

Allerdings wie oben beschrieben mit der Development Version von 28.8 erzeugen die Befehle get SignalESP ccconf und ccpatable geben keine Werte am Bildschirm

Meldungen über Serial Console bei Start:

...scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 10
cnt

connected with *****, channel 11
dhcp client start...
chg_B1:-40
.ip:192.168.0.53,mask:255.255.255.0,gw:192.168.0.251
.
Connected successful to SSID '******'
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.0.53
connected...)
local ip
192.168.0.53
receiver enabled
chg_B1:-80
pm open,type:2 0



im Log steht  get .. ccconf
SignalESP/msg READ: Received answer (MS;P2=-1983;P3=470;P4=-4539;P5=-9535;D=3534343432343234343432343232323232343434323234343232343432;CP=3;SP=5;R=238;) for ccconf does not match C0Dn11.*

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 29 August 2017, 22:01:03
Dass ccconf nicht geht, hatte ich auch durchgängig seitdem ich SignalESP verwende! Ebenso ccpatable, ccreg. Andere Befehle funktionieren.

Was mir noch aufgefallen ist, war, dass bei Version version: V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Aug 22 2017 17:45:28 ausgegeben wird. Die 868MHz irritieren mich weil ein 433MHz Modul angeschlossen habe (https://www.amazon.de/gp/product/B01CI01F94/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 29 August 2017, 22:19:50
in der seriellen Ausgabe müsste ziemlich am Anfang CCVersion= und CCPartnum= ausgegeben werden.
Die Angabe der Frequenz resultiert aus der Version. Bei meinen Modulen sind das 0x14 868 und 0x18 433. Wenn sich das in der Praxis nicht bewährt, dann muss es halt weg.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 01 September 2017, 09:47:19
So
Hat gestern abend dann doch noch mit dem WPS geklappt. Nachdem ich erst eine Fritz-Box SL am Start hatte, und mich gewundert habe, warum denn die 7050 keine Antenne hat, habe ich dann die 7050 rausgekramt. Nach kurzer Zeit wusste ich dann, dass die kein WPS kann, also den naechsten Veteranen gesucht, WGR614V6, kann aber auch kein WPS. OK, also den Repeater vom Gastnetz, der schien aber gerade mal wieder OFF zu sein. Kurz in der 7490 im Gastnetz geguckt, aha da kann man das per SW ausloesen, und schwupps war ich verbunden. Daumm war dann nur, dass ich nicht aufs Webinterface draufkam (Bestimmt falschen Port genommen!), und dass nach Abschalten des GaesteNetzes der SignalESP nach einem Neustart wieder kein Netz aufgespannt hat. Es war wieder die 0.0.0.0 da.
Da ich aber dann auch mal ins Bett musste, werde ich da am WE weitermachen, und zur Not die Reserve 7490 meine Sohnes missbrauchen.
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Cruiser79 am 02 September 2017, 08:24:10
Zitat von: pc1246 am 01 September 2017, 09:47:19
So
Hat gestern abend dann doch noch mit dem WPS geklappt. Nachdem ich erst eine Fritz-Box SL am Start hatte, und mich gewundert habe, warum denn die 7050 keine Antenne hat, habe ich dann die 7050 rausgekramt. Nach kurzer Zeit wusste ich dann, dass die kein WPS kann, also den naechsten Veteranen gesucht, WGR614V6, kann aber auch kein WPS. OK, also den Repeater vom Gastnetz, der schien aber gerade mal wieder OFF zu sein. Kurz in der 7490 im Gastnetz geguckt, aha da kann man das per SW ausloesen, und schwupps war ich verbunden. Daumm war dann nur, dass ich nicht aufs Webinterface draufkam (Bestimmt falschen Port genommen!), und dass nach Abschalten des GaesteNetzes der SignalESP nach einem Neustart wieder kein Netz aufgespannt hat. Es war wieder die 0.0.0.0 da.
Da ich aber dann auch mal ins Bett musste, werde ich da am WE weitermachen, und zur Not die Reserve 7490 meine Sohnes missbrauchen.
Gruss Christoph

Wenn du mit Gastnetz das Gastnetz der Fritzbox meinst, ist das Verhalten erklärbar. Das Fritzbox Gastnetz ist vom normalem Fritzbox WLAN und Netzwerk abgeschottet. Da kommt man weder rein, noch raus. Insofern kannst du auch nicht auf den signalesp zugreifen. Du musst den Esp schon in dein normales WLAN einloggen.

Gruß,
Tim
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 02 September 2017, 08:59:04
Genau, das AVM Gastnetz verbindet zwar mit dem Internet, aber Verbindungen innerhalb der WLAN-Zelle sind unterbunden - eben GAST-Netz.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 04 September 2017, 09:19:42
@cruiser and Rappa
Das der Gastzugang nicht mit meinem Netz zusammenkommt ist mir klar!Trotzdem haette ich erwartet, dass ich auf das WebIf komme, und da dann die richtigen Einstellungen vornehmen kann!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 September 2017, 09:28:15
Hi,
ich meine mich zu erinnern, dass die Fritte im Gastnetz Kommunikation zwischen den Geräten im Default deaktiviert.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 04 September 2017, 10:21:21
Zitat von: RaspiLED am 04 September 2017, 09:28:15
Hi,
ich meine mich zu erinnern, dass die Fritte im Gastnetz Kommunikation zwischen den Geräten im Default deaktiviert.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Danke,
vergesst das einfach, ich hatte nur keine Zeit am WE, so dass ich das morgen in Angriff nehme!
gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 September 2017, 17:31:02
Hi,
ich habe es gestern endlich geschafft einen gloobschen SignalESP auf 868.300 MHz einzustellen. Ist mir nicht genau klar was der hatte (zeigte immer 875.940 MHz), aber am Ende habe ich dreimal die Juni FW geflasht, jetzt ist ccconf stabil auf 868.300. Die aktuelle FW findet den cc1101 nicht! Einer eine Idee?


Nun kommt der eigentliche Hintergrund:
In der FW Version vom Juni ist Somfy nicht aktiv. Hat einer eine funktionierende und getestete Somfy SignalESP FW?


Gruß Arnd
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 04 September 2017, 18:13:40
mit FW meinst du die Sourcen auf github (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101/SIGNALESP)?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 September 2017, 18:55:38
Am liebsten eine HEX/bin die getestet ist. Aber ja: github compiliert hier in einer Arduino IDE und flashed ohne Fehler auf den Wemos. Aber er findet den cc1101 danach nicht, mit der Juni FW hier im Thread läuft er.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 04 September 2017, 19:01:44
Zitat von: habeIchVergessen am 04 September 2017, 18:13:40
mit FW meinst du die Sourcen auf github (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101/SIGNALESP)?

Gerade auch den aktuellen Stand von GitHub getestet.

ccconf liefert nur:

This command is only available with a cc1101 receiver

Hier ist noch ein List vom SignalESP:

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
   DEF        192.168.1.35:23
   DMSG       W51#0B124D8CCB0
   DevState   initialized
   DeviceName 192.168.1.35:23
   FD         21
   LASTDMSG   W51#0B124D8CCB0
   MSGCNT     210
   NAME       SIGNALESP433
   NR         546
   PARTIAL
   RAWMSG     MS;P0=557;P1=-4022;P2=-2142;P3=-7876;D=03020202020102010102020201020201020201020201010201010202020101020201010202010201010202;CP=0;SP=3;R=232;
   RSSI       -86
   STATE      opened
   TIME       1504544270.04776
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.1-dev SIGNALESP - compiled at Sep  4 2017 18:59:31
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-07-02 13:17:57   ITParms         Unsupported command
     2017-09-04 17:05:16   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-07-22 12:22:01   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2017-07-22 12:21:51   config          MS=1;MU=1;MC=1
     2017-09-04 19:01:32   ping            OK
     2017-09-04 19:00:32   state           opened
     2017-09-03 12:24:01   uptime          0 03:24:40
     2017-09-04 19:00:32   version         V 3.3.1-dev SIGNALESP - compiled at Sep  4 2017 18:59:31
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     8
     9
Attributes:
   cc1101_frequency 433.92
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   icon       cul_cul
   room       Gateways,SignalESP
   verbose    0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 September 2017, 19:24:08
Ja genau, das habe ich auch. Erinnere ich mich richtig, dass Ralf9 jetzt auch ID des CC1101 ausliest? Ich gabe das gleiche Problem nämlich gerade auch auf einem nanaCUL Aufbau mit gleichem CC1101 868 Modul. Helfen Serielle Ausgaben oder irgendwelche Logs, um den Fehler einzugrenzen?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 September 2017, 19:44:01
Hallo Raspiled,

Wir lesen  diverse Register des cc1101 aus. Wenn das Ergebnis nicht passt, dann wird der cc1101 nicht als solcher erkannt.

Direkt nach dem Starten des ESP gibt dieser auf der seriellen Konsole diverse Informationen aus.
Die würden erst Mal weiterhelfen um das Problem eingrenzen zu können.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 04 September 2017, 19:49:47
Also die Firmware bei GitHub gibt keine Debug Ausgaben zum CC1101 aus. Da hört es nach dem Lesen des EEPROM auf.

Die Juni-Version hat dort deutlich mehr Informationen angezeigt.

Die OTA-Update Funktionalität ist ja scheinbar auch raus geflogen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 September 2017, 19:51:34
Welche hast Du von github geladen?

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 04 September 2017, 19:52:47
Zitat von: Sidey am 04 September 2017, 19:51:34
Welche hast Du von github geladen?

https://github.com/RFD-FHEM/SIGNALESP/tree/master/SIGNALESP

Debug Ausgabe vom Master Trunk:

Try connecting to WiFi with SSID 'HasenpupsExtreme'
..
Connected successful to SSID 'HasenpupsExtreme'
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.1.35
connected...)
local ip
192.168.1.35
Reading values fom eeprom
New client:
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 04 September 2017, 20:14:20
master ist relativ alt.

im branch dev-cc1101 funktioniert ccconf nicht (Compiler-Flag comp_cc1101).
ebenfalls das Schreiben in den EEPROM hat einen Fehler (Index+1 notwendig).

Dafür ist die signalDecoder-Bibliothek aktuell.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 September 2017, 23:54:10
Hi habeIchVergessen,
Das heisst, wenn ich unter
https://github.com/RFD-FHEM/SIGNALESP/releases
die letzte 3.3.1a nehme, geht viel, aber nicht das ccconf!? Immerhin wird da der CC1101 erkannt !-)

Was empfiehlst Du denn jetzt konkret zu machen?

Den master aus github nicht, okay.
Wenn ich den dev-cc1101 als zip ziehe fehlen mir weitere Abhängigkeiten, wie libs fast...h und memory.h

Jetzt habe ich git für windows geladen und ein
git clone https://github.com/RFD-FHEM/SIGNALESP
Aber wie komme ich jetzt an den tree dev-cc1101?

Sorry brauche einen Schubs !-)
Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 September 2017, 07:08:47
mit -b kann der Branch ausgewählt werden. Die beiden oben beschriebenen Bugs sind in meinen Sourcen gefixt.

git clone -b dev-cc1101 https://github.com/habeIchVergessen/SIGNALESP

Die Inhalte der src-Verzeichnisse unter libraries müssen unter Windows nach %USERPROFILE%\Documents\Arduino\libraries\ in ein neues Verzeichnis (z.B. signalesp) kopiert werden. WiFiManager muss separat von github geladen werden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 September 2017, 07:13:06
Zitat von: habeIchVergessen am 05 September 2017, 07:08:47
Die beiden oben beschriebenen Bugs sind in meinen Sourcen gefixt.

git clone -b dev-cc1101 https://github.com/habeIchVergessen/SIGNALESP

Wäre es nicht besser, wenn du deine Änderungen im "anderen" GitHub Repository commiten würdest? Ich finde es relativ unschön wenn es 2 gibt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 September 2017, 08:42:35
Hallo Glob,

Er hat einen Pull Request gestellt.
Leider hat er mehrere Änderungen in einen PR verpackt.
Das zögert die Sache halt ein wenig heraus, da auch Änderungen enthalten sind, die ich erst mal nicht so übernehmen möchte.

Da jetzt ein paar grundlegende Anpassungen für die Datenübermittlung notwendig sind, verzögert es die Ganze Sache ein wenig.

Grüße Sidey

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 September 2017, 09:18:35
mit einem cherry pick der commits sollten die o.g. Bugs weg sein

f9824d40168b9a99274cfd8bd705df5c647dd936
3794e586a29ad796ef42a1f8a2519a6418671065
f0f26d7c35d445707e0ef0f37a44515c60942bca

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 September 2017, 14:49:01
Wie resette ich denn den ESP:

Zitatcc1101 is not correctly set. Please do a factory reset via command e

Findet gerade nicht die Möglichkeit einen Command "e" zu senden. Wenn ich e über die Arduino Console sende, passiert nix.




Kaum geschrieben schon gefunden:

set SIGNALESP raw e




Dann sieht die Console auch schon besser aus:

Reading values fom eeprom

dump EEPROM:
33 1d 0d 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found (rev. 01)

Try connecting to WiFi with SSID 'xxx'
......
Connected successful to SSID 'xxx'
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.1.35
connected...)
local ip
192.168.1.yyy
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled





Die Version wird nur scheinbar nicht richtig erkannt.

version: V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Sep 5 2017 14:44:15

Ich nutze ein 433MHz Modul:

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 September 2017, 15:10:00
868MHz? s. hier (https://forum.fhem.de/index.php/topic,58396.msg678595.html#msg678595)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 September 2017, 15:25:43
Sicher, dass du so einfach auf die Frequenz schließen kannst?

Ich habe dazu leider im Internet nichts gefunden.

Ich dachte immer die Unterschiede zwischen 433 und 868MHz sind nur unterschiedliche Antennenanpassungen nach dem CC1101
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 September 2017, 16:02:39
wahrscheinlich kann damit nur der Chip unterschieden werden. Bin auch noch am Sammeln von Spezifikationen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 05 September 2017, 17:34:04
Zitat von: gloob am 05 September 2017, 15:25:43
Sicher, dass du so einfach auf die Frequenz schließen kannst?

Ich habe dazu leider im Internet nichts gefunden.

Ich dachte immer die Unterschiede zwischen 433 und 868MHz sind nur unterschiedliche Antennenanpassungen nach dem CC1101

Hi,
Du kannst doch die Frequenz per set-Befehl anpassen. Die Antennenanpassung ist dann zwar nicht optimal aber es kann etwas empfangen werden.

Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 September 2017, 17:45:02
Zitat von: pejonp am 05 September 2017, 17:34:04
Hi,
Du kannst doch die Frequenz per set-Befehl anpassen. Die Antennenanpassung ist dann zwar nicht optimal aber es kann etwas empfangen werden.

Pejonp

Das weiß ich auch. Wäre halt schon wenn es konsistent wäre. Ich bin bestimmt nicht der letzte, der wegen sowas dann fragt. Besonders für Anfänger kann es sehr verwirrend sein und ich würde gerne solche Rückfragen vermeiden wollen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 05 September 2017, 18:05:24
Hallo zusammen.

Mit dem Signal esp ist bestimmt eine coole sache.

Wollte mal nachfragen worin der Vorteil bzw Nachteil zu einem nano mit wemos/esp und cc1101 besteht.
Mal abgesehen davon, da es ein Bauteil weniger gibt.

Ich persönlich finde dem Vorteil bei dem 3er Gespann gut, das ich auch bei Bedarf die afw flashen kann.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 September 2017, 19:57:04


Zitat von: habeIchVergessen am 05 September 2017, 09:18:35
mit einem cherry pick der commits sollten die o.g. Bugs weg sein

Hi habeIchvergessen,

Wie kann man ein commit von einem Pullrequest holen?
Ich weiss leider nicht, wie das gehen soll.

Grüße Sidey


Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 September 2017, 20:11:57
git cherry-pick sollte das Mittel der Wahl sein. theoretisch will man ja genau die Änderung aus einem commit haben. praktisch habe ich das auch noch nicht benutzt ;-)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 September 2017, 23:27:54
Zitat von: habeIchVergessen am 05 September 2017, 20:11:57
git cherry-pick sollte das Mittel der Wahl sein. theoretisch will man ja genau die Änderung aus einem commit haben. praktisch habe ich das auch noch nicht benutzt ;-)

Okay, ich habe das ausprobiert. Ein Cherrypick geht nicht aus dem PR, es geht nur aus einem Repository.
Also habe ich mir das Log aus deinem Repo gezogen und dann die commits einzeln. Das ist ziemlich aufwändig, da ich alle Abweichungen seither auch noch einzeln prüfen durfte.

Zumindest haben wir jetzt mal die Anpassungen von dir im cc1101 branch die für eine fehlerfrei Funktion sorgen sollten.
Es wäre schön, wenn das mal jemand ausprobieren könnte.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 06 September 2017, 08:03:28
Zitat von: habeIchVergessen am 05 September 2017, 20:11:57
git cherry-pick sollte das Mittel der Wahl sein. theoretisch will man ja genau die Änderung aus einem commit haben. praktisch habe ich das auch noch nicht benutzt ;-)
Optimalerweise git cherry-pick -x <id> verwenden, dann sieht man im Commit auch woher es gepicked wurde. Beispiel: [master c5693f6] bugfix (cherry picked from commit 3158f27)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 06 September 2017, 08:50:05
Zitat von: prodigy7 am 06 September 2017, 08:03:28
git cherry-pick -x <id>
mit -n lassen sich mehrere commits auf einen branch anwenden, ohne ein commit zu erzeugen (quasi eine Vorschau).
das macht dann aber auch einen zusätzlichen Aufruf notwendig

--continue
    Continue the operation in progress using the information in .git/sequencer. Can be used to continue after resolving conflicts in a failed cherry-pick or revert.
--quit
    Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.
--abort
    Cancel the operation and return to the pre-sequence state.

aber ohne praktische Erfahrung eher gefährliches Halbwissen.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 12 September 2017, 18:22:22
WLAN hat jetzt doch geklappt.

Allerdings spuckt er mir immer aus:

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Obwohl es ein CC1101 mit 868MHz ist. Ich kann dann die Frequenz auf 868MHz setzen, verliert der SignalESP allerdings den Strom ist die Config hinterher wieder auf 433.

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:CUL_FHTTK:SIGNALduino_un:
   DEF        192.168.1.121:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.1.121:23
   FD         22
   ITClock    250
   LASTDMSG   nothing
   NAME       SIGNALESP868
   NR         554
   PARTIAL
   STATE      opened
   TIME       1505232969.13146
   TYPE       SIGNALduino
   cc1101_frequency 868
   sendworking 0
   version    V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Sep 12 2017 18:34:11
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-07-02 13:17:37   ITParms         Unsupported command
     2017-09-12 18:38:57   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-07-02 13:53:22   ccpatable       C3E = 00 84 00 00 00 00 00 00
     2017-07-02 13:53:34   config          MS=1;MU=1;MC=1
     2017-07-02 13:53:31   freeram         37576
     2017-09-12 18:33:47   ping            OK
     2017-09-12 18:37:01   state           opened
     2017-07-08 16:16:00   uptime          0 00:06:14
     2017-09-12 18:37:55   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Sep 12 2017 18:34:11
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     70
     71
     8
     9
Attributes:
   cc1101_frequency 868.3
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   icon       cul_cul
   room       Gateways,SignalESP


Reading values fom eeprom

dump EEPROM:
33 1d 07 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found

Try connecting to WiFi with SSID 'HasenpupsExtreme'
......
Connected successful to SSID 'HasenpupsExtreme'
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.1.121
connected...)
local ip
192.168.1.121
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
New client:





Erledigt: Den Dev Branch von habeIchVergessen genutzt und dort geht es. Ich blick hier langsam bei den Versionen nicht mehr durch.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 12 September 2017, 21:45:25
Sidey hat per cherry-pick die erforderlichen commits im dev-cc1101 (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101)-branch übernommen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 12 September 2017, 21:55:49
Welchen Nutzen hat dann der dev-cc1101-cb
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 12 September 2017, 22:21:48
die kleinteiligen write's in WiFiClient werden immer in den TCP-Stack durchgereicht und direkt versendet.
Deshalb soll ein CallBack in signalDecoder eingebaut werden, der Hardware-abhängige Optimierungen in den Hauptthread verlagert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 15 September 2017, 16:51:17
Wie kommt eigentlich die DataRate zustande im ccconf? Ich erhalte immer unterschiedliche Werte.

ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:34019.47Baud)

ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 23 September 2017, 08:24:07
Hallo Zusammen,

habe mit der Inbetriebnahme zwei Probleme im Moment.
Zum einen, wenn ich IP und WLAN Daten eingebe, ist das Gerät einwandfrei zu erreichen. Mache ich es dann stromlos, sind die WLAN Daten weg aber IP ist noch richtig im Config Screen. Erreichbar ist er dann wieder unter der alten IP.
Sieht so aus als wenn er lediglich seine WLAN-Daten vergisst.
Zum andren komme ich nicht auf das Webinterface, wenn er mit der richtigen IP im WLAN ist. Also kurz nach der Initialconfig.
In FHEM ist er noch nicht definiert.

Hat da einer eine Idee?

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 24 September 2017, 16:15:47
hab nochmal rumprobiert...
Es ist definitiv so das immer nach einem Neustart die Wifi Einträge fehlen und das Modul dann in den AP Modus startet.
Ist das ein Hardware- oder Softwareproblem?


Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: prodigy7 am 24 September 2017, 16:32:47
Hatte das gleiche Problem hier gehabt! Habe dann einen anderen NodeMCU genommen und da ging es sofort. Der andere Node liegt hier jetzt noch rum, gibt wohl die Möglichkeit den Flash mal komplett zu resetten was ich noch vor habe.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: locutus am 24 September 2017, 17:22:52
Zitat von: Markus. am 23 September 2017, 08:24:07
Zum einen, wenn ich IP und WLAN Daten eingebe, ist das Gerät einwandfrei zu erreichen. Mache ich es dann stromlos, sind die WLAN Daten weg aber IP ist noch richtig im Config Screen. Erreichbar ist er dann wieder unter der alten IP.
Sieht so aus als wenn er lediglich seine WLAN-Daten vergisst.
Ich bin nicht der Softwareentwickler, aber mein Tipp lautet:
- Debbugausgabe mit 115200 Baud im seriellen Monitor ansehen
- Firmware ggf. neu flashen
esptool.py --port <port> erase_flash
löscht den kompletten Flash, sowohl die Firmware als auch die Settings.

Zitat von: Markus. am 23 September 2017, 08:24:07
Zum andren komme ich nicht auf das Webinterface, wenn er mit der richtigen IP im WLAN ist. Also kurz nach der Initialconfig.
In FHEM ist er noch nicht definiert.
Welches Webinterface? Die Methode zum Aufruf des WiFiManagers wird hier beschrieben:
https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 24 September 2017, 17:36:53
webinterface = Config page..
Ich gehe mal davon aus das es http://IP-Addresse ist oder? Das heisst dann die IP die ich in der Erstkonfig vergeben habe.
Debug sieht so aus beim Start

*WM: static netmask
*WM: 255.255.255.0
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 192.168.178.4
*WM: Connection result:
*WM: 3
Should save config
connected....
saving config
{
  "ip": "192.168.178.4",
  "gateway": "192.168.178.1",
  "subnet": "255.255.255.0"
}3.3.1-dev SIGNALEsp - compiled at Aug  8 2017 16:30:24
Using sFIFO  Size: 255
Init eeprom to defaults after flash
Write EEPROM Defaults
CCInit
SRES Started
POR Done
Write Defaults done
EEPROM writePatable
CCVersion=20
CCPartnum=0
cc1101 found
Starting timerjob
HTTPUpdateServer ready!
192.168.178.4
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
New client:
CMD: XQ
CMD: V
CMD: XE
CMD: C0DnF


Nach
esptool.py --port /dev/ttyUSB0 erase_flash und neu flashen selbes Problem. Strom raus -> Wifi Konfig weg.
Ich hab mir mal den Arduino Sketch dafür angesehen. Müsste doch gehen die Wifi Daten + IP fest zu hinterlegen ?!?!
Weiß nur nicht wie :-(


Gruß
Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: locutus am 24 September 2017, 22:48:56
Zitat von: Markus. am 24 September 2017, 17:36:53
Nach
esptool.py --port /dev/ttyUSB0 erase_flash und neu flashen selbes Problem. Strom raus -> Wifi Konfig weg.
Ich hab mir mal den Arduino Sketch dafür angesehen. Müsste doch gehen die Wifi Daten + IP fest zu hinterlegen ?!?!
Weiß nur nicht wie :-(
Das klingt so, als wäre Pin D3 permanent mit GND verbunden.
Hast du den ESP8266 ohne das CC1101 Funkmodul oder das Release aus dem SIGNALESP GitHub Repository schon ausprobiert?
Alternativ kannst du auch Tests mit Hilfe der Examples (https://github.com/tzapu/WiFiManager/tree/master/examples) aus dem WiFiManager Repository durchführen.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 25 September 2017, 05:59:01
Hab das jetzt mal ohne CC1101 getestet..selbes Problem.
Werde mal schauen das ich die anderen Tests auch noch mache. Hab leider keinen anderen Wemos hier zum testen.. :-(
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 25 September 2017, 11:48:51
So habe mal verschiedene Sachen getestet ohne CC1101 Modul. Alles klappt soweit einwandfrei wenn die SSID und Passwort im Sketch hinterlegt sind. Wird jedoch selbes über die Config-Seite eingetragen, merkt er sich nur die IP Adresse, Wifi Daten sind dann weg. Irgendwie versteh ich das nicht ganz, aber ich werde mir jetzt mal einen anderen Wemos besorgen und es nochmal testen.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 September 2017, 17:42:10
Hallo Markus,

Von was für einer Konfig Seite redest Du denn?
Die von mir erstellen Firmwares haben keine Konfig Seite für die WLAN Konfiguration.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 25 September 2017, 17:50:14
Hallo Sidey,

Okay dann wäre das ja geklärt. Dachte man könnte die IP z.B. ändern nach der Erstkonfiguration eben über den selben Web-Config-Screen, halt mit der neuen IP als Adresse.
Aber das er die WLAN konfig bei jedem Neustart nach Strom ausschalten macht ist doch nicht normal ? Oder ..?;-)
Kann man in dem IDE Sketch nicht irgendwo die SSID und Passwort und IP config direkt eintragen ?
Weil prinzipiell funktioniert das Modul, halt bis auf diese WLAN-Problematik.

Gruß

Markus


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 September 2017, 20:22:18
Hallo Markus,

Ich kenne auch keinen web config Screen. Tut mir leid.

Die Einrichtung läuft über WPS. Die IP Adresse wird vom DHCP Server bezogen.

Die SSID wird nach der WPS Verbindung dann gespeichert.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 25 September 2017, 20:48:41
Kann es sein das ich die falsche firmware drauf habe/hatte?

https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497 (https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497)
Wenn er neu geflasht wurde, muss man sich doch mit der Ssid des Moduls verbinden. Man wird kommt dann beim starten eines browsers direkt auf die Config-Seite.Dann halt die eigenen Wlandaten eintragen und IP.
Kannst du bitte mal eine richtige bin hier rein posten? Habe ein 433 mhz modul drauf.

Gruss markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 26 September 2017, 06:03:04
Ist das denn hier die richtige Firmware ?

https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin (https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin)

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 26 September 2017, 08:01:38
Die Firmware passt.
Langsam dämmert mir es. Wenn man das mit dem WPS nicht macht, dann gibt es einen fallback und der ESP macht ein eigenes WLan auf.

Leider hat das bei mir nicht funktioniert, so dass ich es nicht testen konnte. Gut möglich, dass da noch etwas fehlt.

Kannst Du die Variante über WPS nicht anwenden?

Gruß Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 26 September 2017, 09:42:52
Doch werde es nachher mit WPS probieren und bescheid geben. ISt nur ein wenig verwirrend mit den Firmware-Versionen hier im Post.
Diese hier macht z.B. direkt ein eigenes WLAN auf
https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497 (https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497)
Die IP die das Modul dann hat ist 192.168.4.1. Öffnet auch direkt die Config page im IE

Folgende Firmware sucht halt 4 oder 5 mal nach WPS und hat dann IP 0.0.0.0. und macht kein eigenes WLAN auf.
https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin (https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin)

Aber wie auch immer, ich werde es heute mal testen mit WPS und berichten. Ich hab nur auf meiner Fritte WPS abgeschaltet da es mit hidden SSIDs nicht geht aber egal dann schaltich das mal ein... :-)

Und viiielen dank noch mal für die Geduld !!! :-)

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FrankieSOC am 26 September 2017, 14:38:52
Hallo zusammen,

habe auch meinen SignalESP über visualmicro geflasht bekommen. Vielen Dank!

Komisch war das er in der Version als V 3.3.1-dev SIGNALESP cc1101 868MHz angezeigt wurde.
Hab dann geschummelt und im Code gespielt. :)switch(cc1101::chipVersion()) {
        case 0x08:  // CC1101_VERSION 0x31
        case 0x14:  // CC1101_VERSION 0xF1
          MSG_PRINT(F(" 433MHz"));


Was ich schade finde, dass wegen dem WLAN WPS Modus man keine feste IP vergeben kann.
In anderen ESP Modulen, aber auch in der Version von Trebron106 gibt es ein Config-Seite, wo man diese Einstellungen vornehmen kann.

Nochmals vielen Dank und Grüße
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 26 September 2017, 17:34:49
Hallo Frank,

wo hast du das denn geändert?
Nachdem ich nun dir richtige Firmware drauf habe, überlebt er auch einen Neustart.
Und klappt eigentlich get ccconf ?

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 26 September 2017, 17:49:44
habs gefunden...
Naja da ich sichergehen wollte, habe ich die bin geflasht..;-)

Aber get ccconf scheint mit dieser Firmware nicht zu gehen oder?
Sduino433/msg READ: Received answer (Unsupported command) for ccconf does not match C0Dn11.*


Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FrankieSOC am 26 September 2017, 19:43:14
Hey Markus,

bin der .bin klappt ccconf leider nicht.

Ich hatte in der .ino Datei nach 433 gesucht und dann wie oben geschrieben angepasst.
Aber selbst ohne die Änderung hatte es geklappt.

Grüße
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 26 September 2017, 19:56:56
mit der .ino klappt aber auch kein ccconf.
Muss man bein 433 Modul noch irgendwas extra einstellen an Atributen oder so?

Hier mal mein list:


Internals:
   CFGFN
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:CUL_FHTTK:SIGNALduino_un:
   DEF        192.168.178.67:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.178.67:23
   FD         19
   LASTDMSG   nothing
   NAME       Sduino433
   NR         49
   PARTIAL
   STATE      opened
   TIME       1506448231
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALESP cc1101 433MHz - compiled at Sep 26 2017 19:45:42
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1506448233.88067
           VALUE      opened
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-09-26 19:53:27   cmds             V R t X F S P C r W x e
     2017-09-26 19:53:58   config          MS=1;MU=1;MC=1
     2017-09-26 19:55:34   ping            OK
     2017-09-26 19:50:33   state           opened
     2017-09-26 19:53:00   version         V 3.3.1-dev SIGNALESP cc1101 433MHz - compiled at Sep 26 2017 19:45:42
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     63
     64
     65
     66
     67
     69
     70
     71
     8
     9
Attributes:
   DbLogExclude .*
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       098_SignalDuino
   verbose    4


Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FrankieSOC am 26 September 2017, 21:38:16
Sieht für mich richtig aus  :o

Ich hatte diese Version genommen und da klappt ccconf. https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101

Ich habe noch diese Atributte gesetzt.

Attributes:
   cc1101_frequency 433.920
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 27 September 2017, 10:33:06
so habe diese Firmware auch mal geflasht jetzt. CCONF funktioniert auch das setzten der Frequenz über set anstatt über das Attribut.
Das komische ist nur das ich nichts empfange. Wenn ich die Firmware von Trebron106 verwende bekomme ich sofort einen Aussentemperaturfühler angezeigt und als device erstellt. Jedoch hat ja diese Firmware bei meinem Wemos das Problem, das nach einem Neustart die WLAN-Konfig weg ist. Verwende ich jedoch die andere Firmware bleibt zwar nach einem Neustart die WLAN-Konfig erhalten dieüber WPS gesetzt wurde, empfange aber den Aussenfühler nicht mehr .... :-(
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Pfriemler am 27 September 2017, 14:12:27
Sacht ma, ich stehe mal wieder völlig auf dem Schlauch. Dutzende von Beiträgen vorher ist von einer Entwicklerversion von 00_SIGNALduino.pm die Rede, aber eine neuere als die 13215 vom 23.1.17 finde ich nicht. Und egal welche SIGNALEsp-Version ich aktuell verwende - es ist weder an ccconf zu kommen noch die Attribute cc1101_frequency" entsprechend zu setzen oder "hardware" (da habe ich nur nano328, Uno oder promini3238 zur Auswahl).

Wo steckt der Fehler?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 27 September 2017, 15:08:50
glaube da musst du die Entwicklerversion verwenden

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

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 27 September 2017, 15:13:21
Zitat von: trebron106 am 08 August 2017, 16:47:05
Hallo Christoph,

als Anlage eine neue Version von SIGNALEsp,

folgende Änderungen sind enthalten:

- bei SIGNALEsp-CC1001 PIN D3 auf Gnd beim Booten AP Einstellungen werden zurück gesetzt und die Config Page gestartet
- bei SIGNALEsp-433MHz PIN D1 auf Gnd beim Booten AP Einstellungen werden zurück gesetzt und die Config Page gestartet

- wenn noch keine IP gesetzt wurde wird grundsätzlich DHCP gemacht
- nach den einmal eine IP vergeben wurde, kann diese auf der Config Page geändert werden
- somit kann eine statische IP eingestellt werden.

- Aufruf der Config Page durch siehe oben

Gruß
Klaus


Würde es nicht Sinn machen, das beste aus beiden FW nehmen und eine daraus machen  ????? ;-)

Funktioniert bei der SIGNAL-ESP Variante nur das IT Protokoll, oder alle anderen auch ???

Gruß
Sascha

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 27 September 2017, 15:17:26
Hallo Pfriemler
Willkommen im Club! Das ist in diesem thread momentan das Problem. Es  gibt zig Versionen von verschiedenen Erstellern. Und jeder User nimmt die Version, die ihm am Besten passt. Anfangs liess sich das nicht kompilieren, dann gab es fertig kompilierte, usw. usw. . Das Problem mit der IP 0.0.0.0 ist auch noch da, und die Rueckfallebene "configpage" geht bei dem offiziellen "branch" auch nicht. Leider bin ich zu unbeleckt, als das ich helfen koennte.
Aber die 00_SIGNALduino, die kann ich dir wohl heute abend schicken, denn das weiss ich, dass ich die habe!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 27 September 2017, 15:18:47
Ach Mist
Da waren zwei schneller! Aber genau damit ist alles gesagt!
Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 27 September 2017, 15:27:55
@sash.sc
Bei der Version habe ich das Problem, das bei Neustart des Moduls nach Strom aus/ein die WLAN Config gelöscht wird.

Mit den anderen Versionen hab ich das Problem das nix empfangen wird... :-(

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 27 September 2017, 15:50:22
Also warten, oder ein ESP8266 mit Nano und CC1101 bauen !! ;-)

Danke

Gruß
Sascha
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 September 2017, 21:26:44
Am besten wäre es, wenn ihr mir mal schreibt, was genau mit der "richtigen" SIGNAL ESP Version nicht geht und warum ihr eine andere Funktionalität benötigt.
Dass DHCP nicht klappt weiss ich, aber ich weiss noch nicht, wieso eine hinterlegte IP Adresse im ESP besser sein soll, als den DHCP Server anzuweisen eine zu vergeben.

Wenn mal klar ist, wie das Einsatzszenario ist, dann kommen wir da bestimmt auch weiter.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Pfriemler am 27 September 2017, 23:41:38
Ja ne ... das mit der Entwicklerversion war's. Warum die jetzt aber einen Versionsstand hat, der weit unter der offiziellen vom Januar 2017 liegt ... ?
Is installiert, Attribute gesetzt, nun schauen wir mal was ankommt. Beide Versionen bei mir hatte ich erfolgreich ins Netz gehievt, das war nicht mein Problem.

DHCP - wenn es denn funktioniert - ist erst mal in Ordnung (mir lieber über Configpage und Eingabe als über WPS), aber eine Festlegung auf eine IP hätte ich schon ganz gern (was aber auch im Nachgang passieren kann, weil es mit vielen anderen Geräten auch nicht anders geht). Ich habe für meine IoT-Sachen einen Bereich abseits des DHCP-Bereichs definiert, was immer den Vorteil hat, dass kein Routerwechsel oder -reset die Erreichbarkeit der (teilweise nur temporär verbundenen - Geräte in Frage stellt. Alles was sich vom DHCP versorgen lässt, kann IPs haben wie es will, das juckt mich dann nicht. 20-99 ist DHCP, 101-120 Multimedia und Drucker, 121-130 Rechner und 131-150 Mobilgeräte, ab 150-199 dürfen sich alle ESP&Co austoben. Das hat sich sehr bewährt und man weiß auch ganz schnell wo man suchen muss.

IP, SSID und Passwort im Code finde ich ehrlich gesagt weniger gut.

Mich treibt im übrigen derzeit um, dass ich meine steinalten Wettersensoren (CUL_WS) ums Verrecken nicht stabil hereinbekomme (die aber gut messen, ewig mit einem Batteriesatz oder solarbetrieben halten). Nahegelegene Sensoren empfängt sogar der 868er CUL, und beide standalone-Wetterempfänger mit Display sowie das alte WS2000-PC-Interface lesen am Rechnerstandort einwandfrei alle 8 Sensoren, auch mit einem NooElec und CubicSDR höre ich alle acht Sensoren einwandfrei. Mit FHEM, zwei unterschiedlichen 433er CULs und nun dem SIGNALEsp lese ich Geräte von diversen weiten Nachbarn, aber die ferneren CUL_WS sind nie und selbst nur wenige Meter entfernte mal im üblichen 3-Minuten-Takt da, dann wieder für Stunden offline. An eine vernünftige Nutzung ist so nicht ansatzweise zu denken. Auch die Versuche mit einem alten original Empfänger und Anschluss über RS232-USB an den Raspi sind regelmäßig havariert. KS300 via SlowRF und CUL868 ist halbwegs stabil (aber auch da gibt es Ausfälle am Tag für bis zu zwei Stunden). Im Moment liefert eigentlich nur Homematic regelmäßig und verlässlich Daten. Aber das kann's doch eigentlich nicht sein. - So, genug geweint...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 28 September 2017, 08:22:27
Hallo Sidey,

ich glaube das Hauptproblem besteht in der Vielfalt der Firmware. Dies macht es für mich als totaler Anfänger auf diesem Gebiet nicht einfach, da bei jeder Firmware irgendetwas anderes ist. Sie es die Signalerkennung oder die Grundkonfiguration. Ich weiß nicht ob ich viel beitragen kann außer halt eine Darstellung was mir aufgefallen ist und was dann nicht funktioniert hat. Es wird bestimmt so sein, das ich schon b.ei der Konfiguration nicht alles richtig gemacht habe und daher die Probleme kamen. Ich vewende einen WemosD1 Mini.
https://forum.fhem.de/index.php/topic,58396.msg646685.html#msg646685 (https://forum.fhem.de/index.php/topic,58396.msg646685.html#msg646685)
Er wurde mit foldender Firmware geliefert. https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497 (https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497).
Diesen habe ich dann wie beschrieben über die Konfigurationsseite, die er nach aufspannen seines eigenen Wlans erreicht, konfiguriert. Halt mit eigener SSID und Password + IP Daten. Die Konfiguration in FHEM erfolgte dann auch Problemlos. Weitere Attribute habe ich erstmal gar nicht gesetzt. Sofort hat er einen Aussentemperaturfühler erkannt und als Device mit Plot angelegt. Da ich die serielle Ausgabe mit verfolgen wollte erstmal, habe ich ihn per USB am Laptop angeschlossen. Bin halt neugierig was da passiert. Als die Temperatur so für eine Stunde mit geloggt wurde über da Modul wollte ich ihn an den Raspi per USB hängen. Nunja dann war er stromlos und nach dem Neustart am Raspi war der Wemos nicht mehr erreichbar. Er hat dann halt wieder sein WLAN aufgespannt und man kam wieder auf die Konfigpage. SSID und Passwort eingeben und es ging wieder. Das Problem konnte ich auch nicht lösen mit einem anderen Wemos, also liegt es an dieser Firmware. Die Firmware habe ich zum einen über die Arduino IDE mit dem .ino file geflasht und zum anderen direkt die .bin über den ESP8266Flasher.
Als nächstes habe ich dann deine original Firmware geflasht als .bin. Mit WPS war direkt die Verbindung zu meinem Wlan da..freu..
Auch ein Neustart (stromlos und wieder ein) funktionierte einwandfrei. Die device Konfig sowie das bereits erstellte Device samt plot und Log für den Aussenfühler habe ich vorher gelöscht. Bei deiner Firmware ist mir dann aufgefallen, das ccconf und so nicht funktioniert. Wäre ja auch nicht weiter schlimm, aber ich habe keine Messages von irgendeinem device mehr erhalten. Hab dann  die Frequenz für das CC1001 433 MHz über das Attribut zu gesetzt. Aber auch nach FHEM Neustart kamen keine Meldungen rein über Stunden. Schlussendlich bin ich dann wieder zurück auf Firmware die ich zuerst drauf hatte. Das komische jetzt ist nu das der Aussentemperaturfühler nicht mehr automatisch angelegt wird samt Plot und Log. Andere 433Mhz Geräte habe ich leider nicht und mehr zu testen, jedenfalls noch nicht.
Also für mich als Anfänger wäre eine konsistente Firmware wichtig die mit gewissen dokumentierten Einstellungen läuft. Das Wiki hilft mir da ehrlich gesagt nicht viel weiter. Das mit der "online-Konfigurierbarkeit" der IP und SSID wäre für mich ein "Nice to have" aber mehr auch nicht, solange der Rest für mich verständlich funktioniert. Beim flashen einer anderen Firmware habe ich auch immer vorher den Speicher gelöscht esptool.py --port <port> erase_flash.
Macht es eventuell Sinn einen eigenen Thread für SignalESP auf zumachen? Glaube das wurde schon mal vorgeschlagen.
Wenn ich in irgendeiner Weise helfen kann mit meinem limitierten Hardwareaustattung und Erfahrung auf diesem Gebiet...gerne..



Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FrankieSOC am 28 September 2017, 10:50:44
Hallo Sidey,

das mit den unterschiedlichen Versionen kann wirklich verwirrend sein.
Zum Schluss habe ich diese Version https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101 genommen und es funktioniert.  :)
Wie schon oben geschrieben wurde zwar mein CC1101 als 868 erkannt, aber kann man ja selbst beheben.

Es gibt ja noch die neuere dev-cc1101-cb, diese hatte bei mir aber nicht geklappt.

Und zum Thema feste IP. Der Vorteil ist, wie schon Pfriemler geschrieben hat, dass man die Geräte clustern kann und so auch besser den Überblick über alle Netzwerkgeräte hat.

Viele Grüße
Frank
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 04 Oktober 2017, 19:05:54
Nabend,

habe einen SignalESP on Loctulus.
nachdem ich diesen nicht dazu bewegen konnte DHCP zu machen habe ich ihn neu geflasht. (https://forum.fhem.de/index.php/topic,58396.msg669497.html#msg669497)

Das Problem:
Er verbindet sich mit dem WLAN, hat aber weiterhin die 10.x.x.x IP Adresse und macht kein DHCP.

Habe vor dem Flashen den Wemos gelöscht. http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers

Wie bekomme ich den denn auf DHCP?
welche Zeilen der ino muss ich wie anpassen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 04 Oktober 2017, 19:30:09
Also ich nutze immer noch die Version vom 6. Juni und konnte bisher noch keine Probleme feststellen.

https://forum.fhem.de/index.php/topic,58396.msg644583.html#msg644583

Kommt aber natürlich immer drauf an, was für Protokolle du verwenden möchtest.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Oktober 2017, 19:34:09
Hallo Frank,

SignalESP on Loctulus sagt mir nichts.
Was genau soll das sein?

Was die aktuelle compilieren Version angeht, die startet WPS nach dem booten.
Wenn via WPS eine Verbindung hergestellt wurde, wird eine IP Adresse über DHCP bezogen.


Ich bin auch gerade am Entwickeln, damit auch statische IP Adressen gesetzt werden können.
Da wird der Ablauf etwas anders sein:
ESP Bootet und startet einen eigenen AP über den er konfiguriert werden kann.
Verbindet sich kein Endgerät innerhalb von 60 Sekunden wird versucht mit einer hinterlegten SSID eine Verbindung herzustellen.
Kommt keine Verbindung zustande, dann wird WPS ausprobiert.

Aktuell habe ich den Wechsel DHCP zu statischer IP noch nicht implementiert.

Gesendet von meinem XT1650 mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 04 Oktober 2017, 19:47:06
Zitat von: gloob am 04 Oktober 2017, 19:30:09
Also ich nutze immer noch die Version vom 6. Juni und konnte bisher noch keine Probleme feststellen.

https://forum.fhem.de/index.php/topic,58396.msg644583.html#msg644583

Kommt aber natürlich immer drauf an, was für Protokolle du verwenden möchtest.
Danke,
Dann werd ich die auch mal versuchen.

Gesendet von meinem S3_32 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 04 Oktober 2017, 19:55:56
Zitat von: Sidey am 04 Oktober 2017, 19:34:09
Hallo Frank,

SignalESP on Loctulus sagt mir nichts.
Was genau soll das sein?

Was die aktuelle compilieren Version angeht, die startet WPS nach dem booten.
Wenn via WPS eine Verbindung hergestellt wurde, wird eine IP Adresse über DHCP bezogen.


Ich bin auch gerade am Entwickeln, damit auch statische IP Adressen gesetzt werden können.
Da wird der Ablauf etwas anders sein:
ESP Bootet und startet einen eigenen AP über den er konfiguriert werden kann.
Verbindet sich kein Endgerät innerhalb von 60 Sekunden wird versucht mit einer hinterlegten SSID eine Verbindung herzustellen.
Kommt keine Verbindung zustande, dann wird WPS ausprobiert.

Aktuell habe ich den Wechsel DHCP zu statischer IP noch nicht implementiert.

Gesendet von meinem XT1650 mit Tapatalk
Der hier:
https://forum.fhem.de/index.php/topic,76769.0.html

Aah, an wps hatte ich nicht gedacht.
Der esp hat seinen AP aufgespannt und  darüber hab ich das wlan konfiguriert.

Werde wps mall noch testen.

Also nochmal löschen, dann flashen und vor dem ersten Boot am Router wps starten?


Gesendet von meinem S3_32 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 04 Oktober 2017, 21:02:39
mit WPS passiert schonmal leider nichts.
Hab ihn nochmal gelöscht und geflasht mit der unten verlinkten Firmware.


So, mit dieser Firmware hat WPS funktioniert:
Zitat von: Markus. am 26 September 2017, 06:03:04
https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin (https://github.com/RFD-FHEM/SIGNALESP/releases/download/release3.3.1a_devmc/SIGNALESP.bin)

Gibt es denn irgendwo eine Übersicht der verschiedenen Firmware Versionen?
im Forum wird mal nicht schlau...
welches ist denn die aktuellste für Wemos/CC1101 433? die die ich jetzt hab?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Oktober 2017, 22:04:15
Zitat von: Frank_Huber am 04 Oktober 2017, 21:02:39
Gibt es denn irgendwo eine Übersicht der verschiedenen Firmware Versionen?
im Forum wird mal nicht schlau...
welches ist denn die aktuellste für Wemos/CC1101 433? die die ich jetzt hab?

Die vom 28 Aug, ist die, welche ich zuletzt compiliert habe. In so fern, ist das die aktuellste. Was hier im Forum schon als Anhang hinterlegt wurde, keine Ahnung. Das hat mich auch nicht viel weiter gebracht.

Der Aktuelle Stand vom code befindet sich im Branch dev-cc1101-cb, da gibt es aber noch ein paar Dinge zu tun.

Das ganze SIGNALesp Projekt ist halt leider noch nicht wirklich fertig. Es ging jetzt die letzten Tage ein gutes Stück voran, aber eine vollständig funktionierende Version gibt es leider noch nicht.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 05 Oktober 2017, 08:22:20
Danke Sidey!
Das ganze ist also quasi noch BETA Status. Das war mir so nicht bewusst.
Hab ihn jetzt auf jeden Fall mal im Netz und werd ja jetzt sehen ob er was empfängt. :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 Oktober 2017, 11:15:09
Zitat von: Sidey am 04 Oktober 2017, 22:04:15
Die vom 28 Aug, ist die, welche ich zuletzt compiliert habe.
Leider sind in diesem Compilat nicht die Änderungen aus den CherryPicks enthalten (was geht nicht?: ccconf; Schreiben ins EEPROM).

bzgl. Agilität der Entwicklung bin ich etwas enttäuscht!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 05 Oktober 2017, 13:47:22
@habeIchVergessen
Das finde ich eine ganz schoen scharfe Aeusserung! Sidey hat meines Wissens nach noch diverse andere Baustellen. Und wenn es Dir nicht schnell genug geht, dann solltest Du es vielleicht selbst voranbringen!? Das ist hier nur Hobby!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 05 Oktober 2017, 18:10:45
So, nach Reboot connected er nichtmehr. auch nicht per WPS.
Ich versuche mal noch die Version die gloob empfohlen hat, ansonsten geht er erstmal in die Kiste.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Burny4600 am 09 Oktober 2017, 20:54:44
Ich bin auf der Suche nach der Firmware des SIGNALDuino mit einem CC1101 Transceiver.
Das Ganze ist ein wenig verwirrend, da einmal beschrieben wird das dieser CC1101 Transceiver nicht geignet ist und unter FHEM Wiki es sehr wohl funktionieren soll.
Gibt es eine funktionsfähige Anweisung?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 09 Oktober 2017, 21:16:32
Hi,
Ja im Wiki!
https://wiki.fhem.de/wiki/SIGNALduino

Einfach die nanoCUL Hardware nehmen und dann die Entwickler Modulversion laden und die Signalduino FW für
attr SDuino model nanoCC1101
flashen...
Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Burny4600 am 10 Oktober 2017, 13:36:12
Danke für die Info.
Es funktioniert mit diesem Transceiver.

Lässt sich die LED wie beim nanCul auch irgendwie einschalten?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 13 Oktober 2017, 13:23:30
Welche Firmware sollte man denn nun verwenden für einen SignalESP basierend auf einem Wemos wenn man die  Änderungen aus den CherryPicks implentiert haben will? Mir ist es im Moment echt mal egal ob ich die WifiDaten nach jedem Neustart neu eintragen muss.


Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 13 Oktober 2017, 13:25:55
Zitat von: Frank_Huber am 05 Oktober 2017, 18:10:45
So, nach Reboot connected er nichtmehr. auch nicht per WPS.
Ich versuche mal noch die Version die gloob empfohlen hat, ansonsten geht er erstmal in die Kiste.
So, ich antworte mir mal selbst.
Wenn man wie im Wiki beschrieben das richtige Modul läd und auch genügend Strom liefert läuft der SignalESP auch stabil.
Der SignalESP benötigt wohl beim booten etwas mehr Strom...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Frank_Huber am 13 Oktober 2017, 13:28:10
Zitat von: Markus. am 13 Oktober 2017, 13:23:30
Welche Firmware sollte man denn nun verwenden für einen SignalESP basierend auf einem Wemos wenn man die  Änderungen aus den CherryPicks implentiert haben will? Mir ist es im Moment echt mal egal ob ich die WifiDaten nach jedem Neustart neu eintragen muss.
Auf Empfehlung von Gloob läuft bei mir diese jetzt stabil:
https://forum.fhem.de/index.php/topic,58396.msg644583.html#msg644583
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 13 Oktober 2017, 17:57:35
Zitat von: Markus. am 13 Oktober 2017, 13:23:30
Welche Firmware sollte man denn nun verwenden für einen SignalESP basierend auf einem Wemos wenn man die  Änderungen aus den CherryPicks implentiert haben will?
Sourcen müssen jeweils kompilieren werden.

branch dev-cc1101  (sidey's letzter Stand) (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101)

branch dev-cc1101-cb (mein letzter Stand mit Callback+Schreibpuffer) (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 15 Oktober 2017, 10:36:04
Funktioniert diese Firmware denn auch mit dem Signalduino Modul aus dem Dev Repository?
Welche Attribute müssen denn gesetzt werden? Irgendwie empfange ich garnichts mit einem 433 Signalesp...

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 15 Oktober 2017, 17:34:44
Zitat von: Markus. am 15 Oktober 2017, 10:36:04
Signalduino Modul aus dem Dev Repository
hast du einen Link?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 15 Oktober 2017, 18:13:09
Ich hab die Updates für das Modul von hier eingestellt....

https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt (https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt)

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 15 Oktober 2017, 18:52:30
sofern aktuell keine Probleme in der Entwicklerversion bekannt sind, sollte das funktionieren.

was steht den in der seriellen Konsole, wenn ein Reset am WeMos ausgelöst wird?
Was liefert get ccconf?


fhem> version SIGNALduino
File              Rev   Last Change

00_SIGNALduino.pm 10488 2017-10-02 21:00:00Z v3.3.1-dev
fhem> get signalESP ccconf
fhem>
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)


mein alter sduino (ohne cc1101 und mit alter Firmware) verarbeitet Nachrichten ohne Probleme.
Lediglich die Nachrichten von signalESP werden scheinbar "nur" empfangen  und nicht verarbeitet.
habe ein bugfix für die RSSI-Werte hochgeladen (Nachrichtenverarbeitung endete mit einem Formatfehler).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 17 Oktober 2017, 05:50:09
hallo Habichvergessen,

Der ESP ist im Moment nicht angeschlossen aber trotzdem mal die Infos die ich soweit habe
also folgende Infos kommen dann..

File              Rev   Last Change

00_SIGNALduino.pm 10488 2017-10-02 21:00:00Z v3.3.1-dev

fhemweb.js                 15228 2017-10-10 17:34:56Z rudolfkoenig


List vom ESPDuino

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:SIGNALduino_un:
   DEF        192.168.178.67:23
   DMSG       nothing
   DevState   disconnected
   DeviceName 192.168.178.67:23
   LASTDMSG   nothing
   NAME       Sduino433
   NEXT_OPEN  1508212097
   NR         35
   PARTIAL
   STATE      disconnected
   TIME       1507979631
   TYPE       SIGNALduino
   disConnFlag 1
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   READINGS:
     2017-10-13 19:38:44   ccconf          freq:443.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-09-27 18:14:18   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2017-09-27 18:14:10   cmds            V R t X F S P C r W x e b
     2017-10-13 19:31:42   config          MS=1;MU=1;MC=1
     2017-10-14 11:07:25   ping            OK
     2017-10-13 18:51:13   raw             ccFactoryReset done
     2017-10-17 05:47:17   state           disconnected
     2017-09-28 06:39:10   uptime          0 12:32:07
     2017-10-14 09:52:25   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Oct 13 2017 18:40:45
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     8
     9
Attributes:
   DbLogExclude .*
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   room       098_SignalDuino
   verbose    4

Und CCCONF

freq:443.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)


Mit der Meldung beim reset muss ich nochmal schauen.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 17 Oktober 2017, 07:55:09
Habe jetzt mal diese hier geflasht...
https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)

Ein eigenes WLAN macht der aber nicht auf, so das ich erst heute Abend mit WPS testen kann. Aber im Startup-Log sieht man folgendes...


Reading values fom eeprom

dump EEPROM:
33 1d 07 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
11 12 e7 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found (rev. 01)

Try connecting to WiFi with SSID ''

Could not connect to WiFi. state='0'
Please press WPS button on your router
WPS config start
Failed to connect with WPS :-(

Ready! Use 'telnet 0.0.0.0 port 23' to connect
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: NodeDuino
*WM: AP IP address:
*WM: 0.0.0.0
*WM: HTTP server started



Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 17 Oktober 2017, 19:00:06
Also folgendes sehe ich in der Konsole nach der Konfiguration:

c▒l▒l▒▒▒d▒l`▒▒g▒▒


Reading values fom eeprom

dump EEPROM:
33 1d 07 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found (rev. 01)

Try connecting to WiFi with SSID 'MeineSSID'
..
Connected successful to SSID 'MeineSSID'
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:
*WM: 192.168.178.67
connected...)
local ip
192.168.178.67
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled
New client: 192.168.178.38


Was komisch war, kurz nach der WLAN Konfig und der Verbindung zum Server konnte ich in der Konsole jede Menge MU Messages sehen. Waren zwar mit komischen Zeichen, aber war ganz schön was los in der Konsole. Dann habe ich ein "get CCCONF" gemacht und anschliessend ein "get raw e" dann war nix mehr an irgendwelchen Messages zu sehen. Konnte da nur den doofen Log nicht kopieren.

Kann man eigentlich beim Wemos auch über die IDE ein erase_flash machen? 


Gruß
Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 17 Oktober 2017, 19:56:24
Über die ide weiß ich nicht. Klappt aber mit dem esp Flash Tool. Wurde hier aber, glaube ich, auch schon beschrieben.

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 18 Oktober 2017, 07:51:03
Kann die SignalESP Version eigentlich auch IT empfangen?
Gibt es irgendwo eine Übersicht welche Protokolle mit dem SignalESP mit 433MHz möglich sind?


Wird es wieder eine Firmware geben, die ohne WPS funktioniert. Mein Router unterstütz kein WPS.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 18 Oktober 2017, 09:54:30
433MHz: ITv1 und SOMFY (Freq. muss geändert werden) funktionieren bei mir
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 18 Oktober 2017, 09:55:10
Und itv3?

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 18 Oktober 2017, 22:10:43
scheinbar ja. Habe allerdings mit einem herkömmlichen SIGNALduino (ohne CC1101) gesendet, da keine passende Hardware vorhanden.

set sduino sendMsg P17#00111011010100110100101110010000#R6#C420

signalESP/msg READredu: MS;P0=-32001;P1=427;P2=-4204;P3=-421;P4=-2099;D=01213141314141314131413131414131413131414131314141313141314141314131314141313141314141313141413141314131314131414131314131413141314;CP=1;SP=2;R=227;O;m=;
signalESP: Matched MS Protocol id 17 -> arctech
signalESP: Decoded MS Protocol id 17 dmsg i5A9A665A659A965500 length 64 RSSI = -88.5
signalESP IT: message "i5A9A665A659A965500" (19)
signalESP ITv3dimm: bin message "010110101001101001100110010110100110010110011010100101100101010100000000" (72)
signalESP IT: msgcode "00111011010100110100101110010000DDDD" (36) bin = 010110101001101001100110010110100110010110011010100101100101010100000000
signalESP IT: IT_V3_1da9a5c0 (0011101101010011010010111000000) not defined (Address: 00111011010100110100101110 Group: 0 Unit: 0000 Switch code: 1)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 01 November 2017, 07:05:33
gibt's eigentlich irgendwas neues in Bezug auf SignalESP?
Habe das Teil mal wieder nervorgeholt zum spielen.
Bekomme zeitweise folgende Einträge im Log bei MS Messages.

017.10.25 22:17:11 1: PERL WARNING: substr outside of string at ./FHEM/00_SIGNALduino.pm line 2552.
2017.10.25 22:17:11 1: PERL WARNING: Use of uninitialized value $m1 in pattern match (m//) at ./FHEM/00_SIGNALduino.pm line 2591.
2017.10.25 22:17:11 4: Sduino433/msg READredu: MS;P0=;P2=;P3=;P4=;P5=;P6=;D=5363432343234323432323432343432323434323234323432343234343232343230323432343234323032343432323432303234343232343432323432343234323435;CP=3;SP=6;R=247;O;
2017.10.25 22:17:11 4: Sduino433/msg READredu: MS;P0=;P1=;P2=;P4=;P5=;D=4151012101210121012121012101012121010121210121012101210101212101210121012101210121012101012121012101210101212101012121012101210121014;CP=1;SP=5;R=246;O;
2017.10.25 22:17:11 4: Sduino433/keepalive ok, retry = 0


Demudoliert wird nichts, auch kein Gerät angelegt. Der Signalduinofehler kommt nicht bei jeder MS Message.

Sduino433/KeepAlive not ok, retry = 1 -> get ping
2017.10.26 18:23:17 4: Sduino433/msg READ: OK
2017.10.26 18:23:17 4: Sduino433/HandleWriteQueue: nothing to send, stopping timer
2017.10.26 18:24:17 4: Sduino433/keepalive ok, retry = 0
2017.10.26 18:25:12 4: Sduino433/msg READredu: MS;P0=;P1=;P2=;P3=;P5=;D=2151012131213121312131312131212131312121313121312131213121213131213121312131213121312131212131312131213121213131213121312131213121312;CP=1;SP=5;R=247;O;m=;
2017.10.26 18:25:12 4: Sduino433/msg READredu: MU;P0=;P1=;P2=;P3=;P5=;D=151012131213121312131312131212131312121313121312131213121213131213121312131213121312131212131312131213121213131213121312131213121310;CP=1;R=247;
2017.10.26 18:25:12 4: Sduino433/msg READredu: MS;P0=;P1=;P2=;P4=;P5=;D=2141015101510151015151015101015151010151510151015101510101515101510151015101510151015101015151015101510101515101510151015101510151012;CP=1;SP=4;R=246;O;m=;
2017.10.26 18:25:12 4: Sduino433/msg READredu: MS;P0=;P1=;P4=;P5=;D=141015101510151015151015101015151010151510151015101510101515101510151015101510151015101015151015101510101515101510151015101510151012;CP=1;SP=4;R=246;
2017.10.26 18:25:17 4: Sduino433/keepalive ok, retry = 0
2017.10.26 18:26:17 4: Sduino433/KeepAlive not ok, retry = 1 -> get ping
2017.10.26 18:26:17 4: Sduino433/msg READ: OK
2017.10.26 18:26:17 4: Sduino433/HandleWriteQueue: nothing to send, stopping timer
2017.10.26 18:27:17 4: Sduino433/keepalive ok, retry = 0
2017.10.26 18:28:17 4: Sduino433/KeepAlive not ok, retry = 1 -> get ping


Aber wie gesagt, er empfängt was und das war es dann.. :-(
Hier die Version verwende ich:


File              Rev   Last Change

00_SIGNALduino.pm 10488 2017-10-02 21:00:00Z v3.3.1-dev

fhemweb.js                 15228 2017-10-10 17:34:56Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968



Und mal ein list meines devices, vielleicht fehlt ja noch eine Einstellung

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:SIGNALduino_un:
   DEF        192.168.178.67:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.178.67:23
   FD         13
   LASTDMSG   nothing
   NAME       Sduino433
   NR         43
   PARTIAL
   STATE      opened
   TIME       1509470802
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Oct 18 2017 10:48:04
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-10-31 20:53:45   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2017-10-19 18:04:29   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2017-10-19 18:04:36   cmds            V R t X F S P C r W x e
     2017-10-31 20:54:28   config          MS=1;MU=1;MC=1
     2017-10-17 19:25:36   freeram         40920
     2017-11-01 07:02:05   ping            OK
     2017-10-19 16:39:43   raw             ccFactoryReset done
     2017-10-31 18:27:02   state           opened
     2017-10-21 05:30:02   uptime          1 12:18:43
     2017-10-31 20:54:04   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Oct 18 2017 10:48:04
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     34
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     8
     9
Attributes:
   DbLogExclude .*
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   room       098_SignalDuino
   verbose    4


Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 01 November 2017, 18:24:32
P[0-8]= ist immer leer.
Bitte die Quellen aktualisieren und neu bauen. Da hatte ich einen Bug eingebaut.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 01 November 2017, 18:55:59
hallo Habichvergessen,

das heisst neu flashen?
Kannst du nochmal den link posten, nur um sicher zu gehen das ich die richte nehme...

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 01 November 2017, 19:47:20
ist es die hier?

https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 01 November 2017, 20:03:47
Ja. branch dev-cc1101-cb
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 03 November 2017, 07:58:58
Hi,

Der SignalESP soll das gleiche wie der Signalduino können.

Da aktuell ein paar Fehler im Signalduino ausgemerzt werden habe ich für den SignalESP keine Zeit.

Wenn das mit dem Signalduino soweit läuft, dann werde ich mich auch wieder um den ESP kümmern.
Glücklicherweise gibt es jetzt endlich eine neue Version der ESP Lib, die einen Fehler im IP Stack behebt. :)

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 04 November 2017, 20:13:27
Aktuell hab ich ein seltsames Problem mit intertechno V3  bei einem It1500 dreierset.
https://forum.fhem.de/index.php/topic,79019.0.html (https://forum.fhem.de/index.php/topic,79019.0.html)
Die Fernbedienung hat drei Tastenpaare. Alles klappt soweit gut auch die Rwichweite. Aber alle steckdosen die ich auf dem zweiten Tastenpaar anlerne funktionieren nciht richtig. Lerne ich die steckdosen mit dem code von tastenpaar 1 oder 3 an klapt alles klasse.
Kann das Phänomen vom Signalesp kommen eventuell?

Gruss

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 05 November 2017, 08:09:05
glaube habe da ein Problem gefunden wenn man IT V3 verwendet.
Und zwar habe ich ja wie in oben erwähnten Thread 3 das IT 1500 3er set mit FB. Und das Problem wenn ein Stecker auf Platz 2 angelernt wird. Die Code Kombi bei den drei Steckern + All off sieht folgender Massen aus.


0101011001010000010111111010000 Stecker Alle
0101011001010000010111111000000 Stecker 1
0101011001010000010111111000001 Stecker 2 <- Fehler letzte 1 wird verschluckt
0101011001010000010111111000010 Stecker 3

Ich kann  machen was ich will, jedesmal wenn ein Stecker auf Platz 2 angelernt wird, schaltet er nur ab und zu mal.
Für mich sieht es im Moment so aus, als wenn etwas beim senden "verschluckt" wird. Und zwar wenn die 1 für die Tasten-Kombi an letzter stelle steht.
Wenn ich den Code für Stecker 2 auf 0101011001010000010111111000100 ändere funktioniert alles einwndrei. Es darf also keine 1 am Ende stehen.
@habichvergessen....was kann ich denn da ändern
Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 November 2017, 11:30:48
Kann die FB mit 100 am Ende umgehen? Wenn ja, dann hast du eine temp. Lösung.

Das Problem beim Senden ist eher was für Sidey und Ralf9.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 05 November 2017, 11:47:42
nee die Fernbedienung rafft das ja nicht weil ja nur 3 Tastenpaare vorhanden sind und ich denke den Code der FB kann man ja nicht ändern. Über FHEM läuft es natürlich jetzt. Die Steckdosen 1 und 3 kann ich ja schalten über die FB nur halt 2 nicht wegen 1 im Code am ende.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 05 November 2017, 14:04:28
Hi,
Workaround:
Dann leg doch in fhem ein viertes Device an inkl. Notify auf Device zwei. Wenn die FB Device zwei schaltet, dann sendet FHEM Device vier den Befehl und die Physische Dose schaltet.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 05 November 2017, 15:10:33
gute Idee, werds nachher mal versuchen... Danke dir.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: edge am 05 November 2017, 16:33:25
Moin zusammen,

mein SIGNALduino bietet mir nach einem "update all" und anschließendem flashen kein "get ccconf" oder "cc1101_freq" mehr an. Wenn ich die Befehle versuche per "set sduino cc1101_freq 433.92" zu setzen, bekomme ich nur ein "Unknown argument cc1101_freq".

version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

Hat jemand eine Idee? Die Forumsuche hat mir erstmal nicht weitergeholfen (außer, dass der ein oder andere auch schon mal das Problem hatte)

Viele Grüße

[Update 05.11.2017: 16:48 Uhr]
nach einem
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
habe ich die Funktion nun und konnte erfolgreich auf 433.92 Mhz umstellen:
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Leider werden beim drücken der Tasten die Devices werden nicht angelegt (autocreate ist active).

Beispiel "on" Taste:
2017.11.05 16:53:17 4: sduino/msg READ: MS;P1=281;P2=-1051;P4=965;P5=-398;P6=-10394;D=16121212121245121212451212124512451245124512121245;CP=1;SP=6;R=87;O;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i044551 length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i044551" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0F0FFFF0F" (12) bin = 000001000100010101010001
2017.11.05 16:53:17 4: sduino IT: 00F0F0FFFF not defined (Switch code: 0F)
2017.11.05 16:53:17 4: sduino/msg READ: MS;P0=-1068;P1=272;P2=956;P3=-411;P4=-10314;D=14101010101023101010231023102310231023102323232323;CP=1;SP=4;R=87;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 25 -> les led remote
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i04555F length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i04555F" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0FFFFFF11" (12) bin = 000001000101010101011111
2017.11.05 16:53:17 4: sduino IT: 00F0FFFFFF not defined (Switch code: 11)
2017.11.05 16:53:19 4: sduino/keepalive ok, retry = 0


Beispiel "off" Taste:
2017.11.05 16:53:17 4: sduino/msg READ: MS;P1=281;P2=-1051;P4=965;P5=-398;P6=-10394;D=16121212121245121212451212124512451245124512121245;CP=1;SP=6;R=87;O;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i044551 length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i044551" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0F0FFFF0F" (12) bin = 000001000100010101010001
2017.11.05 16:53:17 4: sduino IT: 00F0F0FFFF not defined (Switch code: 0F)
2017.11.05 16:53:17 4: sduino/msg READ: MS;P0=-1068;P1=272;P2=956;P3=-411;P4=-10314;D=14101010101023101010231023102310231023102323232323;CP=1;SP=4;R=87;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 25 -> les led remote
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i04555F length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i04555F" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0FFFFFF11" (12) bin = 000001000101010101011111
2017.11.05 16:53:17 4: sduino IT: 00F0FFFFFF not defined (Switch code: 11)
2017.11.05 16:53:19 4: sduino/keepalive ok, retry = 0


Beispiel mehrmals gedrückt:
2017.11.05 16:53:17 4: sduino/msg READ: MS;P1=281;P2=-1051;P4=965;P5=-398;P6=-10394;D=16121212121245121212451212124512451245124512121245;CP=1;SP=6;R=87;O;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i044551 length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i044551" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0F0FFFF0F" (12) bin = 000001000100010101010001
2017.11.05 16:53:17 4: sduino IT: 00F0F0FFFF not defined (Switch code: 0F)
2017.11.05 16:53:17 4: sduino/msg READ: MS;P0=-1068;P1=272;P2=956;P3=-411;P4=-10314;D=14101010101023101010231023102310231023102323232323;CP=1;SP=4;R=87;
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 25 -> les led remote
2017.11.05 16:53:17 4: sduino: Matched MS Protocol id 3.1 -> itv1_sync40
2017.11.05 16:53:17 4: sduino: Decoded MS Protocol id 3.1 dmsg i04555F length 24 RSSI = -30.5
2017.11.05 16:53:17 4: sduino IT: message "i04555F" (7)
2017.11.05 16:53:17 4: sduino IT: msgcode "00F0FFFFFF11" (12) bin = 000001000101010101011111
2017.11.05 16:53:17 4: sduino IT: 00F0FFFFFF not defined (Switch code: 11)
2017.11.05 16:53:19 4: sduino/keepalive ok, retry = 0


[Update 05.11.2017 17:07 Uhr]
Das an- und ausschalten der Steckdose per raw send geht:
An: set sduino sendMsg P3#00F0F0FFFF0F#R4
Aus: set sduino sendMsg P3#00F0F0FFFFF0#R4


[Update 05.11.2017 18:08 Uhr]
Nun funktioniert alles. Habe die Fernbedienung direkt an die Antenne gehalten und so lange on und off (mit Pausen zwischen den Schaltvorgängen) gedrückt, bis autocreate erfolgreich gelaufen ist. Mag sein, dass die Batterie etwas geschwächelt hat.

Hat jemand eine Idee?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 05 November 2017, 17:42:55
@Arnd.. Danke für den Tip funktioniert so nund auch mit der FB

@edge.. Das hatte ich nur malweil ich zwei Signalduinos verwende eins auf 433 und eins auf 868.Das anlernen hat einwandfrei funktioniert. Aber irgendwie hat autocreate mein 433 device auf IODEV 868 verlinkt. Hab das dann geändert und dann klappte alles.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 18 November 2017, 10:39:45
Hier ist eine vorausschau auf die neue V 3.3.2-dev firmware. Ich und Sidey haben einige Fehler beseitigt und einiges optimiert. Sidey hat im ManchesterDecoder Fehler beseigt und optimiert. Der Hideki Empfang hat sich deutich verbessert. Die anderen Manchester Sensoren wurden noch nicht alle getestet.
Hier ist ein log von ca 1 Stunde von 2 Hideki Sensoren mit einem RSSI von ca -65 und ca -69:

freq:433.920MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

2017.11.17 23:00:06.239 3 : sduinoE 12.1, MC;LL=-1034;LH=917;SL=-545;SH=434;D=571B0BA52663F5668A358A0;C=488;L=91;R=10; RSSI=-69
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:00:06.243 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:01:44.082 3 : sduinoE 12.1, MC;LL=-1024;LH=937;SL=-520;SH=452;D=57058BA527A3F5D88A3B120;C=488;L=91;R=18; RSSI=-65
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:01:44.084 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:02:20.881 3 : sduinoE 12.1, MC;LL=-1029;LH=922;SL=-538;SH=432;D=571B0BA53663F5668A35070;C=486;L=91;R=10; RSSI=-69
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:02:20.884 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:02:21.171 3 : sduinoE 12.1, MC;LL=-1007;LH=952;SL=-533;SH=437;D=571B0BA52663F5668A358A0;C=488;L=91;R=10; RSSI=-69
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:02:21.173 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:02:33.079 3 : sduinoE 12.1, MC;LL=-1022;LH=923;SL=-543;SH=439;D=AE0B174A4F47EBB11476240;C=487;L=90;R=19; RSSI=-64.5
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:02:33.081 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:03:06.177 3 : sduinoE 12.1, MC;LL=-1023;LH=937;SL=-527;SH=456;D=571B0BA52663F5668A358A0;C=490;L=91;R=10; RSSI=-69
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:03:06.179 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:03:21.947 3 : sduinoE 12.1, MC;LL=-1004;LH=946;SL=-532;SH=439;D=57058BA517A3F5D88A3A880;C=486;L=91;R=18; RSSI=-65
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:03:21.949 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:03:51.045 3 : sduinoE 12.1, MC;LL=-1033;LH=922;SL=-537;SH=441;D=571B0BA51663F5668A34100;C=488;L=91;R=10; RSSI=-69
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:03:51.052 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:04:10.805 3 : sduinoE 12.1, MC;LL=-1033;LH=931;SL=-533;SH=440;D=AE0B174A6F47EBB114773E0;C=489;L=90;R=19; RSSI=-64.5
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:04:10.807 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:04:11.114 3 : sduinoE 12.1, MC;LL=-1019;LH=925;SL=-532;SH=443;D=AE0B174A4F47EBB11476240;C=486;L=90;R=19; RSSI=-64.5
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:04:11.116 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:04:35.917 3 : sduinoE 12.1, MC;LL=-1032;LH=931;SL=-534;SH=436;D=AE36174A6CC7EACD146A0E0;C=488;L=90;R=11; RSSI=-68.5
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:04:35.920 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:04:36.225 3 : sduinoE 12.1, MC;LL=-1014;LH=935;SL=-528;SH=446;D=571B0BA52663F5668A358A0;C=487;L=91;R=11; RSSI=-68.5
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:04:36.228 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:05:00.109 3 : sduinoE 12.1, MC;LL=-1015;LH=950;SL=-531;SH=447;D=57058BA527A3F5D88A3B120;C=490;L=91;R=16; RSSI=-66
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:05:00.112 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:05:20.912 3 : sduinoE 12.1, MC;LL=-1036;LH=918;SL=-544;SH=426;D=AE36174A6CC7EACD146A0E0;C=487;L=90;R=11; RSSI=-68.5
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:05:20.920 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:05:21.064 3 : sduinoE 12.1, MC;LL=-1022;LH=929;SL=-544;SH=434;D=571B0BA51663F5668A34100;C=488;L=91;R=11; RSSI=-68.5
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:05:21.066 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:05:48.825 3 : sduinoE 12.1, MC;LL=-1026;LH=932;SL=-518;SH=448;D=AE0B174A6F47EBB114773E0;C=487;L=90;R=19; RSSI=-64.5
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:05:48.833 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:06:05.931 3 : sduinoE 12.1, MC;LL=-1026;LH=913;SL=-540;SH=435;D=571B0BA53663F5668A35070;C=485;L=91;R=12; RSSI=-68
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:06:05.939 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:06:06.250 3 : sduinoE 12, MC;LL=-1031;LH=918;SL=-549;SH=433;D=A8E4F45AD99C0A9975CA75E;C=488;L=91;R=11; RSSI=-68.5
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:06:06.253 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:07:26.827 3 : sduinoE 12.1, MC;LL=-1030;LH=925;SL=-538;SH=437;D=AE0B174A6F47EBB114773E0;C=488;L=90;R=18; RSSI=-65
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:07:26.830 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:08:20.942 3 : sduinoE 12.1, MC;LL=-1027;LH=927;SL=-534;SH=450;D=AE36174A6CC7EACD146A0E0;C=489;L=90;R=14; RSSI=-67
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:08:20.949 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:05.086 3 : sduinoE 12.1, MC;LL=-1031;LH=925;SL=-546;SH=424;D=57058BA527A3F5D88A3B120;C=487;L=91;R=18; RSSI=-65
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:09:05.088 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:05.887 3 : sduinoE 12.1, MC;LL=-1027;LH=922;SL=-534;SH=441;D=AE36174A6CC7EACD146A0E0;C=487;L=90;R=10; RSSI=-69
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:09:05.891 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:06.027 3 : sduinoE 12.1, MC;LL=-1016;LH=924;SL=-536;SH=441;D=AE36174A2CC7EACD1468200;C=486;L=90;R=11; RSSI=-68.5
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:09:06.029 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:06.179 3 : sduinoE 12.1, MC;LL=-1029;LH=925;SL=-551;SH=427;D=571B0BA52663F5668A358A0;C=488;L=91;R=11; RSSI=-68.5
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:09:06.181 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:50.902 3 : sduinoE 12.1, MC;LL=-1044;LH=908;SL=-557;SH=423;D=571B0BA53663F5668A35070;C=488;L=91;R=10; RSSI=-69
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:09:50.910 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:51.202 3 : sduinoE 12.1, MC;LL=-1032;LH=920;SL=-550;SH=431;D=AE36174A4CC7EACD146B140;C=488;L=90;R=10; RSSI=-69
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:09:51.205 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:09:53.934 3 : sduinoE 12.1, MC;LL=-1040;LH=910;SL=-533;SH=443;D=57058BA517A3F5D88A3A880;C=487;L=91;R=18; RSSI=-65
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:09:53.941 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:10:36.055 3 : sduinoE 12.1, MC;LL=-1013;LH=934;SL=-521;SH=451;D=571B0BA51663F5668A34100;C=486;L=91;R=10; RSSI=-69
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:10:36.060 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:10:43.126 3 : sduinoE 12.1, MC;LL=-1027;LH=919;SL=-544;SH=435;D=57058BA527A3F5D88A3B120;C=487;L=91;R=19; RSSI=-64.5
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:10:43.132 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:11:20.927 3 : sduinoE 12.1, MC;LL=-1030;LH=916;SL=-534;SH=438;D=AE36174A6CC7EACD146A0E0;C=486;L=90;R=10; RSSI=-69
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:11:20.929 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:11:21.254 3 : sduinoE 12.1, MC;LL=-1040;LH=912;SL=-533;SH=437;D=AE36174A4CC7EACD146B140;C=486;L=90;R=11; RSSI=-68.5
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:11:21.258 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:11:32.160 3 : sduinoE 12.1, MC;LL=-1028;LH=930;SL=-535;SH=446;D=57058BA527A3F5D88A3B120;C=489;L=91;R=15; RSSI=-66.5
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:11:32.166 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:12:05.927 3 : sduinoE 12.1, MC;LL=-1016;LH=920;SL=-527;SH=447;D=571B0BA53663F5668A35070;C=484;L=91;R=9; RSSI=-69.5
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:12:05.935 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:12:50.946 3 : sduinoE 12.1, MC;LL=-1023;LH=918;SL=-538;SH=443;D=571B0BA53663F5668A35070;C=486;L=91;R=9; RSSI=-69.5
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:12:50.948 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:13:09.989 3 : sduinoE 12.1, MC;LL=-1032;LH=930;SL=-528;SH=449;D=B8AEF8B5D0B8144EEB8AEFC;C=489;L=90;R=14; RSSI=-67
2017.11.17 23:14:47.779 3 : sduinoE 12.1, MC;LL=-1024;LH=922;SL=-541;SH=446;D=AE0B174A6F47EBB114773E0;C=488;L=90;R=18; RSSI=-65
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:14:47.787 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:14:47.945 3 : sduinoE 12.1, MC;LL=-1000;LH=946;SL=-518;SH=459;D=57058BA517A3F5D88A3A880;C=487;L=91;R=18; RSSI=-65
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:14:47.948 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:15:05.903 3 : sduinoE 12.1, MC;LL=-1029;LH=929;SL=-522;SH=445;D=AE36174A6CC7EACD146A0E0;C=487;L=90;R=9; RSSI=-69.5
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:15:05.907 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:15:50.900 3 : sduinoE 12.1, MC;LL=-1019;LH=920;SL=-518;SH=457;D=571B0BA53663F5668A35070;C=485;L=91;R=10; RSSI=-69
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:15:50.907 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:16:25.818 3 : sduinoE 12.1, MC;LL=-1008;LH=943;SL=-520;SH=458;D=AE0B174A6F47EBB114773E0;C=488;L=90;R=19; RSSI=-64.5
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:16:25.826 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:16:26.133 3 : sduinoE 12.1, MC;LL=-1018;LH=925;SL=-537;SH=436;D=AE0B174A4F47EBB11476240;C=485;L=90;R=19; RSSI=-64.5
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:16:26.134 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:16:36.065 3 : sduinoE 12.1, MC;LL=-1027;LH=927;SL=-552;SH=426;D=571B0BA51663F5668A34100;C=488;L=91;R=10; RSSI=-69
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:16:36.072 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:17:15.128 3 : sduinoE 12.1, MC;LL=-1024;LH=917;SL=-537;SH=441;D=57058BA527A3F5D88A3B120;C=486;L=91;R=15; RSSI=-66.5
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:17:15.130 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:17:21.056 3 : sduinoE 12.1, MC;LL=-1031;LH=922;SL=-544;SH=436;D=AE36174A2CC7EACD1468200;C=488;L=90;R=9; RSSI=-69.5
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:17:21.063 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:03.811 3 : sduinoE 12.1, MC;LL=-1032;LH=919;SL=-551;SH=430;D=AE0B174A6F47EBB114773E0;C=488;L=90;R=18; RSSI=-65
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:18:03.818 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:03.928 3 : sduinoE 12.1, MC;LL=-1015;LH=941;SL=-524;SH=452;D=57058BA517A3F5D88A3A880;C=488;L=91;R=18; RSSI=-65
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:18:03.932 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:04.076 3 : sduinoE 12.1, MC;LL=-1021;LH=936;SL=-536;SH=444;D=AE0B174A4F47EBB11476240;C=489;L=90;R=15; RSSI=-66.5
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:18:04.083 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:05.923 3 : sduinoE 12.1, MC;LL=-1035;LH=930;SL=-546;SH=432;D=571B0BA53663F5668A35070;C=490;L=91;R=8; RSSI=-70
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:18:05.930 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:06.235 3 : sduinoE 12.1, MC;LL=-1036;LH=920;SL=-549;SH=429;D=AE36174A4CC7EACD146B140;C=488;L=90;R=9; RSSI=-69.5
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:18:06.241 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:50.929 3 : sduinoE 12.1, MC;LL=-1033;LH=918;SL=-542;SH=441;D=571B0BA53663F5668A35070;C=488;L=91;R=8; RSSI=-70
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:18:50.934 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:51.069 3 : sduinoE 12.1, MC;LL=-1023;LH=924;SL=-550;SH=433;D=AE36174A2CC7EACD1468200;C=488;L=90;R=6; RSSI=-71
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:18:51.071 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:51.231 3 : sduinoE 12.1, MC;LL=-1028;LH=927;SL=-551;SH=426;D=571B0BA52663F5668A358A0;C=488;L=91;R=9; RSSI=-69.5
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:18:51.233 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:18:52.966 3 : sduinoE 12.1, MC;LL=-1012;LH=939;SL=-528;SH=450;D=AE0B174A2F47EBB11475100;C=488;L=90;R=15; RSSI=-66.5
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:18:52.973 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:19:35.938 3 : sduinoE 12.1, MC;LL=-1027;LH=929;SL=-535;SH=438;D=AE36174A6CC7EACD146A0E0;C=488;L=90;R=5; RSSI=-71.5
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:19:35.944 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:19:36.250 3 : sduinoE 12.1, MC;LL=-1032;LH=922;SL=-543;SH=435;D=AE36174A4CC7EACD146B140;C=488;L=90;R=6; RSSI=-71
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:19:36.252 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:20:30.843 3 : sduinoE 12.1, MC;LL=-1042;LH=922;SL=-546;SH=428;D=AE0B174A6F47EBB114773E0;C=489;L=90;R=18; RSSI=-65
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:20:30.846 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:21:19.924 3 : sduinoE 12.1, MC;LL=-1020;LH=935;SL=-529;SH=437;D=57058BA517A3F5D88A3A880;C=486;L=91;R=14; RSSI=-67
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:21:19.930 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:21:51.044 3 : sduinoE 12.1, MC;LL=-1034;LH=904;SL=-560;SH=422;D=AE36174A2CC7EACD1468200;C=486;L=90;R=9; RSSI=-69.5
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:21:51.051 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:21:51.190 3 : sduinoE 12.1, MC;LL=-1032;LH=924;SL=-534;SH=439;D=571B0BA52663F5668A358A0;C=488;L=91;R=6; RSSI=-71
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:21:51.192 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:22:09.094 3 : sduinoE 12.1, MC;LL=-1007;LH=947;SL=-518;SH=451;D=57058BA527A3F5D88A3B120;C=487;L=91;R=18; RSSI=-65
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:22:09.101 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:22:36.069 3 : sduinoE 12.1, MC;LL=-1028;LH=923;SL=-536;SH=438;D=571B0BA51663F5668A34100;C=487;L=91;R=5; RSSI=-71.5
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:22:36.076 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:22:58.137 3 : sduinoE 12.1, MC;LL=-1027;LH=926;SL=-545;SH=430;D=AE0B174A4F47EBB11476240;C=487;L=90;R=18; RSSI=-65
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:22:58.142 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:23:20.921 3 : sduinoE 12.1, MC;LL=-1029;LH=914;SL=-548;SH=433;D=571B0BA53663F5668A35070;C=487;L=91;R=9; RSSI=-69.5
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:23:20.927 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:23:21.228 3 : sduinoE 12.1, MC;LL=-1037;LH=911;SL=-549;SH=436;D=571B0BA52663F5668A358A0;C=488;L=91;R=9; RSSI=-69.5
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:23:21.231 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:23:46.953 3 : sduinoE 12.1, MC;LL=-1014;LH=927;SL=-539;SH=443;D=57058BA517A3F5D88A3A880;C=487;L=91;R=17; RSSI=-65.5
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:23:46.955 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:23:47.133 3 : sduinoE 12.1, MC;LL=-1017;LH=935;SL=-533;SH=439;D=57058BA527A3F5D88A3B120;C=487;L=91;R=17; RSSI=-65.5
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:23:47.135 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:24:05.931 3 : sduinoE 12.1, MC;LL=-1022;LH=926;SL=-532;SH=439;D=AE36174A6CC7EACD146A0E0;C=486;L=90;R=9; RSSI=-69.5
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:24:05.938 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:24:06.074 3 : sduinoE 12.1, MC;LL=-1023;LH=924;SL=-547;SH=438;D=571B0BA51663F5668A34100;C=488;L=91;R=8; RSSI=-70
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:24:06.076 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:24:06.228 3 : sduinoE 12.1, MC;LL=-1029;LH=924;SL=-544;SH=438;D=AE36174A4CC7EACD146B140;C=489;L=90;R=6; RSSI=-71
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:24:06.229 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:24:36.140 3 : sduinoE 12.1, MC;LL=-1004;LH=939;SL=-535;SH=444;D=57058BA527A3F5D88A3B120;C=486;L=91;R=18; RSSI=-65
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:24:36.145 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:24:51.266 3 : sduinoE 12.1, MC;LL=-1033;LH=920;SL=-528;SH=451;D=571B0BA52663F5668A358A0;C=488;L=91;R=11; RSSI=-68.5
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:24:51.268 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:25:24.977 3 : sduinoE 12.1, MC;LL=-1024;LH=921;SL=-545;SH=429;D=57058BA517A3F5D88A3A880;C=486;L=91;R=18; RSSI=-65
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 T: 17.1 H: 59
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 humidity: 59
2017-11-17 23:25:24.984 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:25:35.952 3 : sduinoE 12.1, MC;LL=-1034;LH=919;SL=-535;SH=443;D=AE36174A6CC7EACD146A0E0;C=488;L=90;R=8; RSSI=-70
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:25:35.954 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:26:20.963 3 : sduinoE 12.1, MC;LL=-1025;LH=926;SL=-542;SH=442;D=AE36174A6CC7EACD146A0E0;C=489;L=90;R=11; RSSI=-68.5
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:26:20.970 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:27:02.859 3 : sduinoE 12.1, MC;LL=-1023;LH=929;SL=-545;SH=436;D=AE0B174A6F47E811149F440;C=488;L=90;R=19; RSSI=-64.5
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 T: 17.1 H: 60
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:27:02.866 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:27:02.983 3 : sduinoE 12, MC;LL=-1001;LH=946;SL=-518;SH=453;D=51D28BD1FA0445275A8;C=486;L=76;R=15; RSSI=-66.5
2017.11.17 23:27:05.966 3 : sduinoE 12.1, MC;LL=-1029;LH=924;SL=-536;SH=435;D=AE36174A6CC7EACD146A0E0;C=487;L=90;R=11; RSSI=-68.5
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:27:05.968 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:27:50.971 3 : sduinoE 12.1, MC;LL=-1037;LH=924;SL=-533;SH=444;D=571B0BA53663F5668A35070;C=489;L=91;R=10; RSSI=-69
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:27:50.978 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:27:51.991 3 : sduinoE 12.1, MC;LL=-1014;LH=932;SL=-521;SH=454;D=295C5AE85C0BF775B14AE;C=486;L=83;R=19; RSSI=-64.5
2017.11.17 23:28:40.814 3 : sduinoE 12.1, MC;LL=-1026;LH=932;SL=-523;SH=428;D=57058BA537A3F4088A4FA20;C=484;L=91;R=19; RSSI=-64.5
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 T: 17.1 H: 60
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:28:40.816 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:28:41.110 3 : sduinoE 12.1, MC;LL=-1028;LH=932;SL=-535;SH=432;D=57058BA527A3F4088A4F2F0;C=487;L=91;R=19; RSSI=-64.5
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 T: 17.1 H: 60
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:28:41.112 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:29:20.923 3 : sduinoE 12.1, MC;LL=-1016;LH=931;SL=-526;SH=443;D=AE36174A6CC7EACD146A0E0;C=485;L=90;R=11; RSSI=-68.5
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:29:20.925 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:29:21.076 3 : sduinoE 12.1, MC;LL=-1043;LH=915;SL=-559;SH=420;D=571B0BA51663F5668A34100;C=489;L=91;R=14; RSSI=-67
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:29:21.082 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:29:29.949 3 : sduinoE 12.1, MC;LL=-1020;LH=928;SL=-538;SH=441;D=AE0B174A2F47E811149D6A0;C=487;L=90;R=19; RSSI=-64.5
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 T: 17.1 H: 60
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:29:29.953 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:29:30.141 3 : sduinoE 12.1, MC;LL=-1012;LH=934;SL=-527;SH=446;D=57058BA527A3F4088A4F2F0;C=486;L=91;R=16; RSSI=-66
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 T: 17.1 H: 60
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 temperature: 17.1
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:29:30.143 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:30:18.967 3 : sduinoE 12.1, MC;LL=-1030;LH=916;SL=-544;SH=436;D=57058BA513A3F4088A0EB28;C=487;L=91;R=21; RSSI=-63.5
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:30:18.975 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:30:50.939 3 : sduinoE 12.1, MC;LL=-989;LH=931;SL=-530;SH=455;D=AE36174A6CC7EACD146A0E0;C=484;L=90;R=254; RSSI=-75
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:30:50.942 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:30:50.942 3 : sduinoE/noMsg Parse: MD=76
2017.11.17 23:30:51.084 3 : sduinoE 12.1, MC;LL=-1011;LH=931;SL=-544;SH=437;D=571B0BA51663F5668A34100;C=487;L=91;R=11; RSSI=-68.5
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:30:51.086 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:30:51.086 3 : sduinoE/noMsg Parse: MD=79
2017.11.17 23:31:35.952 3 : sduinoE 12.1, MC;LL=-1025;LH=935;SL=-526;SH=439;D=571B0BA53663F5668A35070;C=487;L=91;R=11; RSSI=-68.5
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:31:35.955 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:31:36.100 3 : sduinoE 12.1, MC;LL=-1039;LH=920;SL=-547;SH=424;D=AE36174A2CC7EACD1468200;C=488;L=90;R=14; RSSI=-67
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:31:36.102 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:31:57.182 3 : sduinoE 12.1, MC;LL=-1025;LH=927;SL=-538;SH=437;D=AE0B174A4747E811141E510;C=487;L=90;R=19; RSSI=-64.5
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:31:57.190 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:32:20.957 3 : sduinoE 12.1, MC;LL=-1017;LH=928;SL=-536;SH=449;D=571B0BA53663F5668A35070;C=488;L=91;R=11; RSSI=-68.5
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:32:20.959 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:33:05.969 3 : sduinoE 12.1, MC;LL=-1040;LH=913;SL=-545;SH=432;D=AE36174A6CC7EACD146A0E0;C=488;L=90;R=12; RSSI=-68
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:33:05.977 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:33:35.056 3 : sduinoE 12, MC;LL=-1011;LH=933;SL=-526;SH=455;D=A8E945E8FD022293AD40;C=487;L=77;R=19; RSSI=-64.5
2017.11.17 23:34:23.807 3 : sduinoE 12.1, MC;LL=-1017;LH=934;SL=-528;SH=447;D=57058BA533A3F4088A0FA58;C=487;L=91;R=19; RSSI=-64.5
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:34:23.809 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:34:24.110 3 : sduinoE 12.1, MC;LL=-1025;LH=921;SL=-549;SH=435;D=57058BA523A3F4088A0F288;C=488;L=91;R=19; RSSI=-64.5
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 package_number: 3
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:34:24.112 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:34:35.921 3 : sduinoE 12.1, MC;LL=-1026;LH=923;SL=-542;SH=435;D=571B0BA53663F5668A35070;C=487;L=91;R=11; RSSI=-68.5
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:34:35.923 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:34:36.070 3 : sduinoE 12.1, MC;LL=-1012;LH=931;SL=-513;SH=469;D=AE36174A2CC7EACD1468200;C=487;L=90;R=12; RSSI=-68
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 package_number: 2
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:34:36.073 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:35:12.804 3 : sduinoE 12.1, MC;LL=-1015;LH=948;SL=-529;SH=446;D=AE0B174A6747E811141F4B0;C=489;L=90;R=19; RSSI=-64.5
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:35:12.811 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:35:12.968 3 : sduinoE 12.1, MC;LL=-1025;LH=926;SL=-537;SH=438;D=57058BA513A3F4088A0EB28;C=487;L=91;R=20; RSSI=-64
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:35:12.973 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:35:20.938 3 : sduinoE 12.1, MC;LL=-1035;LH=907;SL=-551;SH=423;D=571B0BA53663F5668A35070;C=485;L=91;R=14; RSSI=-67
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 package_number: 1
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:35:20.942 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:35:21.223 3 : sduinoE 12.1, MC;LL=-1038;LH=915;SL=-545;SH=434;D=AE36174A4CC7EACD146B140;C=488;L=90;R=11; RSSI=-68.5
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 T: 15.5 H: 57
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 battery: ok
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 channel: 2
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 temperature: 15.5
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 package_number: 3
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 humidity: 57
2017-11-17 23:35:21.225 Hideki Hideki_30_5a.2 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:36:01.815 3 : sduinoE 12.1, MC;LL=-1020;LH=935;SL=-525;SH=444;D=AE0B174A6747E811141F4B0;C=487;L=90;R=19; RSSI=-64.5
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 package_number: 1
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:36:01.822 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)
2017.11.17 23:36:01.966 3 : sduinoE 12.1, MC;LL=-1014;LH=936;SL=-522;SH=456;D=AE0B174A2747E811141D650;C=487;L=90;R=18; RSSI=-65
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 T: 17.2 H: 60
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 battery: ok
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 channel: 4
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 temperature: 17.2
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 package_number: 2
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 humidity: 60
2017-11-17 23:36:01.970 Hideki Hideki_30_b8.4 comfort_level: Hum. OK. Temp. uncomfortable (>24.9 or <20)


Edit der ganze log ist zu lang.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 18 November 2017, 10:54:07
Hallo Ralf,

Mal ne frage, ist das Problem dann für den Signalesp in bezug auf It1500 stwckdosen dann auch beseitigt. Ich meine bei It v3 das die letzte 1 im code verschluckt wird? Siehe ein paar posts vorher.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 19 November 2017, 16:06:25
ZitatMal ne frage, ist das Problem dann für den Signalesp in bezug auf It1500 stwckdosen dann auch beseitigt. Ich meine bei It v3 das die letzte 1 im code verschluckt wird? Siehe ein paar posts vorher.
Dies wurde mit der neuen Firmware noch nicht getestet. Ich kann diesen Fehler nicht nachvollziehen da ich kein It v3 habe.

@Sidey
Kannst Du dies mal mit der neuen Firmware testen?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 19 November 2017, 16:36:48
Nicht das ich da was durcheinander werfe... ich hab das problem auf einem Signalesp. Mit einem normalen Signalduino hab das noch nicht getestet.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 November 2017, 21:04:49
Zitat von: Ralf9 am 19 November 2017, 16:06:25
Dies wurde mit der neuen Firmware noch nicht getestet. Ich kann diesen Fehler nicht nachvollziehen da ich kein It v3 habe.

@Sidey
Kannst Du dies mal mit der neuen Firmware testen?

Gruß Ralf

Würde ich machen, wenn ich wüsste wie ich an letzter Stelle eine 1 bekommen soll :(




Ich kann vier codes wählen und die enden dann so:

0000
0100
1000
1100



Zitat von: Markus. am 19 November 2017, 16:36:48
Nicht das ich da was durcheinander werfe... ich hab das problem auf einem Signalesp.

Der SIGNALESP hängt etwas in der Entwicklung zurück, da es noch ein paar grundsätzliche Themen bei dem gibt.
Das Problem gibt es aber wohl auch mit dem SIGNALduino, ich habs nur nicht mehr so richtig präsent, was da genau nicht geht und wie ich es nachstelle
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 20 November 2017, 14:41:03
vielleicht hilft ja meine Fehlerbeschreibung von hier weiter..
https://forum.fhem.de/index.php/topic,79019.0.html (https://forum.fhem.de/index.php/topic,79019.0.html)

Das komische an der Sache war, das er trotz des Fehlers ab und zu schaltete. Sah für mich irgendwie nach einem Timing Problem aus.
Wenn ich dasnoch richtig zusammen bekomme hatte das Dreierset folgende IDs


0101011001010000010111111000000 Stecker 1
0101011001010000010111111000001 (Stecker 2)
0101011001010000010111111000010 Stecker 3

Und eben bei der mittleren ID (Stecker 2 = zweites Tastenpaar auf der FB) trat das Problem auf.
Stecker 2 habe dich dann wie folgt kodiert:
0101011001010000010111111000100
Damit funktioniert es einwandfrei.

Gruß

Markus


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 30 November 2017, 10:18:34
Hallo Zusammen,

hat sich eigentlich in der Zwischenzeit noch was getan in Bezug auf SignalESP ?
Welche SignalDuino <-> Firmware Kombination sollten man denn jetzt verwenden?

Gruß

Markus



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 30 November 2017, 18:19:16
Beim ESP bin ich noch an einer Callback Funktion.

Theoretisch funktioniert es, nur praktisch hatte ich Probleme von FHEM aus dem Zugriff zu gestalten. Da weiss ich noch nicht, woran das liegt....

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 01 Dezember 2017, 22:45:06
Zitat von: Sidey am 30 November 2017, 18:19:16
Theoretisch funktioniert es, nur praktisch hatte ich Probleme von FHEM aus dem Zugriff zu gestalten. Da weiss ich noch nicht, woran das liegt....

ggf. sind das Probleme bei impliziten Typ-Konvertierungen.
habe ich seit Ende Oktober hier (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb) committed.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 Dezember 2017, 00:27:14
Ich habe gestern eine Version commitet, die läuft schon ganz gut
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 02 Dezember 2017, 09:47:51
Hallo Sidey,

wird das über das normal Update verteilt?

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 02 Dezember 2017, 21:52:07
Zitat von: Sidey am 02 Dezember 2017, 00:27:14
Ich habe gestern eine Version commitet, die läuft schon ganz gut

manchester sieht mau aus (basierend auf meinem Pull-Request (https://github.com/RFD-FHEM/SIGNALESP/pull/13))

ccconf: freq:433.720MHz bWidth:650KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)

-- miniCUL
set miniCUL raw YsA110000112389A

2017.12.02 21:29:39 4: signalESP/msg READ: Mc;LL=-1309;LH=1211;SL=-636;SH=676D=AF272727EAF6FF8;C=0;L=57;R=245;
2017.12.02 21:29:39 4: signalESP/msg READ: Mc;LL=-1278;LH=1236;SL=-602;SH=621D=AF272727EAF6E;C=1;L=51;R=241;
2017.12.02 21:29:39 4: signalESP/msg READ: Mc;LL=-1274;LH=1235;SL=-595;SH=630D=AF272727EAF6FF8;C=7;L=57;R=241;
2017.12.02 21:29:39 4: signalESP/msg READ: Mc;LL=-1190;LH=1241;SL=-592;SH=650D=3636360542400;C=4;L=51;R=241;
2017.12.02 21:29:39 4: signalESP/msg READ: Mc;LL=-1196;LH=1244;SL=-607;SH=625D=AF272727EAF4;C=7;L=46;R=241;
2017.12.02 21:29:40 4: signalESP/msg READ: Mc;LL=-1201;LH=1232;SL=-622;SH=582D=3636360542400;C=1;L=51;R=241;

-- sduino
set sduino sendMsg P43#A1B1B1B02A1200#R6

-- recv
2017.12.02 21:30:17 4: signalESP/msg READ: Mc;LL=-1245;LH=1338;SL=-615;SH=676D=AF272727EAF6FF8;C=7;L=57;R=235;
2017.12.02 21:30:17 4: signalESP/msg READ: Mc;LL=-1243;LH=1327;SL=-595;SH=696D=A84800;C=3;L=22;R=237;
2017.12.02 21:30:17 4: signalESP/msg READ: Mc;LL=-1239;LH=1342;SL=-597;SH=698D=72727EAF6FF8;C=1;L=45;R=237;
2017.12.02 21:30:17 4: signalESP/msg READ: Mc;LL=-1244;LH=1350;SL=-615;SH=688D=BC9C9C9FABDBFE;C=4;L=55;R=237;
2017.12.02 21:30:18 4: signalESP/msg READ: Mc;LL=-1230;LH=1345;SL=-588;SH=708D=AF272727C;C=6;L=34;R=238;
2017.12.02 21:30:18 4: signalESP/msg READ: Mc;LL=-1248;LH=1346;SL=-604;SH=682D=AF272727EAF6FF8;C=6;L=57;R=233;



AF272727EAF6FF8

1010 1111 0010 0111 0010 0111 0010 0111 1110 1010 1111 0110 1111 1111 1000

A1B1B1B02A1200

101 0000 1101 1000 1101 1000 1101 1000 0001 0101 0000 1001 0000 0000 0


die Bitfolge von AF272727EAF6FF8 findet sich negiert in der von A1B1B1B02A1200 wieder.
die Bitfolge von A1B1B1B02A1200 findet sich negiert in der von AF272727EAF6FF8 wieder.
Titel: SIGNALDuino will nicht
Beitrag von: Heiner am 03 Dezember 2017, 20:33:47
HI,

ich habe gerade meine Sebstbau Cul mit Ardunino Nano und CC1101 auf Signalduino geflasht. Das flashen lief Problemlos, aber in fhem will das Ding nicht so recht.

Hier das Log:

2017.12.03 19:28:47 3: Opening SignalDuino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.12.03 19:28:47 3: Setting SignalDuino serial parameters to 57600,8,N,1
2017.12.03 19:28:47 1: SignalDuino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.03 19:28:47 1: SignalDuino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.03 19:28:47 3: SignalDuino device opened
2017.12.03 19:28:52 3: SignalDuino sduinoIdList: whitelistIds=
2017.12.03 19:28:52 3: SignalDuino sduinoIdList: blacklistIds=
2017.12.03 19:28:52 3: SignalDuino sduinoIdList: development=
2017.12.03 19:28:52 3: SignalDuino: ID=63 skiped (developId=y)
2017.12.03 19:28:52 3: SignalDuino: ID=74 skiped (developId=y)
2017.12.03 19:28:52 3: SignalDuino: ID=73 skiped (developId=y)
2017.12.03 19:28:52 3: SignalDuino: ID=p76 skiped (developId=p)
2017.12.03 19:28:52 3: SignalDuino: ID=p76.1 skiped (developId=p)
2017.12.03 19:28:52 3: SignalDuino: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 3.1 32 33 35 38 4 41 51 55 6 68 7 72.1
2017.12.03 19:28:52 3: SignalDuino: IDlist MU 13.1 16 20 21 24 26 27 28 29 30 31 36 37 39 40 44 44.1 45 46 48 49 5 50 56 59 60 61 62 64 65 66 67 69 70 71 72 75 8 9
2017.12.03 19:28:52 3: SignalDuino: IDlist MC 10 11 12 12.1 18 43 47 52 57 58
2017.12.03 19:28:52 3: SignalDuino/init: disable receiver (XQ)
2017.12.03 19:28:52 3: SignalDuino/init: get version, retry = 0
2017.12.03 19:29:02 3: SignalDuino/init: get version, retry = 1
2017.12.03 19:29:12 3: SignalDuino/init: get version, retry = 2
2017.12.03 19:29:22 3: SignalDuino/init: get version, retry = 3
2017.12.03 19:29:22 2: SignalDuino/init retry count reached. Reset
2017.12.03 19:29:22 3: SignalDuino reset
2017.12.03 19:29:22 3: Opening SignalDuino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.12.03 19:29:22 3: Setting SignalDuino serial parameters to 57600,8,N,1
2017.12.03 19:29:22 1: SignalDuino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.03 19:29:22 1: SignalDuino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.03 19:29:22 3: SignalDuino device opened
2017.12.03 19:29:24 3: SignalDuino/init: disable receiver (XQ)
2017.12.03 19:29:24 3: SignalDuino/init: get version, retry = 0
2017.12.03 19:29:34 3: SignalDuino/init: get version, retry = 1
2017.12.03 19:29:44 3: SignalDuino/init: get version, retry = 2
2017.12.03 19:29:54 3: SignalDuino/init: get version, retry = 3
2017.12.03 19:29:54 2: SignalDuino/init retry count reached. Closed
2017.12.03 19:29:54 2: SignalDuino closed


Wenn ich das richtig sehe, scheint da ein Reciever Problem der für das abschalten sorgt. Kann das sein? Was kann ich tun?
Danke fuer die Tipps.

Heiner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Dezember 2017, 09:00:15
Hallo Heiner,

Was hast Du denn auf den Arduino geflasht?

Aus dem Log kann ich nur entnehmen, dass die Serielle Kommunikation nicht klappt.

FHEM fragt die Version vom uC an, bekommt aber keine Antwort.

Gruß Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Heiner am 04 Dezember 2017, 12:15:43
Hi Sidey,

nun ja ich hoffe genau so we es im WIKI steht.

Erst mal den alten nanocul deleten  (aber vorher den DEF notieren damit ich den richtigen seriellen Port habe)
dann Singalduino definieren,
dann Hardware setzen
und dann im Menue mit Set flashen und dabei das passende Verzeichnis angeben.



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Dezember 2017, 16:11:14
Ich nehme an, Du verwendest nur die Quellen die über das normale FHEM Update kommen.

Die Firmware für den cc1101 wird aber noch nicht über das FHEM Update verteilt.

Wenn Du einmalig die Version aus Github installierst, dann hast Du auch die Firmware und kannst flashen:

https://github.com/RFD-FHEM/RFFHEM


Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: wthiess am 04 Dezember 2017, 20:56:33
Hallo!

Ich hab einen neuen Fensterkonakt Kerlii: Im Event Monitor kommt folgendes
IT IT_1527x49afa on   = Manipulationskontakt wurde autocreate angelegt und funktioniert.
Aber die Auf / zu werden nicht angelegt. Warum?
SIGNALduino sduino UNKNOWNCODE i49AFA7     (= zu)
SIGNALduino sduino UNKNOWNCODE i49AFAE     (= auf)
Werte in (sind nur Legende)
Kann ich das irgendwie verwerten? Da doch immer zuverlässig die Werte kommen.

edit: Mit einem Notfy gehts. Aber elegant?

lg
Wolfgang

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Heiner am 04 Dezember 2017, 21:10:41
Hi Sidey,

also deine update quelle führt im Log nur zu:
2017.12.04 20:58:38 1: fhem
2017.12.04 20:58:38 1: nothing to do...
2017.12.04 20:58:38 1:
2017.12.04 20:58:38 1: fhemtabletui
2017.12.04 20:58:39 1: nothing to do...
2017.12.04 20:58:39 1:
2017.12.04 20:58:39 1: signalduino
2017.12.04 20:58:41 1: nothing to do...


Vermutlich weil sehr aehnlich zum WIKI.

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

und das führt im Log zu:

2017.12.04 21:03:40 1 : UPD FHEM/firmware/SIGNALduino_nanoCC1101.hex
2017.12.04 21:03:41 1 : UPD FHEM/firmware/SIGNALDuino_radinoCC1101.hex
2017.12.04 21:03:41 1 : UPD FHEM/14_Hideki.pm
2017.12.04 21:03:41 1 : Got 19404 bytes for FHEM/14_Hideki.pm, expected 21737
2017.12.04 21:03:41 1 : aborting.

also noch mal flashen
und der output ist:
flashing Arduino SignalDuino
hex file: FHEM/firmware/SIGNALduino_nanoCC1101.hex
port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
log file: ./log/SIGNALduino-Flash.log
SignalDuino closed
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101.hex 2>./log/SIGNALduino-Flash.log

--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 5.11.1, compiled on Dec 17 2011 at 19:33:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101.hex auto detected as Intel Hex
avrdude: writing flash (20520 bytes):

Writing | ################################################## | 100% 6.37s

avrdude: 20520 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101.hex contains 20520 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.88s

avrdude: verifying ...
avrdude: 20520 bytes of flash verified

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

SignalDuino opened


dannach lese ich im log:

2017.12.04 21:05:45 3: SignalDuino: filename FHEM/firmware/SIGNALduino_nanoCC1101.hex provided, trying to flash
2017.12.04 21:05:58 3: Opening SignalDuino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.12.04 21:05:58 3: Setting SignalDuino serial parameters to 57600,8,N,1
2017.12.04 21:05:58 1: SignalDuino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.04 21:05:58 1: SignalDuino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.04 21:05:58 3: SignalDuino device opened
2017.12.04 21:05:59 3: SignalDuino/init: disable receiver (XQ)
2017.12.04 21:06:00 3: SignalDuino/init: get version, retry = 0
2017.12.04 21:06:00 2: SignalDuino: initialized. v3.3.3-dev
2017.12.04 21:06:00 3: SignalDuino/init: enable receiver (XE)

scheint alles gut zu sein.....

sduino zeigt auch als Version:  V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

Vielen Dank für die Hilfe.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Schnello am 15 Dezember 2017, 14:41:41
Hallo Hainer.


Funktioniert bei dir das "get ccconf"?

Edit:
Hat sich erledigt. Ein Kabel hatte sich gelöst.


Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jfu am 16 Dezember 2017, 20:01:32
Hallo zusammen,

ich weiß nicht was ich falsch mache, aber mein SIGNALduino will einfach nicht funken. Mein Setup ist ein Arduino Nano und ein CC1101 Transceiver angeschlossen an einen Raspberry Pi 3. Ich habe die Anleitung aus dem Wiki befolgt und den Arduino entsprechend (erfolgreich?) geflasht. Verkabelt habe ich den CC1101 mit dem Nano so:











ArduinoCC1101
(17) VCC 3,3 VVDD / PIN 1
(14) PIN D11SI (MOSI) / PIN 3
(16) PIN D13SCK / PIN 4
(15) PIN D12SO (MISO) / PIN 5
(5) PIN D02   GDO2 / PIN 6
(13) PIN D10CSn (SS) / PIN 7
(6) PIN D03GDO0 / PIN 8
(4/29) PIN GNDGND / PIN 9

Hier die Auszüge aus dem Log:


2017.12.16 19:30:56 3: sduino: filename ./FHEM/firmware/SIGNALduino_nanoCC1101.hex provided, trying to flash
2017.12.16 19:31:09 3: Opening sduino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.12.16 19:31:09 3: Setting sduino serial parameters to 57600,8,N,1
2017.12.16 19:31:09 1: sduino/define: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.16 19:31:09 1: sduino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2017.12.16 19:31:09 3: sduino device opened
2017.12.16 19:31:10 4: sduino/msg READ: Using sFIFO
2017.12.16 19:31:10 5: sduino/noMsg Parse: Using sFIFO
2017.12.16 19:31:10 4: sduino/msg READ: Init eeprom to defaults after flash
2017.12.16 19:31:10 5: sduino/noMsg Parse: Init eeprom to defaults after flash
2017.12.16 19:31:10 3: sduino/init: disable receiver (XQ)
2017.12.16 19:31:10 5: sduino SW: XQ
2017.12.16 19:31:10 4: sduino/msg READ: ccFactoryReset done
2017.12.16 19:31:10 5: sduino/noMsg Parse: ccFactoryReset done
2017.12.16 19:31:10 4: sduino/msg READ: CCVersion=0
2017.12.16 19:31:10 5: sduino/noMsg Parse: CCVersion=0
2017.12.16 19:31:10 4: sduino/msg READ: CCPartnum=0
2017.12.16 19:31:10 5: sduino/noMsg Parse: CCPartnum=0
2017.12.16 19:31:10 4: sduino/msg READ: no CC11xx found!
2017.12.16 19:31:10 5: sduino/noMsg Parse: no CC11xx found!
2017.12.16 19:31:10 4: sduino/msg READ:
2017.12.16 19:31:10 4: sduino/msg READ: Starting timerjob
2017.12.16 19:31:10 5: sduino/noMsg Parse: Starting timerjob
2017.12.16 19:31:11 4: sduino/msg READ: receiver enabled
2017.12.16 19:31:11 5: sduino/noMsg Parse: receiver enabled
2017.12.16 19:31:11 3: sduino/init: get version, retry = 0
2017.12.16 19:31:11 5: sduino SW: V
2017.12.16 19:31:11 4: sduino/msg READ: V 3.3.1-dev SIGNALduino - compiled at Mar 10 2017 22:54:50
2017.12.16 19:31:11 5: sduino/noMsg Parse: V 3.3.1-dev SIGNALduino - compiled at Mar 10 2017 22:54:50
2017.12.16 19:31:11 5: sduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino - compiled at Mar 10 2017 22:54:50
2017.12.16 19:31:11 2: sduino: initialized. v3.3.3-dev
2017.12.16 19:31:11 5: sduino SW: XE
2017.12.16 19:31:11 3: sduino/init: enable receiver (XE)



Was mich stutzig macht ist natürlich "2017.12.16 19:31:10 4: sduino/msg READ: no CC11xx found!" aber da anschließend "2017.12.16 19:31:11 4: sduino/msg READ: receiver enabled" kommt, denke ich das alles in Ordnung ist?

Wenn ich nun aus einem Device (hier Siro Rollo) heraus sende sieht es im Log so aus:


2017.12.16 19:55:59 1: Siro_Set:limited function without definition of time_to_close and time_to_open. Please define this attributes.
2017.12.16 19:55:59 3: Siro_set: handing over to Siro_Send_Command with following arguments: prog  0
2017.12.16 19:55:59 5: Siro_sendCommand: BinHash: = 1100110100010011111111000001
2017.12.16 19:55:59 5: Siro_sendCommand: BinCommand: = 11001100
2017.12.16 19:55:59 5: Siro_sendCommand: Siro set value = ERB16 prog  0
2017.12.16 19:55:59 5: Siro_sendCommand: Siro_sendCommand: ERB16 -> message :P72#1100110100010011111111000001001111001100#R8:
2017.12.16 19:55:59 5: sduino/write: adding to queue sendMsg P72#1100110100010011111111000001001111001100#R8
2017.12.16 19:55:59 5: sduino: sendmsg msg=P72#1100110100010011111111000001001111001100#R8
2017.12.16 19:55:59 5: sduino: sendmsg Preparing rawsend command for protocol=72, repeats=8, clock=340 bits=1100110100010011111111000001001111001100
2017.12.16 19:55:59 5: AddSendQueue: sduino: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545; (1)
2017.12.16 19:55:59 4: sduino/set: sending via SendMsg: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 3: Siro_sendCommand: execute comand prog - sendMsg to HASH(0x1f22d80) channel 3 -> P72#1100110100010011111111000001001111001100#R8
2017.12.16 19:55:59 5: sduino SW: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 4: sduino SendrawFromQueue: msg=SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 4: sduino/msg READ: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 5: sduino/noMsg Parse: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 5: sduino/msg READ: regexp=^S(R|C|M); cmd=sendraw msg=SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 4: sduino/read sendraw answer: SR;R=8;P0=4760;P1=-1496;P2=680;P3=-408;P4=340;P5=-748;D=0123234545232345234545452345452323232323232323454545454523454523232323454523234545;
2017.12.16 19:55:59 4: sduino/HandleWriteQueue: nothing to send, stopping timer



Nachtrag: Ein "get cconfig" sagt "This command is only available with a cc1101 receiver".

Irgendeine Idee was ich falsch mache?

Viele Grüße
Johannes
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 17 Dezember 2017, 07:50:41
Hi,
,,no CC11xx found" lässt auf kaputten CC1101 oder auf kalte Lötstellen schließen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 17 Dezember 2017, 11:03:53
Moin Arnd
Hast Du nichts besseres zu tun als am Sonntag um 10 vor acht im Forum Fragen zu beantworten?
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jfu am 17 Dezember 2017, 12:09:04
Zitat von: RaspiLED am 17 Dezember 2017, 07:50:41
Hi,
,,no CC11xx found" lässt auf kaputten CC1101 oder auf kalte Lötstellen schließen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Danke für die schnelle Antwort, gibt es irgendeine Möglichkeit das zu verifizieren? Der CC1101 kommt frisch aus der Packung...
Titel: OT: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Pfriemler am 17 Dezember 2017, 12:27:23
Zitat von: pc1246 am 17 Dezember 2017, 11:03:53
Arnd ... nichts besseres zu tun als am Sonntag um 10 vor acht im Forum Fragen zu beantworten?
tja: je nach Alter
- vor dem Schlafengehen schnell noch ein paar Fragen zum Runterkommen beantworten
- nervende Kinder vermiesen das Ausschlafen
- senile Bettflucht
...  ;D ;D
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 17 Dezember 2017, 14:00:40
Hi,
[OT] ...oder während ich den Kindern beim Kerzenanzünden zusehe...[/OT]
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jfu am 17 Dezember 2017, 17:09:36
Ich hatte falsch bzw. unzureichend verkabelt/gelötet - nun klappt alles!!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 19 Dezember 2017, 14:40:17
Hallo,

hier ist für den Arduino nano eine Test-Version der neuen V 3.3.2-dev firmware. Es wurden recht viele Fehler beseitigt und einiges optimiert. Ich und Sidey haben den ManchesterDecoder komplett überarbeitet. Der Hideki Empfang hat sich deutich verbessert. Die anderen Manchester Sensoren wurden noch nicht alle getestet.
Dies ist meine 3.3.2 FW die nicht identisch mit einer zukünftigen Signalduino FW 3.3.2 sein muss.

Diese Version ist auf Wiederholungen optimiert.

Ich habe auch eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut. Dies ist noch experimentel, es kann sein, das dies nicht bei allen MU-Nachrichten funktioniert. Ein w am Ende der Nachricht bedeutet, das eine mögliche Wiederholung erkannt wurde.
Es gibt eine neue Konfigvariable muthresh, damit wird der Schwellwert für den split von MU Nachrichten festgelegt.
Mit CSmuthresh=8000 werden z.B. die MU Nachrichten nach einer Pause größer 8 ms gesucht und dort die Nachricht abgetrennt.

Bei den MC-Nachrichten habe ich auch eine Erkennung von Wiederholungen eingebaut.

Edit:
Ich habe dafür ein neues Thema erstellt:
https://forum.fhem.de/index.php/topic,82379.0.html

BTW
Ich habe seither die Arduino IDE 1.6.5 verwendet und habe nun auf die 1.8.5 geupdatet, ich hätte nicht gedacht, daß der Unterschied des verwendeten Speichers so deutlich ist:
ZitatArduino IDE 1.6.5
Der Sketch verwendet 30.132 Bytes (98%) des Programmspeicherplatzes. Das Maximum sind 30.720 Bytes.
Arduino IDE 1.8.5
Der Sketch verwendet 24828 Bytes (80%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.

Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 Dezember 2017, 15:21:20
Hi Ralf,

Kannst Du noch deutlich machen, dass es deine 3.3.2 FW ist und die nicht identisch mit einer zukünftigen Signalduino FW 3.3.2 sein muss, denn die gibt es ja noch nicht.

Ich weiss leider auch nicht, wie man das transparent machen kann, dass es unterschiedliche Firmwares gibt und wo die Fehler zu berichten sind.


Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 Januar 2018, 00:33:09
So, zum neuen Jahr bin ich endlich mal soweit wieder eine Firmware zu veröffentlichen:

Wäre schön, wenn ich Rückmeldungen von euch erhalten könnte.

Die aktuelle "Vorabversion" habe ich im Wiki verlinkt:

https://wiki.fhem.de/wiki/SIGNALduino#Vorabversion_einer_Firmware


Bekannt sind damit folgende "Fehler":

- Wiederholungen von Manchester Signalen, werden manchmal invertiert empfangen (ab RC4)
- Sehr lange Sendekommandos werden nicht richtig verarbeitet
- Kombinierter Sendebefehl wurde mit einer falschen Anzahl an Wiederholungen gesendet. (ab RC2)
- Fehlerhafte Berechnung der Mindestlänge von MS Signalen. (RC3)

EDIT:
02.1.18 22:45: Ich habe die Firmware noch mal neu compiliert, da etwas mit dem freien Speicher nicht stimmte.
04.1.18 21:09: Firmware für SignalESP aufgenommen
06.1.18 21:09: Version 3.3.1 RC2 bereitgestellt
13.1.18 21:24: Version 3.3.1 RC2 nun auch für ESP+CC1101
22.1.18 21:41: Version 3.3.1 RC3 für minicul und nanocc1101 bereitgestellt
04.07.18 22:35:  Direkt auf das Wiki verlinkt
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 04 Januar 2018, 09:34:26
Moin Sidey
Laufen die auch auf einem ESP-duino?
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Januar 2018, 09:51:28
Was ist denn ein ESP Duino?

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: rcmcronny am 04 Januar 2018, 10:18:49
Er meint wohl den SignalESP ;)

Das würde mich auch interessieren, weil ich den auch nutze u.a. ;)

Ronny
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 04 Januar 2018, 12:04:59
Hallo
Ja ich meine den SignalESP, sorry, habe zwei Tage Ikea-Kueche bauen hinter mir!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Januar 2018, 17:44:28
SignalESP muss ich separat compilieren.

Ich denke das klappt heute Abend

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 05 Januar 2018, 15:47:35
sduino (Arduino+RBX6) sendet und signalESP (ESP8266+locutus cc1101 shield) empfängt

set sduino sendMsg P43#A1B1B1B02A1200#R6


2018.01.05 15:11:30 4: signalESP/msg READ: Mc;LL=-1300;LH=1271;SL=-764;SH=601;D=AF272727EAF6FF8;C=3;L=57;R=233;
2018.01.05 15:11:30 4: signalESP/msg READ: Mc;LL=-1296;LH=1280;SL=-659;SH=630;D=1B1B1B02A10;C=0;L=41;R=234;
2018.01.05 15:11:30 4: signalESP/msg READ: Mc;LL=-1326;LH=1262;SL=-650;SH=636;D=5E4E4E4FD5EDFF;C=0;L=56;R=232;
2018.01.05 15:11:30 4: signalESP/msg READ: Mc;LL=-1318;LH=1254;SL=-658;SH=620;D=5E4E4E4FD5EDFF;C=0;L=56;R=231;
2018.01.05 15:11:31 4: signalESP/msg READ: Mc;LL=-1293;LH=1278;SL=-669;SH=625;D=5E4E4E4FD5EDFF;C=7;L=56;R=233;
2018.01.05 15:11:31 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A1B1B1B02A1200;SR;P0=-2560;D=000000000000;


es waren 3 Bugfixes (2x output.h; 1x signalDecoder.cpp) notwendig, damit travis keine Fehler mehr meldet.

Leider wird bestenfalls ein invertiertes Manchester-Signal (SOMFY) empfangen.

Empfang wird besser, wenn signalESP sendet

set signalESP sendMsg P43#A1B1B1B02A1200#R6#F10B07157C4


2018.01.05 15:42:57 4: sduino/msg READ: MC;LL=-1380;LH=1222;SL=-756;SH=552;D=A1B1B1;C=651;L=24;
2018.01.05 15:42:57 4: sduino/msg READ: MC;LL=-1306;LH=1268;SL=-667;SH=675;D=A1B1B1B02A;C=652;L=40;
2018.01.05 15:42:58 4: sduino/msg READ: MC;LL=-1276;LH=1294;SL=-643;SH=648;D=A1B1B1B02A1200;C=643;L=55;
2018.01.05 15:42:58 4: sduino: Found manchester Protocol id 43 clock 643 -> Somfy RTS
2018.01.05 15:42:58 4: sduino: Somfy bitdata: 10100001101100011011000110110000001010100001001000000000 (55)
2018.01.05 15:42:58 4: sduino: Somfy RTS preprocessing check: 0 enc: A1B1B1B02A1200 dec: A11000019A3812
2018.01.05 15:42:58 1: SOMFY Unknown device 12389A (A1 0001), please define it
2018.01.05 15:42:58 4: sduino/msg READ: MC;LL=-1286;LH=1283;SL=-654;SH=638;D=A1B1B1B02A1200;C=643;L=55;
2018.01.05 15:42:58 4: sduino: Found manchester Protocol id 43 clock 643 -> Somfy RTS
2018.01.05 15:42:58 4: sduino: Somfy bitdata: 10100001101100011011000110110000001010100001001000000000 (55)
2018.01.05 15:42:58 4: sduino Dispatch: YsA1B1B1B02A1200, Dropped due to short time or equal msg
2018.01.05 15:42:58 4: sduino/msg READ: MC;LL=-1293;LH=1287;SL=-647;SH=642;D=A1B1B1B02A1200;C=644;L=55;
2018.01.05 15:42:58 4: sduino: Found manchester Protocol id 43 clock 644 -> Somfy RTS
2018.01.05 15:42:58 4: sduino: Somfy bitdata: 10100001101100011011000110110000001010100001001000000000 (55)
2018.01.05 15:42:58 4: sduino Dispatch: YsA1B1B1B02A1200, Dropped due to short time or equal msg
2018.01.05 15:42:58 4: sduino/msg READ: MC;LL=-1293;LH=1287;SL=-647;SH=642;D=A1B1B1B02A1200;C=644;L=55;
2018.01.05 15:42:58 4: sduino: Found manchester Protocol id 43 clock 644 -> Somfy RTS
2018.01.05 15:42:58 4: sduino: Somfy bitdata: 10100001101100011011000110110000001010100001001000000000 (55)
2018.01.05 15:42:58 4: sduino Dispatch: YsA1B1B1B02A1200, Dropped due to short time or equal msg



signalESP

   READINGS:
     2018-01-05 14:50:00   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-01-05 15:44:22   ping            OK
     2018-01-05 15:34:21   state           opened
     2018-01-05 15:34:21   version         V 3.3.1-dev SIGNALESP cc1101 433MHz - compiled at Jan  5 2018 15:32:01


sduino (nicht die aktuellste Version)

   READINGS:
     2018-01-05 15:44:24   ping            OK
     2017-12-15 14:54:09   state           opened
     2017-12-15 14:54:09   version         V 3.3.1-dev SIGNALduino - compiled at Jan  3 2017 23:59:32
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 Januar 2018, 18:30:42
Wie kann ich den SignalESP denn neu konfigurieren. Im Moment hat er eine ganz schräge IP Adresse "10.22.0.200". Gibt es kein DHCP mehr?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Januar 2018, 19:10:47
Zitat von: gloob am 05 Januar 2018, 18:30:42
Wie kann ich den SignalESP denn neu konfigurieren. Im Moment hat er eine ganz schräge IP Adresse "10.22.0.200". Gibt es kein DHCP mehr?
Beim booten macht der ESP ein WLAN auf. Über diese WLAN kannst Du ihm auch eine statische Adresse geben

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 05 Januar 2018, 19:13:41
Gibt es noch einen Trick beim Anlegen in FHEM?
Derzeit geht er nur auf "Opened", lässt aber keine CCConfig auslesen.

defmod SIGNALESP433 SIGNALduino 192.168.1.194:23
attr SIGNALESP433 flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr SIGNALESP433 hardware nanoCC1101
attr SIGNALESP433 icon cul_cul
attr SIGNALESP433 room Gateways,SignalESP


mounting FS...
mounted file system
reading config file
opened config file
{"ip":"10.22.0.200","gateway":"0.0.0.0","subnet":"255.255.255.0"}
parsed json
setting custom ip from config
10.22.0.200
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESP3512638
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 13
cnt

connected with xxx, channel 6
dhcp client start...
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
ip:192.168.1.194,mask:255.255.255.0,gw:192.168.1.1
connected...)
local ip
192.168.1.194
receiver enabled
New client:


Die Firmware vom 6.Juni zeigt, dass es geht:

setstate SIGNALESP433 opened
setstate SIGNALESP433 2017-07-02 13:17:57 ITParms Unsupported command
setstate SIGNALESP433 2018-01-05 19:29:16 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
setstate SIGNALESP433 2017-09-05 14:45:27 ccpatable C3E = 00 84 00 00 00 00 00 00  => 5_dBm
setstate SIGNALESP433 2018-01-05 19:11:24 config MS=1;;MU=1;;MC=1
setstate SIGNALESP433 2017-09-05 14:55:47 freeram 41784
setstate SIGNALESP433 2018-01-05 19:31:14 ping OK
setstate SIGNALESP433 2018-01-05 19:28:14 state opened
setstate SIGNALESP433 2017-09-04 19:23:30 uptime 0 00:00:20
setstate SIGNALESP433 2018-01-05 19:29:33 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Jun  6 2017 12:37:19

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 05 Januar 2018, 23:42:03
Zitat von: habeIchVergessen am 05 Januar 2018, 15:47:35
sduino (Arduino+RBX6) sendet und signalESP (ESP8266+locutus cc1101 shield) empfängt

Den Fehler habe ich behoben und RC2 bereitgestellt.

Zitat von: habeIchVergessen am 05 Januar 2018, 15:47:35
es waren 3 Bugfixes (2x output.h; 1x signalDecoder.cpp) notwendig, damit travis keine Fehler mehr meldet.

Travis lief mit dem Branch durch. Verstehe ich jetzt nicht.

Zitat von: gloob am 05 Januar 2018, 19:13:41
Gibt es noch einen Trick beim Anlegen in FHEM?
Derzeit geht er nur auf "Opened", lässt aber keine CCConfig auslesen.

Ich habe keine Firmware mit cc1101 Support compiliert und bereitgestellt. Damit geht kein CCConfig.
Das Thema gehe ich aber auch an.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 06 Januar 2018, 10:56:09
Zitat von: Sidey am 05 Januar 2018, 23:42:03
Travis lief mit dem Branch durch. Verstehe ich jetzt nicht.
Ich habe den CC1101-Support an.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 06 Januar 2018, 13:06:33
Zitat von: habeIchVergessen am 06 Januar 2018, 10:56:09
Ich habe den CC1101-Support an.

Würdest du dann bitte deine kompilierte Firmware zur Verfügung stellen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 06 Januar 2018, 15:12:29
für ein WeMos D1  mini kompiliert

Sourcen hier (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Teamdrachen am 06 Januar 2018, 22:10:49
Kurze frage...
bietet die CC1101 Version irgendwelche Vorteile zur Version mit WS001 Empfänger?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 07 Januar 2018, 02:21:23
Hi,
Ja, viele haben die Hardware in Form eines nanoCULs schon da und man kann die Freq anpassen. Z.B. Zwischen 433.920 (IT) und 433.420 MHz (Somfy) oder auch mal kurz einen Ausflug auf 868.300 MHz machen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Teamdrachen am 07 Januar 2018, 10:00:13
Zitat von: RaspiLED am 07 Januar 2018, 02:21:23
Hi,
Ja, viele haben die Hardware in Form eines nanoCULs schon da und man kann die Freq anpassen. Z.B. Zwischen 433.920 (IT) und 433.420 MHz (Somfy) oder auch mal kurz einen Ausflug auf 868.300 MHz machen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Das grün markierte würde ich jetzt nicht so unterschreiben. Im alten Signalduino Thread war die Anzahl der VERSCHIEDENEN Mitschreiberlinge höher. Bei einigen und auch den Neulingen könnte durchaus der Eindruck entstehen man BRAUCHT JETZT unbedingt einen CC1101.



Kurze Anmmerkung... dann bin ich auch schon weg.
Der Threadtitel ist eventuell etwas unglücklich gewählt. Man hat den Eindruck, es ginge um das optimieren der Signalduino Hardware.
Optimieren in der Richtung, das etwas mehr Reichweite rauskommt, oder Empfangssicherheit.
Daher die Fehler "ausmerzen" wo der SignalDuino softwareseitig funktionieren müsste, es dennoch zu Problemchen kommt.

An der Stelle drängt sich dann auch der Gedanke auf der  CC1101 wäre jetzt das Maß der Dinge für störungsfreien Empfang ... besser als die Superheterodyne, oder WS001.
Die neue Referenz im Signalduino Hardware Design sozusagen.

Man muss sich wirklich durch alle Seiten "wühlen" um auf den Gedanken zu kommen.... es ist etwas ganz anderes.
Zumindest nach den ersten paar Seiten geht es dann in so viele verschiedene Richtungen... es wird verwirrend. Jede Menge "ich hab jetzt auch mal was verändert" Versionen.

Letztendlich weiß man dann doch nicht worum es hier im Thread letztendlich geht.
Evolution des bekannten SignalDuino ? Der alte Thread ist ja mehr oder weniger geschlossen.
Den CC1101 + Nano erst mal auf den Stand zu bringen den der Signalduino mit herkömmlicher Hardware jetzt schon hat ?
Experimente mit den verschiedenen Layouts der ESP-Varianten&CC1101 ... was unter dem Schlagwort ESPDuino oder doch eher SignalESP, SignalNode, SignalAmica, SignalWeMos durchaus seinen ganz eigenen Bereich haben könnte ?


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Invers am 07 Januar 2018, 12:56:02
Nach heutigem Updete folgende Fehler im Log:
2018.01.07 08:21:19 1: reload: Error:Modul 00_SIGNALduino deactivated:
syntax error at ./FHEM/00_SIGNALduino.pm line 4757, near "$name:"

2018.01.07 08:21:19 0: syntax error at ./FHEM/00_SIGNALduino.pm line 4757, near "$name:"


Bin zurück zum Vorgänger.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Januar 2018, 13:17:21
Zitatsyntax error at ./FHEM/00_SIGNALduino.pm line 4757, near "$name:
Dies sieht nach der dev-r33 Version aus, dies ist die developversion wo es ab und zu vorkommen kann, daß was nicht funktioniert.
Die stabile Version ist normalen FHEM Update (SVN).

Hier geht es um die SIGNALDuino Empfänger Firm- und Hardware. Für die Module gibt es das Thema "Signalduino Version 3.3.1"
https://forum.fhem.de/index.php/topic,58397.0.html

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Invers am 07 Januar 2018, 13:25:06
Danke. Ich gehe dann dort hin.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Januar 2018, 15:12:41
ZitatBei einigen und auch den Neulingen könnte durchaus der Eindruck entstehen man BRAUCHT JETZT unbedingt einen CC1101.
Nein, dem ist nicht so, es kann weiterhin auch ein Superheterodyne (z.B. RXB6) Empfänger verwendet werden, mit dem funktiontioniert es auch sehr gut.
Ich habe den RXB6 und cc1101 im Einsatz. Ich habe den Eindruck, daß mit dem RXB6 die WH3080 und der FS10 Sender besser empfangen wird.
Bei den Temperatursensoren und Intertechno kann ich keine Unterschiede feststellen.

Die Vorteile vom cc1101 sind u.a.:
Es ist für Sender und Empfänger nur eine Antenne notwendig
Es kann z.B. für Somfy die Sendefrequenz verändert werden.
Es kann der Sendepegel erhöht werden.
Es kann der Empfangs RSSI angezeigt werden.
Es kann die nanocul Hardware verwendet werden   
Er ist evtl weniger empfindlich gegenüber Störungen, da er eine geringere Empfangsbandbreite hat.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: wthiess am 08 Januar 2018, 18:03:24
Hallo!

Meine Erfahrung ist das verschiedene cc1101 Versionen schlechter empfangen. Der RXB"8" ist Super. Jeder Sender in meiner Straße wird empfangen.

lg
Wolfgang
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 09 Januar 2018, 07:44:41
Die RXB Module sind halt nicht für 868MHz verwendbar...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: fhemfreund am 12 Januar 2018, 10:22:54
Zitat von: habeIchVergessen am 06 Januar 2018, 15:12:29
für ein WeMos D1  mini kompiliert

Sourcen hier (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb)

Hätte Interesse das auch mal nachzubauen. Welches Sendemodul hast du verwendet? Gibt es einen 'Schaltplan', bzw. Info wie was verschaltet wird?

Andreas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 12 Januar 2018, 11:05:56
ich habe ein CC1101 und RXB6-Set im Einsatz. Im Wiki zum miniCUL und SIGNALduino solltest du hinreichende Informationen finden, um entsprechende Geräte aufbauen zu können.

Im Marktplatz kann man auch das ein oder andere Modul kaufen. Hängt von deiner Bastelaffinität ab.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: fhemfreund am 12 Januar 2018, 11:26:34
Zitat von: habeIchVergessen am 12 Januar 2018, 11:05:56
ich habe ein CC1101 und RXB6-Set im Einsatz. Im Wiki zum miniCUL und SIGNALduino solltest du hinreichende Informationen finden, um entsprechende Geräte aufbauen zu können.

Ich bin davon ausgegangen, dass du den CC1101/RXB6 direkt an den Wemos ohne Nano angeschlossen hast - daher meine Frage... Ist das der Fall?

Andreas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 12 Januar 2018, 11:27:27
Zitat von: fhemfreund am 12 Januar 2018, 11:26:34
Ich bin davon ausgegangen, dass du den CC1101/RXB6 direkt an den Wemos ohne Nano angeschlossen hast - daher meine Frage... Ist das der Fall?

Andreas

Hier siehst du wie sowas aussieht: https://forum.fhem.de/index.php/topic,82558.0.html

Oben der Wemos und auf einer Adapterplatine unten drunter der CC1101
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 12 Januar 2018, 11:48:18
Zitat von: fhemfreund am 12 Januar 2018, 11:26:34
Ich bin davon ausgegangen, dass du den CC1101/RXB6 direkt an den Wemos ohne Nano angeschlossen hast - daher meine Frage... Ist das der Fall?

ja, den CC1101 betreibe ich direkt am Wemos D1. habe mir das CC1101 Wemos shield von locutus (s. Marktplatz) bestellt und selber gelötet. oder eben von gloob fertig nehmen. oder halt alles selber machen (inkl. Layout).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 Januar 2018, 21:45:33
Hi,

ich habe nun auch für einen CC1101 die SignalESP Version zur Verfügung gestellt:

Den Beitrag habe ich somit auch aktualisiert:
https://forum.fhem.de/index.php/topic,58396.msg740610.html#msg740610

Wie der cc1101 angebunden werden muss, habe ich im WIKI ergänzt?

https://wiki.fhem.de/wiki/SIGNALduino#Hardware

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 14 Januar 2018, 11:31:24
Zitat von: Sidey am 13 Januar 2018, 21:45:33
ich habe nun auch für einen CC1101 die SignalESP Version zur Verfügung gestellt:

Ich glaube da ist noch ein kleiner Schreibfehler im Post:

ZitatSIGNALESP_331rc1.bin (mit cc1101)

Soll doch bestimmt so aussehen:

ZitatSIGNALESP_331rc2.bin (mit cc1101)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 14 Januar 2018, 12:07:40
Zitat von: Sidey am 13 Januar 2018, 21:45:33
..
Wie der cc1101 angebunden werden muss, habe ich im WIKI ergänzt?
https://wiki.fhem.de/wiki/SIGNALduino#Hardware
Grüße Sidey
Hallo Sidey,

der Anschluß MOSI ist 2x drin. MIS soll das MISO sein ?

CC1101 Bezeichnung    ESP Pin
CLK    GPIO14
MOSI    GPIO13
MOSI    GPIO13
MIS    GPIO12
CSN    GPIO15
GDO0    GPIO4
GDO2    GPIO5

Jörg
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 14 Januar 2018, 12:15:53
2x MOSI mit gleichem GPIO (Typo).
ansonsten ist das die Standardbelegung für SPI + Interrupt-Pins CC1101
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Binnesmann am 16 Januar 2018, 15:51:48
Hallo Zusammen,

ich bin mir nicht sicher ob ich hier richtig bin, ich habe viele Seiten gelesen und den Überblick total verloren. Ich suche die Source Dateien um die Software für einen nanocul mit CC1101 in der Arduino IDE  zu kompilieren. Später soll das ganze auch mit Netzwerk funktionieren. Mein Problem dabei ist, dass ich im Moment noch kein FHEM benutzte und die Anleitungen, die ich gefunden habe, alle FHEM voraussetzen.

Bin für jeden Hinweis dankbar.

Gruß

Binnesmann
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 16 Januar 2018, 21:43:35
hier (https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33-cc1101-mcfirtbitfix) findest du die Sourcen für
- atmega328p (Arduino) + RXB6
- atmega328p + CC1101 (miniCUL)

hier (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101-cb) für
- ESP8266 + CC1101

es gibt wohl auch noch die Möglichkeit am ESP8266 ein Arduino + CC1101 (serielle Bridge) zu betreiben. Vermutlich wird der Arduino dann wie oben geflasht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Binnesmann am 17 Januar 2018, 13:13:53
Vielen Dank. Das hilft mir sehr. Ich werde mich da mal einarbeiten.

Gruß

Binnesmann
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: darkon am 18 Januar 2018, 21:28:45
Ich hatte mir den Signalduino mit einem Arduino Nano und den billigen Sender- und Empfangsmodulen gebaut. Dieser lief auch einwandfrei.

Jetzt habe ich den Signalduino aufgrund einer schwächeren Sendeleistung auf einen CC1101 433 Mhz umgebaut.
Dazu habe ich den Schaltplan vom Selbstbau CUL verwendet. Habe auch die Spannungsteiler mit 470/1000 Ohm verwendet.
Abschließend habe ich die Hardware auf CC1101 umgestellt und den Signalduino neu geflasht. Hat auch alles prima funktioniert.

Der Signalduino wird einwandfrei erkannt und steht auf "opened".

Leider werden jedoch keine Signale gesendet bzw. erkannt. Also der Arduino erkennt den Befehl, aber das CC1101 scheint nichts zu senden.
Habe alles nochmal geprüft und durchgemessen. Das einzige was mir aufgefallen ist, ist das der 3,3V Ausgang vom Arduino nur 2,4V liefert. Jedoch arbeitet der CC1101 laut Datenblatt ab 1,8V. Sollte also ausreichend sein.

Habe ich irgend etwas übersehen bzw. hat jemand noch eine Idee?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 18 Januar 2018, 22:01:43
Klingt sehr nach einem Verdrahtungsfehler, bzw. bist Du sicher die Kombi 470/1000 Ohm benutzt zu haben ?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: darkon am 18 Januar 2018, 22:42:36
Ich habe alles nochmal geprüft. Die Widerstände sind korrekt und der Rest scheint auch zu passen. Trotzdem tut sich immer noch nichts...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 18 Januar 2018, 22:43:27
Hast Du den SIGNALduino richtig geflasht?
Stürzt er auch ab, wenn der CC1101 nicht angebunden ist?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: darkon am 18 Januar 2018, 22:50:35
Habe ihn gerade nochmal neu geflasht. Jetzt bleibt er verbunden. Jedoch bekomme ich immer noch kein Signal.

Weiß jemand zufällig die Spannungspegel die an den einzelnen Punkten anliegen müssten?
Muss ih vielleicht noch etwas für das CC1101 einstellen? Frequenzbereich oder ähnliches?

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 19 Januar 2018, 09:45:10
Hi Sidey,

könnt ihr das bei Gelegenheit bitte mal anpassen:


72 MU Siro            Siro shutter # developModule. Siro is not in github or SVN available
72.1 MS Siro            Siro shutter # developModule. Siro is not in github or SVN available


Das Modul ist seit geraumer Zeit im SVN enthalten.

Danke und Gruss Byte09
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: darkon am 19 Januar 2018, 11:37:46
Habe gerade zum testen versucht die Vorabversion zu flashen.


set sduino flash https://drive.google.com/uc?export=download&id=1sIac8-Qhts4c7OEkFH72Lv6hhgbOadFQ


Seit dem blinkt die LED mit der Beschriftung L dauerhaft. Der Arduino Nano wird sowohl am Rasp als Signalduino erkannt, wie auch am PC.
Jedoch ist nun kein Upload mehr möglich.

Hat jemand eine Idee was passiert sein könnte?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 19 Januar 2018, 13:31:33
Ich würde gerne mein LCG Carrier-Board von locutus für den SIGNALDuino verwenden, da diese bereits einen cc1101 on-board hat.

Allerdings funktioniert die Firmware nicht out-of-the-box, da sich die Pinbelegung vom nanoCUL unterscheidet.
Einem selbstkompilieren steht leider das etwas eigenwillige Projektformat im Wege, welches sich in der  Arduino-IDE nicht übersetzen lässt.

Wer könnte mir da mit einem Binary aushelfen?

Pinbelegung LCG Carrier:
GD0 -> PD2 (INT0)
GD2 -> PD3 (INT1)
LED -> PD4 (T0)
433MHz -> PC0 (ADC0)

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 Januar 2018, 16:29:54
Bezüglich des LCG Carrier-Boards brauche ich alle Pins, dann könnte ich auch dafür eine Version bereitstellen.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 19 Januar 2018, 18:43:38
Danke.

MISO, MOSI & Co haben die gleiche Pinbelegung wie der nanoCUL
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 Januar 2018, 23:03:22
Zitat von: SusisStrolch am 19 Januar 2018, 13:31:33
Ich würde gerne mein LCG Carrier-Board von locutus für den SIGNALDuino verwenden, da diese bereits einen cc1101 on-board hat.

Ich stehe leider noch etwas auf dem Schlauch. Zu LCG finde ich nur LCrosseGatweway und dort ist immer ein RFM69 verbaut:
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Nano_LaCrosse_Gateway

Gibt es zu dem Board irgendwo eine Beschreibung?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: fhemfreund am 20 Januar 2018, 01:34:41
Habe jetzt mal einen Wemos mit dem CC1101 (868Mhz) verheiratet und in FHEM eingebunden. Dieser wird soweit auch in FHEM erkannt und ich empfange Daten. Allerdings werden diese scheinbar nicht richtig (?) decodiert und somit kein Device per Autocreate angelegt.

Hat jemand von den Spezi's hier eine Idee? Habe ich ev. noch ein Setting vergessen/falsch? Laut


https://wiki.fhem.de/wiki/SIGNALduino#Hardware


sollte LaCrosse via CUL_TX verarbeitet werden. Meine 868Mhz TX35DTH Sensoren werden jedoch nicht angelegt ...

Diese FW habe ich auf meinem Wemos leider nicht zum Laufen gebracht:


SIGNALESP_331rc2.bin (mit cc1101) von https://forum.fhem.de/index.php/topic,58396.msg740610.html#msg740610


Daher folgende FW genommen:


https://forum.fhem.de/index.php/topic,58396.msg743522.html#msg743522


List vom Device:


Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        192.168.0.26:23
   DMSG       u14#00010
   DevState   initialized
   DeviceName 192.168.0.26:23
   FD         36
   LASTDMSG   u14#00010
   MSGCNT     105
   NAME       HmWifiDui1
   NR         292
   PARTIAL   
   RAWMSG     MS;P0=-414;P1=659;P2=-649;P3=-92;P5=445;P6=-5646;D=56505050505050505050505050505050125050534;CP=5;SP=6;R=206;
   RSSI       -99
   STATE      opened
   TIME       1516406187.90805
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages 2018-01-20 01:15:48-MU;P0=-713;P1=433;P2=-406;P4=677;D=01212121212121212121212121212124012121212;CP=1;R=203;CP=1;R=203;#2018-01-20 01:17:43-MS;P0=-427;P1=644;P2=-630;P3=-91;P7=429;D=270707012707070707070707070707070701270730;CP=7;SP=6;R=204;#2018-01-20 01:17:44-MS;P0=112;P1=462;P2=-396;P3=-134;P4=692;P5=-669;P6=243;P7=-12815;D=121213421212121212121212121245121212126700;CP=1;SP=7;R=205;#2018-01-20 01:17:44-MU;P0=-438;P1=665;P2=-628;P3=-90;P5=124;P6=-265;P7=415;D=670707012701270701212707316707070707070735670121212707070127070;CP=7;R=208;CP=7;R=208;#2018-01-20 01:19:40-MU;P2=433;P3=-424;P4=629;P5=-648;D=012323232323232323234523232323454545234520;CP=2;R=206;CP=2;R=206;#2018-01-20 01:19:40-MS;P0=635;P1=-640;P2=426;P3=-425;P4=-92;P5=173;P6=-7590;P7=111;D=232323232323232323010104532323230123232670;CP=2;SP=6;R=206;#2018-01-20 01:21:36-MU;P1=-421;P2=423;P3=660;P4=-639;D=012121212134343421342121342121213421212120;CP=2;R=206;CP=2;R=206;#2018-01-20 01:21:36-MS;P0=439;P1=-406;P2=636;P3=-664;P4=-265;P5=-93;P6=141;P7=-8388;D=01010101010101010101010101230101042125672;CP=0;SP=7;R=206;#2018-01-20 01:21:36-MU;P1=-406;P2=437;P3=638;P4=-643;D=012121212121213421342121343421212121212120;CP=2;R=204;CP=2;R=204;
   version    V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Jan  6 2018 15:09:26
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-01-20 01:02:11   ccconf          freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB  (DataRate:5603.79Baud)
     2018-01-19 23:33:18   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2018-01-20 00:23:02   ccreg           C3E = 00 84 00 00 00 00 00 00
     2018-01-20 00:17:26   cmds             V R t X F S P C r W x e
     2018-01-20 01:01:56   config          MS=1;MU=1;MC=1
     2018-01-19 23:33:07   freeram         35472
     2018-01-20 01:21:03   ping            OK
     2018-01-20 01:02:03   state           opened
     2018-01-19 23:32:32   uptime          0 01:46:10
     2018-01-20 01:02:03   version         V 3.3.1-dev SIGNALESP cc1101 868MHz - compiled at Jan  6 2018 15:09:26
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     75
     8
     9
Attributes:
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      Funk
   room       System Module
   verbose    5


Auszug aus dem FHEM Log (mit Log Level 5)


2018.01.20 00:23:16 4: HmWifiDui1/keepalive ok, retry = 0
2018.01.20 00:23:35 4: HmWifiDui1/msg READredu: MS;P1=439;P2=-411;P3=663;P4=-678;P5=278;P6=-4855;D=212121212121212121212121212123412121212560;CP=1;SP=6;R=203;
2018.01.20 00:23:35 4: HmWifiDui1: Matched MS Protocol id 1 -> ConradRSL
2018.01.20 00:23:35 5: HmWifiDui1: Starting demodulation at Position 41
2018.01.20 00:23:35 5: HmWifiDui1: Found wrong signalpattern, catched 0 bits, aborting demodulation
2018.01.20 00:23:35 4: HmWifiDui1: Matched MS Protocol id 14 -> Heidemann HX
2018.01.20 00:23:35 5: HmWifiDui1: Starting demodulation at Position 41
2018.01.20 00:23:35 5: HmWifiDui1: Found wrong signalpattern, catched 0 bits, aborting demodulation
2018.01.20 00:23:35 4: HmWifiDui1/msg READredu: MU;P0=229;P1=-403;P2=451;P3=934;P5=616;P6=-672;D=012121212121213121215656215621212121212120;CP=2;R=204;CP=2;R=204;
2018.01.20 00:23:35 5: HmWifiDui1: applying filterfunc SIGNALduino_filterSign
2018.01.20 00:23:35 4: HmWifiDui1: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.01.20 00:23:35 5: HmWifiDui1: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.01.20 00:23:35 4: HmWifiDui1: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.01.20 00:23:35 5: HmWifiDui1: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.01.20 00:23:35 4: HmWifiDui1: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2018.01.20 00:23:35 5: HmWifiDui1: start pattern for MU Protocol id 29 -> HT12e remote mismatches, aborting
2018.01.20 00:23:35 4: HmWifiDui1: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.01.20 00:23:35 5: HmWifiDui1: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.01.20 00:23:35 4: HmWifiDui1: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.01.20 00:23:35 5: HmWifiDui1: Starting demodulation at Position 21
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 24
2018.01.20 00:23:36 5: HmWifiDui1: applying filterfunc SIGNALduino_compPattern
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 56 -> Celexon matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 56 -> Celexon mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 59 -> AK-HD-4 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 59 -> AK-HD-4 mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 2
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 2
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 20
2018.01.20 00:23:36 4: HmWifiDui1/msg READredu: MU;P0=92;P1=-148;P2=405;P3=-425;P5=601;P6=-687;P7=-91;D=232323232323232323232323232323562323232701565656235623235300;CP=2;R=206;CP=2;R=206;
2018.01.20 00:23:36 5: HmWifiDui1: applying filterfunc SIGNALduino_filterSign
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 1
2018.01.20 00:23:36 5: HmWifiDui1: dispatching bits: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
2018.01.20 00:23:36 4: HmWifiDui1: decoded matched MU Protocol id 20 dmsg u20#FFFFFFF8 length 32 RSSI = -99
2018.01.20 00:23:36 5: HmWifiDui1 Dispatch: u20#FFFFFFF8, test ungleich: disabled
2018.01.20 00:23:36 5: HmWifiDui1 Dispatch: u20#FFFFFFF8, -99 dB, dispatch
2018.01.20 00:23:36 5: HmWifiDui1: dispatch u20#FFFFFFF8
2018.01.20 00:23:36 4: SIGNALduino_unknown incomming msg: u20#FFFFFFF8
2018.01.20 00:23:36 4: SIGNALduino_unknown rawData: FFFFFFF8
2018.01.20 00:23:36 4: SIGNALduino_unknown Protocol: 20
2018.01.20 00:23:36 4: SIGNALduino_unknown converted to bits: 11111111111111111111111111111000
2018.01.20 00:23:36 4: Unknown, please report
2018.01.20 00:23:36 3: HmWifiDui1: Unknown code u20#FFFFFFF8, help me!
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 27 -> remote27 mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 28 -> IC Ledspot mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 29 -> HT12e remote mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 30 -> unitec47031 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 30 -> unitec47031 mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 43
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 37 -> Bresser 7009994 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 48
2018.01.20 00:23:36 5: HmWifiDui1: applying filterfunc SIGNALduino_compPattern
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 56 -> Celexon matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 56 -> Celexon mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 0
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 69 -> Hoermann matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 69 -> Hoermann mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 0
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: start pattern for MU Protocol id 72 -> Siro shutter mismatches, aborting
2018.01.20 00:23:36 4: HmWifiDui1: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2018.01.20 00:23:36 5: HmWifiDui1: Starting demodulation at Position 30
2018.01.20 00:24:16 4: HmWifiDui1/keepalive ok, retry = 0


Andreas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 20 Januar 2018, 07:32:47
 Beispielsweise dieses hier:

https://forum.fhem.de/index.php/topic,55705.0.html
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Januar 2018, 09:46:19
Ah verstehe,

Das LCG ist ein Board mit einem ESP Chip und an dem ESP hängt ein ATMega.
An dem AT Mega hängt ein cc1101.

Von dem ESP kommt man nicht direkt an den cc1101, was die einfachere Sache wäre. :)

Gut, compilieren der Firmware sollte leicht möchte sein. Wie man das dann flasht habe ich auf Anhieb noch nicht verstanden.

Gruß Sidey



Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 20 Januar 2018, 14:18:34
Das LGW dient nebenbei als WLAN/Serial Umsetzer - ähnlich dem ESPLink.
Das ATMega-Image wird vom ESP auf den ATMega geflasht - hochgeladen wird über eine spezielle URL.

Klappt prima 😄
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Januar 2018, 22:47:10
Zitat von: SusisStrolch am 20 Januar 2018, 14:18:34
Das LGW dient nebenbei als WLAN/Serial Umsetzer - ähnlich dem ESPLink.
Das ATMega-Image wird vom ESP auf den ATMega geflasht - hochgeladen wird über eine spezielle URL.

Klappt prima 😄

Okay, auf das LGW kommt nach meinen Recherchen ein miniCul.
Habe dafür nun mal die Firmware compiliert:

SIGNALduino_minicul-331rc3.hex
https://drive.google.com/uc?export=download&id=1q3rQ6C9g2kE34bgrkG9J1l9RT6OdmuE-


Flashen geht ja irgendwie über die serial Bridge, also den esp. Das müsstest Du mir am besten mal zeigen, welchen Befehl Du da absetzt. Dann könnte man das ins Modul vermutlich auch direkt einbauen.
Als Hardware solltest du nanoCC1101 wählen, damit auch die cc1101 Funktionen zur Verfügung stehen.

Die Baudrate ist im übrigen wie gehabt 57600, das könnte man aber ja noch nach oben hin anpassen, denn die 57600 sind nicht gerade optimal für 8 Mhz.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: PeMue am 20 Januar 2018, 23:20:31
Hallo Sidey,

Zitat von: Sidey am 20 Januar 2018, 22:47:10
Flashen geht ja irgendwie über die serial Bridge, also den esp. Das müsstest Du mir am besten mal zeigen, welchen Befehl Du da absetzt. Dann könnte man das ins Modul vermutlich auch direkt einbauen.
das Flashen geht über das Gateway selber, siehe https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x Abschnitt Subprozessor bzw. da Firmware flashen.
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex

Gruß PeMue

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Januar 2018, 23:34:15
Zitat von: PeMue am 20 Januar 2018, 23:20:31
Hallo Sidey,
das Flashen geht über das Gateway selber, siehe https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x Abschnitt Subprozessor bzw. da Firmware flashen.
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex

Gruß PeMue

Danke für den Hinweis.

Blöde frage, aber wo wird das aufgerufen, auf der shell eines Linux Servers? :)

Was ist 192.168.31.211 ? Ist das die IP Adresse vom ESP?
LGW-Addon.ino.hex wird dann vermutlich die zu flashende Firmware sein.

Ich vermute jetzt mal, es wird ein HTTP Get auf <IP vom ESP>/ota/addon.hex aufgerufen und  Content_Type:multipart/form-data als Header übergeben und im Anschluss noch das Hexfile.

Grüße Sidey

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 21 Januar 2018, 00:54:20
da wird ein HTTP-Post aufgerufen. Ziel ist der ESP (IP: 192.168.31.211).
Der Rest der URL ist fix

http://<IP ESP>/ota/addon.hex

im Modul KVPUDP.pm (https://forum.fhem.de/index.php/topic,45545.msg661203.html#msg661203) wird in perl ein HTTP-Post zusammengebaut (sub KVPUDP_Flash).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 21 Januar 2018, 09:39:00
Zitat von: habeIchVergessen am 21 Januar 2018, 00:54:20
da wird ein HTTP-Post aufgerufen. Ziel ist der ESP (IP: 192.168.31.211).
Der Rest der URL ist fix

http://<IP ESP>/ota/addon.hex

im Modul KVPUDP.pm (https://forum.fhem.de/index.php/topic,45545.msg661203.html#msg661203) wird in perl ein HTTP-Post zusammengebaut (sub KVPUDP_Flash).
Danke, dann habe ich das ja weitgehend richtig interpretiert.

Http Post dachte ich, wird in curl mit -X POST gesendet.

Mein 1. Gedanke war da auch das HTTPMod zu nutzen.
Insgesamt sollte sich das Flashen aber implementieren lassen.
Man müsste halt nur eine Hardware im Attribut definieren.
Alles andere ist ja entweder statisch (Pfad) oder kann aus dem Define entnommen werden (IP Adresse).

Gruß Sidey


Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 21 Januar 2018, 09:52:40
Empfang funktioniert anscheinend, die LED blitzt auch ab und an auf.
Muss mir die Logs mal im Detail anschauen was da so alles an Sensoren erkannt wird.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 22 Januar 2018, 17:44:40
Hallo,

hier https://forum.fhem.de/index.php/topic,58396.msg743522.html#msg743522 (https://forum.fhem.de/index.php/topic,58396.msg743522.html#msg743522) ist ja das File für einen SignalESP. Wie bekomme ich das aufgespielt? ESP Tools habe ich (Windows) aber an welche Adresse oder besser gesagt ab welcher Adresse muss ich die Datei flashen?

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 22 Januar 2018, 19:19:32
Hi,

Ich steh auf dem Schlauch.
Was meinst Du mit Adresse?

Ein Screenshot würde das bestimmt erklären.

Gruß Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 22 Januar 2018, 19:27:57
Zitat von: Bennemannc am 22 Januar 2018, 17:44:40
Hallo,

hier https://forum.fhem.de/index.php/topic,58396.msg743522.html#msg743522 (https://forum.fhem.de/index.php/topic,58396.msg743522.html#msg743522) ist ja das File für einen SignalESP. Wie bekomme ich das aufgespielt? ESP Tools habe ich (Windows) aber an welche Adresse oder besser gesagt ab welcher Adresse muss ich die Datei flashen?

Gruß Christoph

Adresse: 0x00

Aber ich empfehle die Firmware von hier: https://forum.fhem.de/index.php/topic,58396.msg740610.html#msg740610
Titel: SIGNALDuino auf ESP32
Beitrag von: hjgode am 22 Januar 2018, 19:54:26
Hallo

falls noch jemand den SignalDuino ohne USB Verbindung betreiben möchte, ich habe den 3.3.1 code auf den ESP32 mit WifiClient und Server portiert: https://github.com/hjgode/SignalDuino_esp32

Die Änderungen sind transparent, der ESP32 (zB ein DevelopKit C komaptibles Board) kann auch an 'nur' USB betrieben werden.

Gegenüber der Lösung mit einem Nano und einem ESP-01 spart man ein Board. Der ESP-01 verarbeitet Hardware-Interrupts zu langsam, aber der ESP32 hat damit keine Probleme.

Flashen ist nocht nicht angepasst. Müsste dann wohl über OTA gehen.

Have Fun

~Josef
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 22 Januar 2018, 21:19:46
Der ESP-01 hat ja gar keine Hardware Interrupts. :(
Hat der ESP-32 denn Hardware Interrupts?

Die Version für den ESP-32 finde ich gut. Werde ich versuchen einzubauen. Seit letzter Woche habe ich auch Hardware bei mir :)

Zu den geforkten Versionen des SIGNALduino oder SIGNALesp kann ich keinen Support geben.
Sie stellen auch in Frage, dass ich hier überhaupt noch eine Vorabversion anbiete.

@hjgode:
Du hast vom SIGNALduino ausgehend die Anpassung gemacht. Wäre es nicht besser gewesen den SIGNALesp als Basis zu nehmen?

Grüße Sidey


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 22 Januar 2018, 22:14:55
Danke für eure Rückmeldungen.
Musste wegen einem Fehler noch mal ein Update der Firmwares auf RC3 machen. :)

Links im Beitrag sind aktualisiert:
https://forum.fhem.de/index.php/topic,58396.msg743243.html#msg743243


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 23 Januar 2018, 06:39:22
Zitat von: Sidey am 22 Januar 2018, 21:19:46
Der ESP-01 hat ja gar keine Hardware Interrupts. :(
Hat der ESP-32 denn Hardware Interrupts?

Die Version für den ESP-32 finde ich gut. Werde ich versuchen einzubauen. Seit letzter Woche habe ich auch Hardware bei mir :)

Zu den geforkten Versionen des SIGNALduino oder SIGNALesp kann ich keinen Support geben.
Sie stellen auch in Frage, dass ich hier überhaupt noch eine Vorabversion anbiete.

@hjgode:
Du hast vom SIGNALduino ausgehend die Anpassung gemacht. Wäre es nicht besser gewesen den SIGNALesp als Basis zu nehmen?

Grüße Sidey

Hallo sidey

SignalESP unterscheidet sich stark vom SIGNALduino. Meine ESP32 Version erweitert lediglich die PatterDecoder Klasse um einen zusätzlichen Initializer und dann sind alle relevanten Ausgaben um die Ausgabe auf einem WifiClient ergänzt. Der Hauptcode in Signaduino_ESP32 wurde an den ESP32 angepasst und um WiFi erweitert. Das bedeutet, dass Du theoretisch den PatternDecoder übernehmen könntest. Ich denke, dass sich im wesentlichen nur dort von Zeit zu Zeit Änderungen ergeben. Die benutzten Libraries habe ich in den Programmpfad integriert.

Senden habe ich noch nicht getestet. Sollte aber kein Problem sein.

Am FHEM SignaulDuino Modul muss gar nichts angepasst werden. Nur Flashen wird halt nicht gehen.

Ich hatte auch eine Version mit MQTT angefangen. Allerdings müsste dann ein neues Signaduino FHEM Modul geschrieben werden. Deshalb habe ich das nicht weiterverfolgt.

~Josef
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Januar 2018, 07:04:59
Hi Hjgode,

Ich weiss nicht, auf welchem Branch du SignalESP und Signalduino dir angesehen hattest.

Ich bin dabei, sehr viele Dinge zwischen SignalESP und Signalduino zu verheiraten.
Die PatternDecoder Klasse habe ich bereits  zusammen führen können.

Der SignalESP hat halt die ganze WLAN und Initialisierungs Thematik.
Da es mit dem ESP-01, genauer gesagt in den Bibliotheken, ein delay beim WiFi Senden gibt, wird die Ausgabe über einen Puffer gesteuert.

Meine grobe Idee ist, dass ich die Anpassungen für den ESP-32 in den SignalESP Code einbaue und man mittels Define noch umschalten kann ob ESP-01 oder ESP-32.

Ob außer Pin Definitionen überhaupt etwas angepasst werden muss werde ich ja merken. Vielleicht sind einige deiner Anpassungen ja auch für den ESP-01 interessant.

Die Filtering.h benutze ich halt z.B. schon länger nicht mehr.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 07:54:19
Hallo,

die Firmware ist geflasht - wie kann ich da eine feste IP-Adresse eingeben. Bisher habe ich es nur geschafft den per WSP einzubinden.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 23 Januar 2018, 09:09:01
Interessant wäre eine Version ESP-32 + CC1101

Gruß, Sabine
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: rageltus am 23 Januar 2018, 10:25:42
Hi zusammen,

als Anfänger mit ESP eine doofe Frage: Es ist dann Möglich, den Signalduino via WLAN an eine beliebige Stelle im Haus zu platzieren? :-D Analog Mysensors?

Goil
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Januar 2018, 10:46:48
Zitat von: SabineT am 23 Januar 2018, 09:09:01
Interessant wäre eine Version ESP-32 + CC1101

kannst du doch bauen (Sourcen hier (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb) oder hier (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101-cb))

Zitat von: rageltus am 23 Januar 2018, 10:25:42
Es ist dann Möglich, den Signalduino via WLAN an eine beliebige Stelle im Haus zu platzieren?

so der Plan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 11:41:23
Hallo,

entweder bin ich zu blöd, oder es ist noch ein Bug in der Firmware. Wennich die Config ändere kommt immer
Should save config
connected...)
local ip
192.168.11.10
saving config
failed to open config file for writing
{

Warum kann er das Config nicht schreiben - ich versuche dem eine feste IP,und GW zuzuweisen.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Januar 2018, 12:37:55
such mal in SIGNALDUINO.ino nach

File configFile = SPIFFS.open("/config.json", "r");


im darauf folgendem if-Block ergänze bitte "configFile.close();" als letze Zeile

if (configFile) {
...
else {
DBG_PRINTLN("failed to load json config");
}
configFile.close();
}
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 23 Januar 2018, 13:01:20
Zitat von: Sidey am 22 Januar 2018, 21:19:46
Der ESP-01 hat ja gar keine Hardware Interrupts. :(
Woher hast Du denn diese Info?

Das interne WLAN ist mit dem NMI verheirated,
alle GPIOs (bis auf GPIO16) sind voll interruptfähig.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Januar 2018, 13:27:18
Zitat von: hjgode am 22 Januar 2018, 19:54:26
falls noch jemand den SignalDuino ohne USB Verbindung betreiben möchte, ich habe den 3.3.1 code auf den ESP32 mit WifiClient und Server portiert: https://github.com/hjgode/SignalDuino_esp32

Lässt sich beim beim ESP32 das WIFI auch deaktivieren, und dann per LAN anbinden. Z.B. mit einem W5500 Ethernet Network Modul:
https://www.ebay.de/itm/W5500-Ethernet-Network-Modul-TCP-IP-51-STM32-SPI-Schnittstelle-Fur-Arduino-New/272461200469?hash=item3f6ff3fc55:g:p~AAAOSwB09YNpwB

Wenn Du ein get freeram machst, wieviel freies RAM bekommst Du dann angezeigt?

Der ESP32 müsste doch eigentlich genügend RAM haben, um den Messagepuffer so groß zu machen, damit es zu keinem Messagepuffer überlauf mehr kommt. Dies würde auch die SignalDetectorClass deutlich vereinfachen.
Z.B. eine Messagepufferlänge von 1000 oder größer.
Können mit einem println oder write Befehl auch mehr als 1000 Zeichen ausgegeben werden?

Dann könnte die komplette Nachricht mit allen Wiederholungen an den 00_Signalduino übergeben werden und dort dann die Wiederholungen erkannt und ggf getrennt werden.

Nachtrag:
Ist der ESP32 schnell genug, damit er die Interrupts von den Signalflanken von zwei cc1101 verarbeiten kann?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Januar 2018, 15:51:07
Zitat von: Ralf9 am 23 Januar 2018, 13:27:18
Lässt sich beim beim ESP32 das WIFI auch deaktivieren

beim ESP8266 gibt es Wifi OFF und vermutlich auch für den ESP32

WiFi.mode(WIFI_OFF);
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 16:26:40
Hallo,

ich habe den SignalESP mit 3.3.1rc3.bin file geflasht. Direkt beim Starten kommt an der Konsole
dump EEPROM:
33 1d 07 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 20 77 69 6e
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found
mounting FS...
failed to mount FS
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESP537799
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started

Warum kann das FS nicht gemounted werden? Wenn er das Config.File nicht lesen kann, ist es klar das er das auch nicht beschreiben kann. Irgendwie verzweifel ich gerade daran. Ich probiere jetzt schon den ganzen Tag rum, aber er will einfach nicht. Wer kann mir da helfen?

Gruß Christoph

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SabineT am 23 Januar 2018, 16:37:12
Zitat von: habeIchVergessen am 23 Januar 2018, 10:46:48
kannst du doch bauen (Sourcen hier (https://github.com/habeIchVergessen/SIGNALESP/tree/dev-cc1101-cb) oder hier (https://github.com/RFD-FHEM/SIGNALESP/tree/dev-cc1101-cb))
Naja, ich bin davon ausgegangen, dass die für den ESP8266 sind und nicht optimiert für den ESP32
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 19:46:49
Hallo,

ich habe die Sourcen von habeIchVergessen genommen. Der Sketch läuft durch, ich komme auf die Configseite, die Werte werden anscheinend gespeichert - aber er verbindet sich nicht mit dem Netzwerk. Hier ist der Log von der Konsole
dump config register:
29 2E 3F 07 D3 91 FF 04 45 00 00 0F 00 1E C4 EC
8C 22 02 22 F8 47 07 30 04 76 6C 03 40 91 87 6B
F8 56 10 A9 0A 20 0D 41 00
CCVersion=0x14
CCPartnum=0x0
CC1101 found (rev. 01)
mounting FS...
mounted file system
reading config file
opened config file
{"ip":"192.168.11.10","gateway":"192.168.11.1","subnet":"255.255.255.0"}
parsed json
setting custom ip from config
192.168.11.10
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESP537799
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Scan done
*WM: Cubie-Wifi
*WM: -50
*WM: Home_Router_N
*WM: -53
*WM: Sent config page
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: WiFi save
*WM: static ip
*WM: 192.168.11.10
*WM: static gateway
*WM: 192.168.11.1
*WM: static netmask
*WM: 255.255.255.0
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 192.168.11.10
*WM: Already connected. Bailing out.
Should save config
connected...)
local ip: 192.168.11.10
saving config
{
  "ip": "192.168.11.10",
  "gateway": "192.168.11.1",
  "subnet": "255.255.255.0"
}CC1100_PKTCTRL0=0 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=46 vs EEPROM IOCFG2=13
cc1101 is not correctly set. Please do a factory reset via command e


Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Januar 2018, 20:41:07
Hi Bennemanc,

Was für ein ESP Board hast Du denn?


Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 21:05:09
Wemos D1 mini mit einer Adapterplatine wo der CC1101 drauf ist.
Habe ich hier im Forum so fertig gekauft.
Wenn ich das richtig deute, meldet der sich immer beim falsche (keine Ahnung wo die Daten stehen) Netzwerk an. Da hatte ich mal WPS ausprobiert. Ich kann im LOG auch nicht sehen, das er versucht sich woanders anzumelden.
Connected successful to SSID 'Home_Router_N'
mounting FS...
mounted file system
reading config file
opened config file
{"ip":"192.168.10.60","gateway":"192.168.10.200","subnet":"255.255.255.0"}
parsed json
setting custom ip from config
192.168.10.60
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
*WM: IP Address:


Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Januar 2018, 21:52:55
Wie hast Du ihm denn mitgeteilt mit welchem WLAN er sich verbinden soll?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 23 Januar 2018, 21:57:19
Na, er macht ja sein eigenes Wlan (AP Mode) auf. Dort kann ich bei dem obersten Punkt ein Wlan auswählen und den Key eingeben. Dann sollte der sich auch in dieses Netz einloggen - aber genau das seint er nicht zu machen.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Januar 2018, 23:02:14
Ich habe das Problem auch und wir sind glaube auch nicht die einzigsten, welche das Problem haben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 23 Januar 2018, 23:07:22
Moin
Hallo Christoph, das dachte ich auch zuerst, da das eigene Netz des ESP immer noch da ist. Es dauert so ca. 20 Sekunden, dann meldet er nach dem Start, dass er mit meinem Netz verbunden ist.
Warum das eigene Netz noch da ist??? Ist bei anderen ESP Implementierungen anders, aber schadet nur bedingt!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Januar 2018, 23:17:57
Zitat von: Sidey am 23 Januar 2018, 23:02:14
Ich habe das Problem auch und wir sind glaube auch nicht die einzigsten, welche das Problem haben.
habe eine Bugfix hochgeladen (oder s. hier (https://forum.fhem.de/index.php/topic,58396.msg754235.html#msg754235)).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 24 Januar 2018, 06:54:10
Zitat von: Sidey am 22 Januar 2018, 21:19:46

@hjgode:
Du hast vom SIGNALduino ausgehend die Anpassung gemacht. Wäre es nicht besser gewesen den SIGNALesp als Basis zu nehmen?

Grüße Sidey

Ich wollte dass der code möglichst nahe an SignalDuino ist. Wie gesagt, auuser dem Main ino wurde nur die PatternDecoder Klasse angepasst, damit ich dort ein WifiClient object übergeben kann, dass dann ebenfalls als Ausgabe benutzt wird.
Mein Code basiert auf der 3.1.0 und benötigt keine Anpassung des FHEM 00_SIGNALduino Moduls, ähnlich wie die Abindung des Signalduino Nano mit ESPlink.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 24 Januar 2018, 12:46:11
Das hilft leider auch nicht. Ich habe die Quellen neu gezogen und man das Debuging unten wieder reingenommen.
Reading values fom eeprom

dump EEPROM:
33 1d 0d 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00
10 b0 71 f7 c4 30 23 b9 00 07 00 18 14 6c 07 00
90 87 6b f8 56 11 e9 2a 00 1f 41 00 ff ff ff ff
00 84 00 00 00 00 00 00
SRES Started
POR Done
CCVersion=0x14
CCPartnum=0x0
CC1101 found (rev. 01)

Try connecting to WiFi with SSID 'Home_Router_N'
.
Connected successful to SSID 'Home_Router_N'
mounting FS...
mounted file system
reading config file
opened config file
{"ip":"192.168.11.10","gateway":"192.168.11.1","subnet":"255.255.255.0"}
parsed json
setting custom ip from config
192.168.11.10
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: ESP537799
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Sent config page
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: WiFi save
*WM: static ip
*WM: 192.168.11.10
*WM: static gateway
*WM: 192.168.11.1
*WM: static netmask
*WM: 255.255.255.0
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: 192.168.11.10
*WM: Already connected. Bailing out.
Should save config
connected...)
local ip: 192.168.11.10
saving config
{
  "ip": "192.168.11.10",
  "gateway": "192.168.11.1",
  "subnet": "255.255.255.0"
}CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled

Er meldet sich beim Start direkt auf "Home_Router_N" an - richtig wäre "Cubie-Wifi". Wenn ich dann die Config aufrufe (192.168.4.1) sehe ich beide Netzwerke. Wenn ich dann das richtige wähle und den Schlüsseleingebe funktioniert alles anscheinend normal, aber das Netzwerk wird nicht gewechselt. Auch nach einem Reset meldet er sich sofort wieder beim falsche AP an. Das Netzwerk und der Schlüssel stehen irgendwo falsch drin und werden immer wieder genommen.

Habe Home_Router_N mal abgeschaltet. Dann schreibt er das richtige über die Webpage rein. Allerdings verbindet er sich damit nicht, weil er anscheinend DHCP versucht - die Config wurde noch nicht gelesen. Da auf Cubie-Wifi kein dhcp-Server läuft, kann er sich nicht verbinden.

Gruß Christoph

BTW. Sollten wir für den SignalESP nicht einen eigenen Threat aufmachen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 24 Januar 2018, 20:09:41
ZitatBTW. Sollten wir für den SignalESP nicht einen eigenen Threat aufmachen?

Ich hab mal ein neues Thema erstellt:
https://forum.fhem.de/index.php/topic,83273.0.html

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 Januar 2018, 21:09:13
Zitat von: SusisStrolch am 23 Januar 2018, 13:01:20
alle GPIOs (bis auf GPIO16) sind voll interruptfähig.

Das sind aber leider alles Software Interrupts und keine echten HW Interrupts

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 24 Januar 2018, 22:00:03
Wie kommst Du darauf?
Die Pegel/Flankenänderungen an den GPIOs lösen direkt einen Interrupt aus.
Nix mit "Trap X" oder so - auch kein Polling über einen Timer - echte Hardware-Interrupts also.

Natürlich können sie - im Gegensatz zum NMI welcher vom WLAN Modul verwendet wird - gesperrt und freigegeben werden.

Ich empfehle da nen Blick ins Datenblatt (http://espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf)
4.1 General Purpose Input/Output Interface (GPIO)
...
Each GPIO can be configured with internal pull-up or pull-down, or set to high impedance,
and when configured as an input, the data are stored in software registers; the input can
also be set to edge-trigger or level trigger CPU interrupts. In short, the IO pads are bi-
directional, non-inverting and tristate, which includes input and output buffer with tristate
control inputs.


Beispiel für negativ flankengetriggerten Interrupt:

...
        pinMode(Settings.TaskDevicePin1[event->TaskIndex], INPUT_PULLUP);
        pulseinit(Settings.TaskDevicePin1[event->TaskIndex], event->TaskIndex);
...

void pulseinit(byte Par1, byte Index)
{
  // Init IO pins
  String log = F("Power Counter: Init");
  addLog(LOG_LEVEL_INFO,log);

  switch (Index)
  {
    case 0:
      attachInterrupt(Par1, pulse_interrupt1, FALLING);
      break;
      ...
  }
}

/*********************************************************************************************\
* Pulse Counter IRQ handlers
\*********************************************************************************************/
void pulse_interrupt1()
{
  pulsecheck(0);
}
...

/*********************************************************************************************\
* Check Pulse Counters (called from irq handler)
\*********************************************************************************************/
void pulsecheck(byte Index)
{
  unsigned long PulseTime=millis() - pulseTimePrevious[Index];
  unsigned long PulseTimePrevious=millis();
  ...
}

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 Januar 2018, 22:08:50
Zitat von: SusisStrolch am 24 Januar 2018, 22:00:03
Wie kommst Du darauf?

Hmm, hatte ich gelesen. Und da die Interrupts nicht so gleichmäßig wie bei einem Arduino ausgelöst werden erschien mir das auch stimmig.
Ob das vielleicht an der Arduino8266 Bibliothek lag und vor geraumer Zeit da die Register für Interrupts nicht gesetzt wurden?


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: SusisStrolch am 24 Januar 2018, 22:42:27
Nun, setzen und initialisieren musste schon selbst - das nimmt dir der Aduino-Core nicht ab.
Und - niemals ever never auf die Idee kommen, yield oder printxxx in der IRQ-Routine verwenden.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 24 Januar 2018, 23:34:03
Zitat von: Bennemannc am 24 Januar 2018, 12:46:11
Das hilft leider auch nicht. Ich habe die Quellen neu gezogen und man das Debuging unten wieder reingenommen.

Das wird als bug/issue (https://github.com/tzapu/WiFiManager/issues/480) geführt!
Weil bereits eine Verbindung besteht, wird beim Speichern die neue nicht übernommen.

Workaround:
- Wifi aus (router)
- neu konfigurieren
- Wifi an
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Bennemannc am 25 Januar 2018, 07:36:25
Das habe (siehe oben) ich gestern auch hinbekommen, nur verbindet er sich jetzt bein Neustart nicht mit dem anderen Netz. Er versucht anscheinend mit dhcp eine Adresse zu bekommen. Da in dem Netz keine dhcp Server läuft scheitert er daran. Die Config mit den Festen IP's ist zu diesem Zeitpunkt noch nicht gelesen worden. Deshalb bleibt er in der "while" Schleife hängen und geht nicht weiter. Ich stelle mir das so vor.
Versuch eine Verbindung aufzubauen (20 mal oder so) - wenn keine Verbindung zustande kommt, lesen der Config / IP Daten und erneuter Versuch der Verbindung mit den Config Daten.

Gruß Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 29 Januar 2018, 07:52:27
Hi

so, ich habe die Signalduino firmware 3.3. nun auch auf den ESP32 portiert: https://github.com/hjgode/SIGNALduino330_esp32

Senden ist nicht getestet,,,

Gruss

~Josef
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 Januar 2018, 10:06:51
Hi Hjgode,

Von welchem Branch hast Du den Fork gemacht?

Sieht mir leider etwas veraltet aus.

Gruß Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 29 Januar 2018, 13:50:58
von https://github.com/RFD-FHEM/SIGNALDuino/
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 01 Februar 2018, 16:07:02
Hi,

hat noch jemand das Problem dass im FHEM bei den SIGNALDUINO devices kein PING, UPTIME, VERSION mehr geht?
Es kommt einfach keine Antwort mehr.

Der SIGNALDUINO funktioniert, nur diese Anfragen werden nicht mehr beantwortet.
Man kann den GET Knopf drücken und das wars.

Das habe ich bei all meinen SIGNALDUINO devices, völlig egal ob arduino nano oder signal esp.
Ich weiß dass es früher ging und bei den CULS gehen diese Befehle immer noch.

Kann das jemand bestätigen?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 01 Februar 2018, 22:16:13
Hi Stefan,

Ja das Problem habe ich leider auch schon festgestellt.
Bislang aber gedacht, es läge nur an mir.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Intruder1956 am 01 Februar 2018, 22:29:00
bei mir klappt es
uptime: 3 14:18:24
ping: OK
version: V 3.3.2-dev SIGNALduino cc1101 - compiled at Jan 7 2018 19:11:11

Gruß Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 01 Februar 2018, 22:31:13
Die Readings werden aktualisiert.
Es kommt nur in fhemweb keine direkte Rückmeldung

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Intruder1956 am 01 Februar 2018, 22:39:24
doch, macht sich kleines Fenster in der Mitte auf.
und erst jetzt sehe ich das es auch in den readings steht  ;)

Gruß
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 02 Februar 2018, 00:17:52
Das ist ja komisch.
Bei mir genau dasselbe wie bei Sidey.
Fenster geht nicht auf.
Habe auch schon verschiedene Browser probiert.

Intruder welche Version von FEHM hast du denn?
Ich habe gerade vorgestern aktualisiert.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 02 Februar 2018, 07:03:11
Popup fenster sollten wohl gehen:
siehe attachements

Vielleicht mal anderen Browser testen, Cookies löschen oder so...

~josef
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Intruder1956 am 02 Februar 2018, 08:39:44
moin stefanru,
ich habe gerade ein Update von Fhem gemacht.
das Popup-Fenster öffnet sich trotzdem, alles gut bei mir

Gruß
Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 02 Februar 2018, 09:59:10
Bei mir tut sich auch nix auf dem Bildschirm.
Version: V 3.3.1-RC2 SIGNALduino - compiled at Jan 6 2018 00:45:45

Aber wie Sidey schon sagt: Bei einem reload der Seite wird der Zeitstempel in den Readings aktualisiert.
War aber früher anders, soweit ich mich erinnere.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 02 Februar 2018, 18:00:56
Kommt denn ein 'Fenster; wenn in CMD Eingabe ein "Version" eingegeben wird? Dies benutzt dieselbe Schnittstelle.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Intruder1956 am 02 Februar 2018, 18:55:41
ja, läuft

Gruß Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 02 Februar 2018, 19:24:30
Ich habe auch mal ein update gemacht:
Latest Revision: 16063
fhem.pl                  16050 2018-01-30 20:21:02Z rudolfkoenig


Bei mir kommen die Popup-Fenster auch wie gewohnt.
Evtl ist es Browser abhängig. Ich habe es mit Firefox und chrome getestet.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: hjgode am 02 Februar 2018, 19:30:49
Die dialog fenster für Get Abfragen, wie Version etc., in SIGNALduino werden zum einen über asyncOutput realisiert und enden dann über jquery-min in einem ui-dialog (widget) der FHEM Web Seite. Wenn jquery-min.js und jquery-min.css nicht zusammen passen, kann es sein, das der dialog nicht angezeigt wird. Dies kann auch mit dem Browser zusammenhängen, da der jquery code einige parameter beim Browser abfragt. Also mal einen anderen Browser testen (IE, Chrome, Firefox).

Wenn die Version Abfrage in der CMD Line einen Dialog anzeigen kann, sollte es auch kein Problem beim Get Version im SignalDuino Modul sein. Wenn allerdings auch der CMD Line Version Befehl keinen Dialog zeigt, dann liegt es wie gesagt an einer Misch-Installation (mal die Chrom Developer Tools drauf loslassen) oder am Browser (was man ebenfals in Javascript Fehlern in den jeweiligen Browser Devloper Tools sehen können sollte).

Generell sollten bei jeder Frage zu einem Problem die Versionsnummern der beteiligten Komponenten angegeben werden.

Gruss

Josef

EDIT: Möglicherweise liegt es auch am verwendeten Theme (Select Style). Ich habe irgendwas mit dark.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 02 Februar 2018, 21:53:41
Hi,

danke für die vielen Antworten.
Aber leider stellt es sich bei mir anders da.

Popups bei anderen Geräten gehen.
Z.B. Das uptime Popup beim nanoCUL funktionieren.

Beim Signalduino geht alles was eine korrekte Antwort liefert nicht.
Z.B. es kommt kein Popup an einem Sduino mit CC1101 wenn ich get ccconf klicke. Das reading wird aber aktualisiert.
Mache ich das selbe bei einem Signalduino ohne CC1101 kommt durchaus die Fehlermeldung "This command is only available with a cc1101 receiver"

Also alle Antworten vom Sduino werden nicht im Popup dargestellt.
NanoCUL, Fduino gehen.

Version der Sduinos:
ESP Sduino: V 3.3.1-rc3 SIGNALESP - compiled at Jan 24 2018 21:48:34
Sduino mit cc1101: V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 12 2017 23:04:38
Sduino ohne cc1101:    V 3.3.1-dev SIGNALduino - compiled at Jan 3 2017 23:59:32

Schon sehr merkwürdig...

Gruß,
Stefan

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 03 Februar 2018, 08:50:06
Hallo Stefan,

welche 00_SIGNALduino.pm verwendest Du?
Falls es die aktuelle dev-r33 ist, hast Du es schon mit der 00_SIGNALduino.pm aus dem fhem update (svn) versucht?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 03 Februar 2018, 12:35:44
Bei mir läuft die
00_SIGNALduino.pm    10488 2017-11-19 11:00:00Z v3.3.3-dev

Kein Popup weder mit Chrome noch IE.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: trebron106 am 03 Februar 2018, 13:57:14
Setze mal das Attribute

do_not_notify  auf 1

So klappt es bei mir.

Gruß
Klaus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 03 Februar 2018, 14:07:48
Hi treborn,

ja das hat geholfen.
Warum muss ich das auf einmal setzten?
War früher doch auch nicht nötig, und was bewirkt es? Die Commadref sagt dazu nichts.

Ach so ja ich benutze dev-r33
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 03 Februar 2018, 14:49:25
Zitat von: trebron106 am 03 Februar 2018, 13:57:14
Setze mal das Attribute
do_not_notify  auf 1
So klappt es bei mir.

Demnach verwendest Du auch die v3.3.3-dev.
Hast Du es schon mal mit der 00_SIGNALduino.pm aus dem fhem update (svn) versucht?

Nachtrag:
Du kannst auch in der v3.3.3-dev die Zeile 5194 auskommentieren, dies müsste auch ausreichen:
#DoTrigger($dev,"$name $loglevel: $text");

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 03 Februar 2018, 16:47:53
Ok, alles klar.

Ist das ein Bug oder ein Feature? ;-)
Was bewirkt das do not notify? Ist es schlecht wenn ich das gesetzt lasse?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 03 Februar 2018, 17:18:28
Eher ein Bug.

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 Februar 2018, 16:44:50
Beim Kompilieren mit der Arduino IDE bekomme ich immer diese warnings, es funktioniert zwar trotzdem, ich finde es aber unschön.
Habt Ihr dies auch?

sketch/cc1101.h: In function 'uint8_t cc1101::cmdStrobe(uint8_t)':
sketch/cc1101.h:62:112: warning: return-statement with no value, in function returning 'uint8_t {aka unsigned char}' [-fpermissive]
  #define wait_Miso()       while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return; miso_count--; }      // wait until SPI MISO line goes low
                                                                                                                ^
sketch/cc1101.h:171:3: note: in expansion of macro 'wait_Miso'
   wait_Miso();                                    // wait until MISO goes low
   ^
sketch/cc1101.h:62:112: warning: return-statement with no value, in function returning 'uint8_t {aka unsigned char}' [-fpermissive]
  #define wait_Miso()       while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return; miso_count--; }      // wait until SPI MISO line goes low
                                                                                                                ^
sketch/cc1101.h:173:3: note: in expansion of macro 'wait_Miso'
   wait_Miso();                                    // wait until MISO goes low
   ^
sketch/cc1101.h: In function 'uint8_t cc1101::readReg(uint8_t, uint8_t)':
sketch/cc1101.h:62:112: warning: return-statement with no value, in function returning 'uint8_t {aka unsigned char}' [-fpermissive]
  #define wait_Miso()       while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return; miso_count--; }      // wait until SPI MISO line goes low
                                                                                                                ^
sketch/cc1101.h:180:3: note: in expansion of macro 'wait_Miso'
   wait_Miso();                                    // wait until MISO goes low
   ^



Verursacht wird dies von dieser Zeile:
#define wait_Miso() while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return; miso_count--; } // wait until SPI MISO line goes low

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 11 Februar 2018, 17:05:02
Hallo Ralf,
lese nur nebenbei mit:

Das Makro liefert kein Returnwert, dann ist das resultierende Warning schon korrekt
warning: return-statement with no value

if(miso_count==0) return 0 else return 1
oder Ähnliches als Workaround?

Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 Februar 2018, 17:29:05
Zitatif(miso_count==0) return 0 else 1
oder Ähnliches als Workaround?
Nein dies bringt nichts, da bekomme ich eine andere warning.

Wenn ich das return durch break ersetze, dann sind die warnings weg.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 11 Februar 2018, 18:03:42
Zitat von: Ralf9 am 11 Februar 2018, 17:29:05
Wenn ich das return durch break ersetze, dann sind die warnings weg.

Ja, das Macro hat keinen Return wert, da es nur eine Schleife ist.
Das "Return" sollte die Schleife + die Funktion aus der es aufgerufen wird beenden, da ja irgendwas nicht stimmt, wenn die Zeit für wait_miso abgelaufen ist.

Ob das return in dem Macro aber die Funktion, in der es verwendet wird, überhaupt beendet habe ich nicht getestet oder es vergessen :)


break beendet definitiv nur die Schleife und der Rest des Programmes macht weiter egal ob der counter abgelaufen ist oder nicht.

Grüße Sidey

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 11 Februar 2018, 18:37:49
Vermute das Macro soll eine Art Inline-Code darstellen.
Mann könnte aber mögllicherweise auf eine ganz normale Funktion mit Returnwert  umstellen,
wenn es nicht andere Notwendigkeiten dafür gäbe?
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 11 Februar 2018, 19:02:43
Hi juergs,

Die Idee mit dem Macro war, dass die Funktion in der das Macro aufgerufen wird beendet wird.

Mit einer Funktion geht das so halt nicht.

Mit einer Inline Funktion oder einem template geht das meines Wissens nach auf keinen Fall.

Gut Programmiert ist das aber nicht. Passt wohl eher in die Kategorie Hack ;)

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 Februar 2018, 19:10:58
ZitatDas "Return" sollte die Schleife + die Funktion aus der es aufgerufen wird beenden, da ja irgendwas nicht stimmt, wenn die Zeit für wait_miso abgelaufen ist.

Ok, nun ist es klar. Damit es sauber ist, werden 2 Marco benötigt:
#define wait_Miso()       while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return 255; miso_count--; }      // wait until SPI MISO line goes low
#define waitV_Miso()      while(isHigh(misoPin) ) { static uint8_t miso_count=255;delay(1); if(miso_count==0) return; miso_count--; }      // wait until SPI MISO line goes low



Bei readReg wird dann 255 zurückgegeben, aber es wird kein cc1101_Deselect() mehr ausgeführt.
uint8_t readReg(const uint8_t regAddr, const uint8_t regType) {       // read CC1101 register via SPI
cc1101_Select();                                // select CC1101
wait_Miso();                                    // wait until MISO goes low
sendSPI(regAddr | regType);                     // send register address
uint8_t val = sendSPI(0x00);                    // read result
cc1101_Deselect();                              // deselect CC1101
return val;
}


Und hier z.B. wird dann das waitV_Miso() verwendet:
void writeReg(const uint8_t regAddr, const uint8_t val) {     // write single register into the CC1101 IC via SPI
cc1101_Select();                                // select CC1101
waitV_Miso();                                    // wait until MISO goes low
sendSPI(regAddr);                               // send register address
sendSPI(val);                                   // send value
cc1101_Deselect();                              // deselect CC1101
}


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Binnesmann am 20 Februar 2018, 08:23:15
Hallo zusammen,

ich möchte den Signalduino ohne Thema benutzen. Gibt es eine Doku zu den Rohdaten die vom Signalduino gesendet werden? Ich würde die Daten gerne in Python verarbeiten. Vielleicht hat ja jemand einen Sketch für mich.

Ich habe schon 45 Seiten gelesen, aber die Flut ist hier ja enorm. Daumen hoch für die Entwickler.

Gruß Binnesmann
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Februar 2018, 18:16:01
Zitat von: Binnesmann am 20 Februar 2018, 08:23:15
ich möchte den Signalduino ohne Thema benutzen. Gibt es eine Doku zu den Rohdaten die vom Signalduino gesendet werden?

Leider gibt es keine vollständige Beschreibung dazu.
Es ist aktuell auch so, dass die Protokoll Definitionen im FHEM Modul eingebaut bin.
Ich wollte diese schon mal auslagern, aber ganz so einfach ist es dann doch nicht gewesen.

Vom Prinzip müsstest Du das ganze FHEM Modul in Python übersetzen und von den FHEM Schnittstellen lösen.

Ich habe in der Vergangenheit durchaus schon daran gedacht, dass es besser wäre die Protokoll Logik aus dem FHEM Modul zu extrahieren und einen allgemeingültigen Connector zu definieren, der dann auch unabhängig von FHEM funktioniert.
Aber das ist eine ordentliche Portion Arbeit :(

Ob Python da das richtige ist, weiss ich nicht.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Binnesmann am 20 Februar 2018, 21:06:59
Hallo Sidey,

Danke für deine Antwort. Ich habe mir das mit dem Übersetzen schon so gedacht. Wollte das aber umgehen. Python oder C ist das was ich so leidlich kann. Wobei Python den Vorteil des Skriptes hat und nicht jedes mal kompiliert werden muss.

Ich werde mich da also mal durchwurschteln. Ich hatte nur die Hoffnung, dass die einzelnen Rückgabewerte definiert sind und ich diese Parameter leicht umrechnen kann. Die Übersetzung der Empfangenen Daten ist so schnell gemacht. Was die Daten dann im einzelnen bedeuten muss dann später betrachtet werden.

Ich mach mich mal ans Werk.

Gruß Binnesmann
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Februar 2018, 21:42:46
Hi,

also vom Prinzip kannst Du mit den Parse Routinen anfangen.
Da kommen erst ein paar Regex Einträge und der Datensalat wird in einzelne Variablen zerlegt.
Titel: Dooya Wandsender DC229 / DC230
Beitrag von: uelpenich am 21 Februar 2018, 21:07:18
Hallo,
gestern hatte ich diese Frage im Thema "98_Dooya Modul Version 1.13" gestellt und darauf aufmerksam gemacht worden dass sie besser hier hin gehört.
https://forum.fhem.de/index.php/topic,49523.msg769952.html#msg769952 (https://forum.fhem.de/index.php/topic,49523.msg769952.html#msg769952)

Ich setze Rolladen7 Rohrmotore mit DC229 bzw. DC230 Wandsender ein.
Die Rolladenmotore kann ich problemlos mit Signalduino und dem Modul DOOYA steuern.
Signalduino:      V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
                        # $Id: 00_SIGNALduino.pm 10488 2018-02-14 14:32:00Z v3.3.3-dev $
98_Dooya.pm: # $Id: 98_Dooya.pm 1013 2017-08-26 21:00:00Z Jarnsen_darkmission_ralf9 $

Signalduino Readings:
ccconf            freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
ccpatable       C3E = 00 84 00 00 00 00 00 00 => 5_dBm
cmds             V R t X F S P C r W x e
config            MS=1;MU=1;MC=1
ping              OK
state            opened
version          V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50


Mein Problem: Viele meiner Wandsender (nicht alle) werden nicht (immer) als P16 DOOYA Shutter erkannt, sondern meistens als unbekanntes u57 oder auch u40 Gerät.
2018-02-20 16:45:09 SIGNALduino signalduino_0_433 DMSG u57#556B5555B6D56AD5AB
2018-02-20 16:45:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u57#556B5555B6D56AD5AB
2018-02-20 16:45:09 SIGNALduino signalduino_0_433 DMSG u57#556B5555B6D56AD55B
2018-02-20 16:45:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u57#556B5555B6D56AD55B
2018-02-20 16:45:10 Dooya Dooya_1111100100000111101010100111_1 parsestate: on
2018-02-20 16:45:10 Dooya Dooya_1111100100000111101010100111_1 closed
2018-02-20 16:45:10 Dooya Dooya_1111100100000111101010100111_1 position: 200
2018-02-20 16:45:10 Dooya Dooya_1111100100000111101010100111_1 exact: closed
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 DMSG u40#41EA9C4CC
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41EA9C4CC
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 DMSG u40#41EA9C4C8
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41EA9C4C8
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 DMSG u57#556B5555B6D56AD5AB
2018-02-20 16:45:10 SIGNALduino signalduino_0_433 UNKNOWNCODE u57#556B5555B6D56AD5AB
2018-02-20 16:45:11 SIGNALduino signalduino_0_433 DMSG u57#556B5555B6D56AD55B
2018-02-20 16:45:11 SIGNALduino signalduino_0_433 UNKNOWNCODE u57#556B5555B6D56AD55B
Die Rolladen lassen sich problemlos mit den ausgelesenen DOOYA IDs steuern.
Feststellung: die erkannten u57 Datenpakete sind sehr reproduzierbar und stabil.
Fragen:
Sind die Protokolle u57, u40 und d16 so ähnlich, so dass es bei ungenauen Sender zu diesen Verwechslungen kommen kann?
Kann ich die CC1001 Empfängereinstellungen so verändern, dass DOOYA sicher erkannt wird? (ich will auch InterTechno empfangen, was zur Zeit problemlos funktioniert)
Tritt das Problem auch an anderer Stelle auf?
Was kann ich weiterhin versuchen, um zu besseren Ergebnissen zu kommen?
Titel: Dooya Wandsender DC229 / DC230
Beitrag von: uelpenich am 21 Februar 2018, 21:10:02
Die Idee von Darkmission, MC abzuschalten hat nicht geholfen:

2018-02-21 20:36:09 Dooya Dooya_1111100100000111011101100111_1 parsestate: off
2018-02-21 20:36:09 Dooya Dooya_1111100100000111011101100111_1 open
2018-02-21 20:36:09 Dooya Dooya_1111100100000111011101100111_1 position: 0
2018-02-21 20:36:09 Dooya Dooya_1111100100000111011101100111_1 exact: open
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#EECE222
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#EECE222
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#41DD9C444
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41DD9C444
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#41DD9C440
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41DD9C440
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#ECE220
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#ECE220
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#41DD9C444
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41DD9C444
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 DMSG u40#41DD9C478
2018-02-21 20:36:09 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#41DD9C478
2018-02-21 20:36:11 SIGNALduino signalduino_0_433 DMSG u40#DC478
2018-02-21 20:36:11 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#DC478
2018-02-21 20:36:11 SIGNALduino signalduino_0_433 DMSG u40#D9C478
2018-02-21 20:36:11 SIGNALduino signalduino_0_433 UNKNOWNCODE u40#D9C478
Titel: Antw:Dooya Wandsender DC229 / DC230
Beitrag von: Sidey am 21 Februar 2018, 21:28:26
Zitat von: uelpenich am 21 Februar 2018, 21:10:02
Die Idee von Darkmission, MC abzuschalten hat nicht geholfen:

Poste doch bitte mal die Raw Messages dazu (Ab Verbose 4 zu sehen).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: uelpenich am 21 Februar 2018, 23:35:02
Hallo Sidey,
danke für die Hilfe.

Bei signalduino verbose 5 sieht man vor lauter Bäumen den Wald nicht mehr.

Zwei Dinge habe ich geändert:

Hier das Ergebnis eines Tastendrucks.
2018.02.21 23:00:14 3: signalduino_0_433 Attr: whitelist_IDs
2018.02.21 23:00:14 3: signalduino_0_433 sduinoIdList: whitelistIds=3,16
2018.02.21 23:00:14 3: signalduino_0_433 sduinoIdList: blacklistIds=
2018.02.21 23:00:14 3: signalduino_0_433 sduinoIdList: development=
2018.02.21 23:00:14 3: signalduino_0_433: IDlist MS 3
2018.02.21 23:00:14 3: signalduino_0_433: IDlist MU 16
2018.02.21 23:00:14 3: signalduino_0_433: IDlist MC
2018.02.21 23:00:32 4: signalduino_0_433/keepalive ok, retry = 0
2018.02.21 23:00:35 4: signalduino_0_433/msg READ: MU;P0=240;P1=-4184;P2=311;P3=-2170;P5=-1172;P6=116;D=01212323232123232121232321012323210125632;CP=2;R=220;
2018.02.21 23:00:36 4: signalduino_0_433/msg READ: MU;P0=114;P1=-2150;P2=234;P3=354;P4=-4166;P6=-9232;P7=176;D=0121343131343431313434313134343424343434240131313134313131343431367;CP=3;R=219;
2018.02.21 23:00:44 4: signalduino_0_433/msg READ: MS;P1=465;P3=348;P4=-1986;P5=-3929;P6=-9185;D=16341514151514151514141515141414141414141414141415141414151414151415141514;CP=1;SP=6;R=229;O;
2018.02.21 23:00:44 4: signalduino_0_433/msg READ: MS;P0=-1962;P1=472;P2=-3927;P3=-9200;P4=329;D=13401210121210121210101212101010101010101010101012101010121010121012101210;CP=1;SP=3;R=230;O;
2018.02.21 23:00:45 2: Got message for undefined device 049d65, and failed to guess type from msg 'Ack' - ignoring
2018.02.21 23:00:52 4: signalduino_0_433/msg READ: MU;P0=-11268;P1=919;P2=-1026;P3=-546;P4=424;P5=-92;P6=112;D=012121343424313434212434343431562134342124312124313421343424313434243434343434312434343134343424343124343121243121342121212134243124;CP=4;R=225;
2018.02.21 23:00:52 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:00:52 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:00:52 4: signalduino_0_433/msg READ: MU;P0=-32001;P1=910;P2=-1046;P3=-553;P4=409;D=01212134342431343421243434343121343421243121243431213434243134342434343434343124343431343434243431243431212431213421343421343421343424;CP=4;R=223;
2018.02.21 23:00:52 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:00:52 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:00:58 4: signalduino_0_433/msg READ: MU;P0=-32001;P1=4737;P2=-1530;P3=340;P4=-735;P5=696;P6=-378;D=012345634345634563434343434345656345634345656565656343434343434345634343456343434561234563434563456343434343434565634563434565656565634343434343434563434345634343456123456343456345634343434343456563456343456565656563434343434343456343434563434345;CP=3;R=27;
2018.02.21 23:00:58 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:00:58 5: signalduino_0_433: Starting demodulation at Position 3
2018.02.21 23:00:58 5: signalduino_0_433: dispatching bits: 0 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1
2018.02.21 23:00:58 4: signalduino_0_433: decoded matched MU Protocol id 16 dmsg P16#4A069F0111 length 40 RSSI = -60.5
2018.02.21 23:00:58 5: signalduino_0_433 Dispatch: P16#4A069F0111, test ungleich: disabled
2018.02.21 23:00:58 5: signalduino_0_433 Dispatch: P16#4A069F0111, -60.5 dB, dispatch
2018.02.21 23:00:58 5: signalduino_0_433: dispatch P16#4A069F0111
2018.02.21 23:00:58 4: Dooya_Parse: rawData = 4A069F0111 length: 10
2018.02.21 23:00:58 4: Dooya_Parse: converted to bits: 0100101000000110100111110000000100010001
2018.02.21 23:00:58 4: Dooya_Parse: device ID: 0100101000000110100111110000
2018.02.21 23:00:58 4: Dooya_Parse: Channel: 1
2018.02.21 23:00:58 4: Dooya_Parse: Cmd: 0001  Newstate: off
2018.02.21 23:00:58 4: Dooya_Parse: deviceCode: 0100101000000110100111110000_1
2018.02.21 23:00:58 3: Dooya_set: handled command off --> move :off:  newState :0:
2018.02.21 23:00:58 4: signalduino_0_433/msg READ: MU;P0=-32001;P1=339;P2=-15708;P3=-735;P4=699;P5=-376;P6=4732;P7=-1540;D=012131313134545134513134545454545131313131313134513131345454545136713451313451345131313131313454513451313454545454513131313131313451313134545454513671345131345134513131313131345451345131345454545451313131313131345131313454545451;CP=1;R=27;
2018.02.21 23:00:58 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:00:58 5: signalduino_0_433: Starting demodulation at Position 67
2018.02.21 23:00:58 5: signalduino_0_433: dispatching bits: 0 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 0
2018.02.21 23:00:58 4: signalduino_0_433: decoded matched MU Protocol id 16 dmsg P16#4A069F011E length 40 RSSI = -60.5
2018.02.21 23:00:58 5: signalduino_0_433 Dispatch: P16#4A069F011E, test ungleich: disabled
2018.02.21 23:00:58 5: signalduino_0_433 Dispatch: P16#4A069F011E, -60.5 dB, dispatch
2018.02.21 23:00:58 5: signalduino_0_433: dispatch P16#4A069F011E
2018.02.21 23:00:58 4: Dooya_Parse: rawData = 4A069F011E length: 10
2018.02.21 23:00:58 4: Dooya_Parse: converted to bits: 0100101000000110100111110000000100011110
2018.02.21 23:00:58 4: Dooya_Parse: device ID: 0100101000000110100111110000
2018.02.21 23:00:58 4: Dooya_Parse: Channel: 1
2018.02.21 23:00:58 4: Dooya_Parse: Cmd: 0001  Newstate: off
2018.02.21 23:00:58 4: Dooya_Parse: deviceCode: 0100101000000110100111110000_1
2018.02.21 23:00:58 3: Dooya_set: handled command off --> move :off:  newState :0:


Das zu "P16#4A069F0111" decodierte Signal ist das gewünschte. Alle von FHEM an 4A069F0_1 gesendeten Befehle kommen richtig an und werden ausgeführt.
Fragen: Was sind die anderen Protokolle? Sendet der Wandsender soviel (Schrott)? oder ist bei mir die Umgebung so verseucht?

Hier ist ein weiterer Mitschnitt:2018.02.21 23:05:19 4: signalduino_0_433/msg READ: MU;P0=374;P1=-2076;P3=-4123;P4=92;D=010303010101030101030301010303010103030303030303030101014;CP=0;R=220;
2018.02.21 23:05:20 4: signalduino_0_433/msg READ: MU;P0=164;P1=-2070;P2=376;P3=-4131;P4=-9140;P5=-27472;D=012121212321212123232124212323212121232125;CP=2;R=220;
2018.02.21 23:05:20 4: signalduino_0_433/msg READ: MS;P1=368;P2=-2074;P3=-4134;P4=-9134;P6=192;D=14121313121212131212131312121313121213631313131313131212121213121212131312;CP=1;SP=4;R=219;
2018.02.21 23:05:20 4: signalduino_0_433/msg READ: MU;P0=184;P1=-2083;P2=345;P3=-4161;P4=-9168;P5=112;D=0121212323212421232321212123212123232121232321215;CP=2;R=220;
2018.02.21 23:05:20 4: signalduino_0_433/msg READ: MU;P0=226;P1=-4135;P2=373;P3=-2155;P4=-9128;D=01212121212121212323232321232323212123240;CP=2;R=220;
2018.02.21 23:05:24 4: signalduino_0_433/msg READ: MU;P0=-3934;P1=472;P2=-580;P3=356;P4=-1965;P5=140;P6=-21396;D=0121234101410101410101414101014141414141456;CP=1;R=229;
2018.02.21 23:05:24 4: signalduino_0_433/msg READ: MS;P0=-1972;P2=-3938;P3=463;P4=-9188;P5=331;D=34503230323230323230303232303030303030303030303032303030323030323032303230;CP=3;SP=4;R=230;O;
2018.02.21 23:05:24 4: signalduino_0_433/msg READ: MS;P0=-1978;P1=454;P2=-3934;P3=-9134;P4=338;D=13401210121210121210101212101010101010101010101012101010121010121012101210;CP=1;SP=3;R=227;
2018.02.21 23:05:35 4: signalduino_0_433/keepalive ok, retry = 0
2018.02.21 23:05:53 4: signalduino_0_433/msg READ: MU;P0=-29540;P1=904;P2=-1044;P3=-552;P4=427;D=0121213434243134342124343434312134342124312124313424312434313434243434343434312431342434343134212434312124313434212124313421212434;CP=4;R=225;
2018.02.21 23:05:53 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:05:53 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:05:53 4: signalduino_0_433/msg READ: MU;P0=-2504;P1=909;P2=-1043;P3=-551;P4=421;D=01212134342431343421243434343121343421243121243431243124343134342434343434343124313424343431342124343121243134342124343431243431243434;CP=4;R=225;
2018.02.21 23:05:53 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:05:53 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:05:53 4: signalduino_0_433/msg READ: MU;P0=-1012;P1=919;P3=-570;P4=402;P5=156;P6=-22964;P7=112;D=0101013434043134340104343434310134340104356507013404343431340104343101043134340101340134340434343434;CP=4;R=222;
2018.02.21 23:05:53 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:05:53 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:05:55 4: signalduino_0_433/msg READ: MU;P0=-28520;P1=362;P2=-2108;P3=-4139;P5=-9148;P6=204;D=012131312121213121213131213121312121313131313131313121212121312121312131215126;CP=1;R=217;
2018.02.21 23:05:55 4: signalduino_0_433/msg READ: MU;P0=134;P1=-4156;P2=366;P3=-2069;P4=-31936;P5=-9156;D=012123232321232321212321232123232121212124232321232123252321212323232123232121232123210;CP=2;R=221;
2018.02.21 23:05:55 4: signalduino_0_433/msg READ: MU;P0=204;P1=-2074;P2=368;P3=-4151;P4=-9136;P5=132;D=01212323232323232323212121212321212321232124212323212121232121232321232123212123232323232323235;CP=2;R=219;
2018.02.21 23:05:56 4: signalduino_0_433/msg READ: MS;P1=-2129;P2=366;P3=-4135;P4=-9146;D=24212323212121232121232321232123212123232323232323232121212123212123212321;CP=2;SP=4;R=221;
2018.02.21 23:05:59 4: signalduino_0_433/msg READ: MS;P1=447;P3=337;P4=-1986;P5=-3942;P6=-9189;D=16341514151514151514141515141414141414141414141415141414151414151415141514;CP=1;SP=6;R=229;O;
2018.02.21 23:05:59 4: signalduino_0_433/msg READ: MS;P0=-1971;P1=474;P2=-3933;P3=-9204;P4=330;D=13401210121210121210101212101010101010101010101012101010121010121012101210;CP=1;SP=3;R=228;O;
2018.02.21 23:06:30 4: signalduino_0_433/msg READ: MU;P0=-25388;P1=359;P2=-2064;P3=-4150;P5=208;D=012131312121213121213131213121312121313135;CP=1;R=216;
2018.02.21 23:06:30 4: signalduino_0_433/msg READ: MU;P0=96;P1=-4140;P2=386;P3=-2067;P4=256;P5=-9164;P6=140;D=0121212121232323232123234123212325232121232323212323212123212321236;CP=2;R=220;
2018.02.21 23:06:30 4: signalduino_0_433/msg READ: MU;P0=140;P1=-4152;P2=367;P3=-2071;P4=-27500;D=012323232123232121232123212323212121212124;CP=2;R=220;
2018.02.21 23:06:30 4: signalduino_0_433/msg READ: MS;P1=-2100;P2=358;P3=-9166;P4=-4164;D=23212424212121242121242421242124212124242424242424242121212124212124212421;CP=2;SP=3;R=220;
2018.02.21 23:06:31 4: signalduino_0_433/msg READ: MU;P0=158;P1=-2063;P2=370;P3=-4138;P4=-9140;D=01212121232121232123212421232321212123212123232123212321212323232323232323212121210;CP=2;R=221;
2018.02.21 23:06:31 4: signalduino_0_433/msg READ: MU;P0=160;P1=-4141;P2=376;P3=-2070;P4=-9168;P5=-29524;D=0123232123212324232121232323212323212123252121212121232323232123232123210;CP=2;R=220;
2018.02.21 23:06:33 4: signalduino_0_433/msg READ: MU;P0=-9140;P1=702;P2=-376;P3=341;P4=-732;P5=4726;P6=-1546;D=01234123434343434341212341234341212121212343434343434341234343412343434125634123434123412343434343434121234123434121212121234343434343434123434341234343412563412343412341234343434343412123412343412121212123434343434343412343434123434341;CP=3;R=15;
2018.02.21 23:06:33 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:33 5: signalduino_0_433: Starting demodulation at Position 75
2018.02.21 23:06:33 5: signalduino_0_433: dispatching bits: 0 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1
2018.02.21 23:06:33 4: signalduino_0_433: decoded matched MU Protocol id 16 dmsg P16#4A069F0111 length 40 RSSI = -66.5
2018.02.21 23:06:33 5: signalduino_0_433 Dispatch: P16#4A069F0111, test ungleich: disabled
2018.02.21 23:06:33 5: signalduino_0_433 Dispatch: P16#4A069F0111, -66.5 dB, dispatch
2018.02.21 23:06:33 5: signalduino_0_433: dispatch P16#4A069F0111
2018.02.21 23:06:33 4: Dooya_Parse: rawData = 4A069F0111 length: 10
2018.02.21 23:06:33 4: Dooya_Parse: converted to bits: 0100101000000110100111110000000100010001
2018.02.21 23:06:33 4: Dooya_Parse: device ID: 0100101000000110100111110000
2018.02.21 23:06:33 4: Dooya_Parse: Channel: 1
2018.02.21 23:06:33 4: Dooya_Parse: Cmd: 0001  Newstate: off
2018.02.21 23:06:33 4: Dooya_Parse: deviceCode: 0100101000000110100111110000_1
2018.02.21 23:06:33 3: Dooya_set: handled command off --> move :off:  newState :0:
2018.02.21 23:06:33 4: signalduino_0_433/msg READ: MU;P0=-1552;P1=335;P2=-5928;P4=-746;P5=687;P6=-396;P7=4717;D=01214561414561456141414141414565614561414565656565614141414141414561414145614141456701456141456145614141414141456561456141456565656561414141414141456141414561414145670145614145614561414141414145656145614145656565656141414141414145614141456141414567014561;CP=1;R=15;O;
2018.02.21 23:06:33 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:33 5: signalduino_0_433: Starting demodulation at Position 85
2018.02.21 23:06:33 5: signalduino_0_433: dispatching bits: 0 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1
2018.02.21 23:06:33 4: signalduino_0_433: decoded matched MU Protocol id 16 dmsg P16#4A069F0111 length 40 RSSI = -66.5
2018.02.21 23:06:33 5: signalduino_0_433 Dispatch: P16#4A069F0111, test gleich
2018.02.21 23:06:33 4: signalduino_0_433 Dispatch: P16#4A069F0111, Dropped due to short time or equal msg
2018.02.21 23:06:33 4: signalduino_0_433/msg READ: MU;P0=-734;P1=338;P2=701;P3=-385;D=010231023101010101010232310231010232323232310101010;CP=1;R=15;
2018.02.21 23:06:33 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:33 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:06:34 4: signalduino_0_433/msg READ: MU;P0=-378;P1=335;P2=-740;P3=696;P4=4736;P5=-1548;D=01212301230121212121212303012301212303030303012121212121212301212123030303012451230121230123012121212121230301230121230303030301212121212121230121212303030301;CP=1;R=15;
2018.02.21 23:06:34 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:34 5: signalduino_0_433: Starting demodulation at Position 79
2018.02.21 23:06:34 5: signalduino_0_433: dispatching bits: 0 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 0
2018.02.21 23:06:34 4: signalduino_0_433: decoded matched MU Protocol id 16 dmsg P16#4A069F011E length 40 RSSI = -66.5
2018.02.21 23:06:34 5: signalduino_0_433 Dispatch: P16#4A069F011E, test ungleich: disabled
2018.02.21 23:06:34 5: signalduino_0_433 Dispatch: P16#4A069F011E, -66.5 dB, dispatch
2018.02.21 23:06:34 5: signalduino_0_433: dispatch P16#4A069F011E
2018.02.21 23:06:34 4: Dooya_Parse: rawData = 4A069F011E length: 10
2018.02.21 23:06:34 4: Dooya_Parse: converted to bits: 0100101000000110100111110000000100011110
2018.02.21 23:06:34 4: Dooya_Parse: device ID: 0100101000000110100111110000
2018.02.21 23:06:34 4: Dooya_Parse: Channel: 1
2018.02.21 23:06:34 4: Dooya_Parse: Cmd: 0001  Newstate: off
2018.02.21 23:06:34 4: Dooya_Parse: deviceCode: 0100101000000110100111110000_1
2018.02.21 23:06:34 3: Dooya_set: handled command off --> move :off:  newState :0:
2018.02.21 23:06:34 4: signalduino_0_433/msg READ: MU;P0=-13908;P1=108;P2=-2051;P3=445;P4=-3933;P5=-9172;P7=284;D=2323432343234323532343234343234343232347032321;CP=3;R=226;
2018.02.21 23:06:34 4: signalduino_0_433/msg READ: MS;P0=451;P1=-3926;P2=-1983;P3=-9139;P4=338;D=03420102010102010102020101020202020202020202020201020202010202010201020102;CP=0;SP=3;R=229;
2018.02.21 23:06:35 4: signalduino_0_433/keepalive ok, retry = 0
2018.02.21 23:06:36 4: signalduino_0_433/msg READ: MU;P0=-27732;P1=911;P2=-1038;P3=-579;P4=430;P5=164;P6=-16516;P7=114;D=0121213434243134342124343434312134342124356737;CP=4;R=226;
2018.02.21 23:06:36 4: signalduino_0_433/msg READ: MU;P0=112;P1=-561;P2=904;P3=-1058;P4=244;P5=415;D=01234121535151512153235151232351512153232;CP=5;R=223;
2018.02.21 23:06:36 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:36 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:06:36 4: signalduino_0_433/msg READ: MU;P0=-1045;P1=917;P2=-533;P3=437;P4=136;D=012323010321010323210123032321232303232324;CP=3;R=226;
2018.02.21 23:06:36 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:36 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:06:36 4: signalduino_0_433/msg READ: MU;P0=-559;P1=898;P2=-1063;P3=416;P4=156;P5=-22356;D=0121030323010303212303030301210303212301245;CP=3;R=222;
2018.02.21 23:06:36 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:36 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting
2018.02.21 23:06:36 4: signalduino_0_433/msg READ: MU;P0=92;P1=-1008;P2=156;P4=427;P5=-535;P6=914;D=01214545456541614545616145456541616541654545454545414;CP=4;R=225;
2018.02.21 23:06:36 4: signalduino_0_433: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.02.21 23:06:36 5: signalduino_0_433: start pattern for MU Protocol id 16 -> Dooya shutter mismatches, aborting



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 22 Februar 2018, 20:15:54
Hallo,

meine Rollladenmotoren nutzen das RIO-Funksystem. Nach Angabe des Herstellers ist es ein hauseigenes Protokoll, keiner der bekannten Standards. Die Frequenz ist 868 MHz. Sowohl auf dem Motor als auch der Fernbedienung ist RC15 angegeben. Ich habe eine Fernbedienung für max. 8 Motoren vom Typ HS 8 RIO im Einsatz. Ziel ist es die Rollläden über FHEM anzusteuern.

Ich habe einen V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 im Einsatz. Der cc1101 ist die kleine 868 MHz-Version mit der gewendelten Antenne.
ccconf: freq:868.000MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Ich habe viele Mitschnitte dessen gesammelt, was meine mitgelieferte Fernbedienung lt. SIGNALduino aussendet, auf github gepostet und erste hilfreiche Hinweise bekommen.

Die Sender senden ein Protokoll das vom SIGNALduino als MU halbwegs brauchbar verarbeitet werden kann.

Die Mitschnitte zeigen ein Format
P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=0123232323232323232323232453265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626;

Ralf9 hat mich auf die Spur gebracht, dass die Sequenzen mit einer Präambel "01232323232323232323232324" beginnen und danach ein sich wiederholender Steuercode kommt. Senden kann man so etwas mit
set mySIGNALduino raw SC;;SR;;P0=-32001;;P1=15874;;D=01;;SR;;R=20;;P0=-32001;;P1=15874;;P2=-364;;P3=447;;P4=4060;;P5=-762;;P6=853;;D=23232323232323232323232453265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626;;

Ich habe die Mitschnitte unter dem Blickwinkel einer sauberen Präambel analysiert/gefiltert und den rohen Steuercode extrahiert. Der Parameterblock unterscheidet sich von Command zu Command, scheint aber als Grundraster so etwas in der Größenordnung wie
P0=-32000;P1=16000;P2=-400;P3=400;P4=4000;P5=-800;P6=800
zu haben. Wenn ich die real gemessenen Parameter mit den Zahlen des Steuercodes ausmultipliziere, komme ich immer auf ca. 90 mSec. Ich scheine also auf einem brauchbaren Weg zu sein.

Die Liste der vermutlich brauchbaren Codes habe ich per Script durchgetestet und die extrahiert, bei denen der Rollladenmotor reagierte. Das gab dann sozusagen die Erstaussattung der Steuercodes.

Als erstes habe ich dann festgestellt, dass vom Obergeschoss aus der entfernteste Rollladenmotor nicht reagierte. Eine Verlagerung meines Raspi mit dem SIGNALduino (=keine Betondecke mehr) brachte den Erfolg. Die Sendeleistung habe ich vorsorglich auf 10dB erhöht.

Ich beobachte ferner, dass die Rollladenmotoren nicht stabil reagieren. Verschiedene Standorte des Raspi/SIGNALduino im Erdgeschoss, teils Antenne nach oben gerichtet, teils horizontal, brachten unterschiedliche Ergebnisse. Den Wiederholungsfaktor für den Steuercode muss ich teilweise auf 30-50 erhöhen (50 = 5 Sekunden senden). Außerdem habe ich das Gefühl, als ob der SIGNALdunio bei zuviel Last den Sendebtetrieb einstellt. Führe ich denselben Befehl Stunden später aus reagiert der Rollladenmotor.

Nun meine Fragen:

VG plin



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 Februar 2018, 20:53:36
beim Senden würde ich P0 auf -16000 setzen und 2x 0 in den Daten benutzen (wenn ich mich nicht täusche, ist da ein Limit im Sketch).

mal ein wenig mit den Daten gespielt (es geht ja nur um ein Muster)

P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324

53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL
1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100
AD99 79A2 9FBC B7FC


also die Frequenz kleiner 0 (z.B. -800) ist ein l (long low), > 0 L (long high)
sS sind die 400-ter (short low/high)

weiter angenommen es werden immer 2 Frequenzen verglichen (lS => 1 und sL => 0)

interessant währen noch die Taste und wie oft diese gedrückt wurde (z.B. im Abstand von 15 s mehrfache die gleiche)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 22 Februar 2018, 21:31:24
Zitat von: habeIchVergessen am 22 Februar 2018, 20:53:36
interessant währen noch die Taste und wie oft diese gedrückt wurde (z.B. im Abstand von 15 s mehrfache die gleiche)
Na ja, ich habe viele Tasten oft gedrückt :-)

Es sind 6 Rolllädenmotoren, jeden kann ich mit up/stop/down ansteuern (also 6x8 Messreihen). Da der SIGNALduino nicht immer direkt im Log den MU-Code ausgewiesen hat, habe ich alles mögliche an "Press-Mustern" getestet (mal lang, mal kurz, mal kleiner/größerer Abstand ...). Bei Nutzung der realen Fernbedinung reagieren die Rolllädemotoren nach einer gefühlten halben Sekunde.

Ich hab also genug Material mitgeschnitten, um über Statisitken den vermutlich richtigen Code zu ermitteln.

Der Ansatz mit Übersetzung in "lSsLlSsLlS..." ist einer den ich noch nicht verfolgt habe.  Bei der Länge der einzelnen Impulse gibt es Schwankungen, deshalb bin ich mir nicht sicher, ob ich einen Mittelwert vergleichbarer Code-Reihen ansetzen sollte.

Das mit der 001 werde ich testen.

P.S. ich werde eine zweiten SIGNALduino bauen und kann dann ermitteln, ob die beiden SIGNALduinos die realen Signale identisch interpretieren bzw. ob das was der eine sendet sich vom Signal der Fernbedienung unterscheidet. Der cc1101 ist noch unterwegs ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 Februar 2018, 22:04:55
ein Anfang wäre auch mit einer FB die Bits für die Tasten zu identizfizieren. Schauen, ob ein Tastendruck immer die gleiche Nachricht auslöst (du hattest erwähnt, das eine Nachricht zu unterschiedlichen Zeitpunkten eine Reaktion der Rollos auslöst), usw.

dann die Erkenntnisse mit den anderen FBs überprüfen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 22 Februar 2018, 22:10:58
Es ist etwas komplizierter. Die Fernbedienung hat 4 Tasten. Mit der ersten wähle ich rollierend den Rollladenmotor aus. Die drei anderen sind dann up/stop/down.

Ich werde jetzt mal die bekannten Codes nach deinem Beispiel übersetzen und schauen was dabei herauskommt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: misux am 22 Februar 2018, 22:23:29
 :-[

Hallo!

Ich habe eine Problem mit meinem neulich erworbenem signalDuino... Bekomme nicht wirklich irgend ein Signal empfangen. Habe es letzte Woche gekauft, es ist ein selbstbau. Ich möchte allerdings ausschließen das es an mir liegt das er nicht läuft... Könnte bitte jemand drüber schauen ob wenigstens die List einträge i.O. sind...

Wäre sehr dankbar.

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9ITHZZV-if00-port0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9ITHZZV-if00-port0@57600
   FD         25
   ITClock    250
   LASTDMSG   nothing
   NAME       signalDuino
   NR         85
   NR_CMD_LAST_H 8
   PARTIAL   
   STATE      opened
   TIME       1519327681
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-RC2 SIGNALduino cc1101 - compiled at Jan  6 2018 00:45:28
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-02-22 19:20:43   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-02-22 22:20:04   ping            OK
     2018-02-22 20:28:03   state           opened
     2018-02-22 20:28:03   version         V 3.3.1-RC2 SIGNALduino cc1101 - compiled at Jan  6 2018 00:45:28
   XMIT_TIME:
     1519328111
     1519328115
     1519328117
     1519328120
     1519328134
     1519328143
     1519328148
     1519328173
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
   msIdList:
   muIdList:
     72
Attributes:
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   whitelist_IDs 72
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 22 Februar 2018, 22:37:44
sieht eigentlich gut aus.

hast du mal verbose 4 probiert? zumindest im Log-File sollte dann etwas erscheinen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 23 Februar 2018, 16:23:05
Hallo habeIchVergessen,

Zitat von: habeIchVergessen am 22 Februar 2018, 20:53:36

P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324

53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626

lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL
1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0

10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100
AD99 79A2 9FBC B7FC


also die Frequenz kleiner 0 (z.B. -800) ist ein l (long low), > 0 L (long high)
sS sind die 400-ter (short low/high)

weiter angenommen es werden immer 2 Frequenzen verglichen (lS => 1 und sL => 0)

Ich habe mir einige meiner Messreihen angeschaut. Neben lS und sL finde ich auch andere Kombinationen.

Sehe ich es richtig, dass
D.h. die Kombinationen sl, ls, SL ,LS sind falsche Werte und nicht weiter zu betrachten.

Kann ich dem SIGNALduino eigentlich die Parameter P0-P6 vorgeben auf die er lauschen soll?

VG plin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Februar 2018, 16:43:44
Zitat von: plin am 23 Februar 2018, 16:23:05
Sehe ich es richtig, dass
so war meine Arbeitshypothese.

Zitat von: plin am 23 Februar 2018, 16:23:05
Kann ich dem SIGNALduino eigentlich die Parameter P0-P6 vorgeben auf die er lauschen soll?
ist aus meiner Sicht nicht möglich.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 23 Februar 2018, 18:19:00
Eine Analyse weiter:

Rollladen 4 down
73DC BC21 3F74 B7FC
05FC E15D 3F74 B7FC
0B8B A0AE 3F74 B7FC
4CD1 BF45 3F74 B7FC
6EAE 04DA 3F74 B7FC
BC56 C68E 3F74 B7FC
CFC0 6175 3F74 B7FC
E7F9 8B24 3F74 B7FC

Rollladen 2 down
9EB5 A2F8 7F74 B7FC

Rollladen 3 down
CA10 58B5 BF74 B7FC

Für "down" kristallisiert sich  B7FC oder 74 B7FC in der letzten Gruppe heraus. "up" scheint auf B7FA zu enden.

Die Dritte Gruppe könnte der jeweilige Rollladen sein. Natürlich gibt es wieder Ausnahmen, wo die dritte Gruppe bei up und down voneinander abweicht. Ich führe das mal auf falsch erfasste Codes zurück.

Bleibt die Frage nach den ersten beiden Gruppen. Ist das ein rollierender Code? Ich habe 2 Fernbedienungen. Beide funktionieren unabhängig voneinander. Die von mir mitgeschnittenen Codes sind immer wieder nutzbar. Könnte es sein, dass man in den ersten beiden Gruppen einen Zufallscode überträgt der nur bestimmte Kriten erfüllen muss (z.B. eine Prüfsumme)???


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Februar 2018, 18:39:54
einfach mal AABB CCDD für die ersten Nibble probieren. Wenn sich etwas bewegt, dann scheint es nur eine Art sync zu sein. Wenn es eine Prüfziffer ist, dann sollte bereits die Änderung eines Bits das Gegenteil bewirken (keine Aktion).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 23 Februar 2018, 19:06:21
Zitat von: habeIchVergessen am 23 Februar 2018, 18:39:54
einfach mal AABB CCDD für die ersten Nibble probieren. Wenn sich etwas bewegt, dann scheint es nur eine Art sync zu sein. Wenn es eine Prüfziffer ist, dann sollte bereits die Änderung eines Bits das Gegenteil bewirken (keine Aktion).
gibt's denn für meine MU-Codes auch eine andere  Sendeform statt raw oder muss ich die wieder in Zahlenkollonnen umrechnen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 23 Februar 2018, 19:24:03
bis dato gibt es nur raw (die Zahlenkolonnen).

Rollladen 4 down
E7F9 8B24 3F74 B7FC

Rollladen 2 down
9EB5 A2F8 7F74 B7FC

Rollladen 3 down
CA10 58B5 BF74 B7FC

alter Code
AD99 79A2 9FBC B7FC

also ich vermute
- der 9. Nibble ist der Kanal/Rollladen (4 bit)
- 10. - 15. Nibble ist der Code der FB (24 bit)
- der 16. Nibble ist die Taste (4 bit)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 09:32:52
Zitat von: habeIchVergessen am 23 Februar 2018, 19:24:03
also ich vermute
- der 9. Nibble ist der Kanal/Rollladen (4 bit)
- 10. - 15. Nibble ist der Code der FB (24 bit)
- der 16. Nibble ist die Taste (4 bit)

Verdammt gut vermutet (fast so, als ob Du selbst den Code für die Steuerung geschrieben hättest :-)). Ich kann Deine Vermutung auf Basis meiner aufbereiteten Daten nachvollziehen

up/stop/down
D34E BC00 5F74 B7FE
.... .... .... ...E -> stop
875E 2E7E BF74 B7FA
.... .... .... ...A -> up
F4E4 33FA BF74 B7FC
.... .... .... ...C -> down


Rollladenmotor
Rolllade 1
4BE9 9ECF FFBC B7FC -> FFBC (12)
38B2 D909 FF74 B7FA -> FF74 (10)
.... .... F... .... -> R1

Rolllade 2
0FE8 A86C 7FBC B7FC -> 7FBC (29)
3301 53F9 7F74 B7FA -> 7F74 (21)
.... .... 7... .... -> R2

Rolllade 3
052A 5850 BF74 B7FE -> BF74 (30)
AD68 F6CB BFBC B7FC -> BFBC (21)
.... .... B... .... -> R3

Rolllade 4
4A39 0D05 3FBC B7FA -> 3FBC (14)
.... .... 3... .... -> R4

Rolllade 5
3E6E 7D95 DFBC B7FA -> DFBC (6)
9318 BE15 DF74 B7FE -> DF74 (6)
.... .... D... .... -> R5

Rolllade 6
97A1 D452 5FBC B7FA -> 5FBC (19)
6C35 EA08 5F74 B7FE -> 5F74 (11)
.... .... 5... .... -> R6


Fernbedienung

.... .... .FBC B7F. -> FB1
.... .... .F74 B7F. -> FB2


Ich stelle mir nur die Frage, ob der Hersteller wirklich das Risiko eingeht für die Adressierung der Motoren nur 4 Bits zu verwenden. Ich hatte damals 7 Motoren verbaut, da liegt die Wahrscheinlichkeit, dass zwei Motoren auf dieselbe Adresse hören, bei fast 50%. Andererseits wäre es aus merkwürdig, wenn der Code aller verbauten Motore auf ".F" endet (Ansatz Nibbel 9+10).

ok, aber ich könnte jetzt auf Basis dieser Erkenntnis einen raw-Code zusammenbauen (mit der Annahme, dass Nibbel 1-8 n ur sync sind zusätzlich zur Präambel). Das führt natürlich zu neuen Fragen:


Aber ansonsten: schon mal ein herzliches Dankeschön, ohne Deine Tipps wäre ist nicht so schnell so weit gekommen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 10:01:35
P.S. Der Motor, der sich bisher am stabilsten ansteuern ließ, reagiert auch auf die "begradigten" Parameter
SC;;SR;;P0=-16000;;P1=16000;;D=001;;SR;;R=10;;P2=-400;;P3=400;;P5=4000;;P6=800;;P7=-800;;D=...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 24 Februar 2018, 10:35:48
ich würde P0 auch in die Wiederholungen beim Senden einbauen. ist ja "nur" eine Pause.

der sduino ist mit cc1101? wenn ja geht vielleicht geht noch was, wenn die Frequenz variiert wird.
auf welcher Frequenz empfängst du aktuell?868MHz
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 12:55:25
Zitat von: habeIchVergessen am 24 Februar 2018, 10:35:48
der sduino ist mit cc1101? wenn ja geht vielleicht geht noch was, wenn die Frequenz variiert wird.
auf welcher Frequenz empfängst du aktuell?868MHz
Ich habe bereits mit Frequenz und Bandbreite rumgespielt. Der Empfang klappt nur bei 868.000 MHz und 650 kHz Bandbreite.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 16:22:46
Mir kam da so ein Gedanke: Was wäre wenn die Nibbles 1-8 ein pro Tastendruck dynamisch generierter Zufallscode sind, damit der Empfänger erkennen kann, ob die Taste immer noch oder erneut gedrückt wurde? Das würde erklären, dass sich die Motoren manchmal nicht reproduzierbar ansteuern lassen. Über Nacht ist das alles vergessen und der Code vom Vorabend funkioniert wieder.

Würde bedeuten: Ich müsste die Nibbles 1-8 jedes mal austauschen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 24 Februar 2018, 16:38:33
ändert sich das Sendeverhalten bei einem kurzen und langen Tastendruck?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 16:54:56
Zitat von: habeIchVergessen am 24 Februar 2018, 16:38:33
ändert sich das Sendeverhalten bei einem kurzen und langen Tastendruck?
Kann ich noch nicht sagen. Der SIGNALduino reagiert manchmal träge was MU-Einträge im Log angeht.

Ich habe aber gerade einen funktionsfähigen Code getestet. Motor dreht. Habe ihn mit der Fernbedienung gestoppt und denselben Code aus FHEM erneut abgesetzt -> keine Reaktion. Wenn ich im Nibble 1 nur zwei Bits tausche ändert das nichts. Da scheint also mehr Plausibilitätsprüfung drin zu stecken. Und sei es, dass es eine Art Einbrecherschutz sein soll. Wenn er einen Code mitgeschnitten hat müsste er bis zum nächsten Morgen warten, um ihn anwenden zu können

Alle 1er Bits der Nibbles 1-8 zählen ist es nicht. Nibbles 1-8 als eine große Hex-Zahl interpretieren führt auch zu abweichenden Zahlen. Die Suche geht weiter ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 24 Februar 2018, 17:12:09
Ein anderer Motor hat meine Theorie gerade zunichte gemacht: Er reagiert mehrfach auf denselben Code.

Bleibt also die alte Frage: Wieso funktionieren Codes manchmal und dann mal wieder nicht?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 24 Februar 2018, 17:23:23
teste mal die Anzahl der Wiederholungen und die Pausen dazwischen.
würde eher weniger Wiederholungen sehen. aber keine 32s Pause.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 25 Februar 2018, 10:46:26
Zitat von: habeIchVergessen am 24 Februar 2018, 17:23:23
teste mal die Anzahl der Wiederholungen und die Pausen dazwischen.
würde eher weniger Wiederholungen sehen. aber keine 32s Pause.
Moin,

ich habe 4 Testreihen durchgespielt:
10 x alle 5 Sekunden eine Taste kurz gedrückt
10 x alle 15 Sekunden eine Taste kurz gedrückt
10 x alle 5 Sekunden eine Taste lang gedrückt (gefühlte 2 Sekunden)
10 x alle 15 Sekunden eine Taste lanf gedrückt (gefühlte 2 Sekunden)

Bei den kurzen Tastendrücken kommen wenige brauchbare Codes raus. Die Datenteile beginnen z.B. mit "D=0101212121213434343421343421213421..." statt sauberen "D=01232323232323232323232324...".
Mal erkennt der SIGNALduino nicht jeden Tastendruck, mal werden gefundene 4-5 MU-Sequenzen im Log ausgewiesen.

Mein Script zur Erkennung strukturell sauberer Codes erkennt aus den 347 mitgeschnitteten MU-Sequenzen 11 die brauchbar sein könnten. Die Aufbereitung ergibt dann:


kurz, 5 Sekunden Pause
P0=-17232;P1=15916;P2=-360;P3=455;P4=4056;P5=852;P6=-747;D=0123232323232323232323232425632525632563632525636363632563636363252563636325632563252525256325256363636363256363632563252563256363256363636363636363256325; # 4B3D E750 9F74 B7FA

kurz, 5 Sekunden Pause
P0=-11236;P1=15946;P2=-342;P3=466;P4=4070;P5=872;P6=-750;D=0123232323232323232323232425636363636325256325252563632525636325256363252563636325636363636325256363636363256363632563252563256363256363636363636363256325; # 7C8C CCEF 9F74 B7FA
P0=-18912;P1=15946;P2=-337;P3=478;P4=4046;P5=-742;P6=869;D=0123232323232323232323232453535326535353532653265326535353532626535353532626535326265326265326265353535353265353532653262653265353265353535353535353265326; # EF57 9E64 9F74 B7FA

lang, 5 Sekunden Pause
P0=-18076;P1=15912;P2=-370;P3=431;P4=4044;P5=-783;P6=843;D=0123232323232323232323232453535353265353262626532653535353262653532653262626535353535326265326265353535353265353532653262653265353265353535353535353265326; # F62F 347C 9F74 B7FA
P0=-32001;P1=15932;P2=-332;P3=471;P4=4058;P5=-731;P6=892;D=0123232323232323232323232453265326262653265326532626532653532653265353535353535353262653535326265353535353265353532653262653265353265353535353535353265326; # A2A5 AFF3 9F74 B7FA

lang, 15 Sekunden Pause
P0=-32001;P1=15918;P2=-360;P3=444;P4=4050;P5=853;P6=-770;D=0123232323232323232323232425636363256363636325636325256363632563252525252563252563632563256325256363636363256363632563252563256363256363636363636363256325; # 77B3 A09A 9F74 B7FA
P0=-14992;P1=15934;P2=-256;P3=554;P4=4080;P5=-651;P6=958;D=0123232323232323232323232453262626532626535326265353265353265326535326532653532626532653535326265353535353265353532653262653265353265353535353535353265326; # 1 0 3 0
P0=-16944;P1=15920;P2=-365;P3=460;P4=4066;P5=-751;P6=849;D=0123232323232323232323232453535326262653535326532626265326265326265326262653262653532653265326265353535353265353532653262653265353265353535353535353265326; # E3A2 489A 9F74 B7FA
P0=-32001;P1=15938;P2=-346;P3=464;P4=4072;P5=866;P6=-740;D=0123232323232323232323232425632563256363252525256325636363256325636363252525636363252525636325256363636363256363632563252563256363256363636363636363256325; # 5617 5C71 9F74 B7FA
P0=-22656;P1=15934;P2=-358;P3=452;P4=4054;P5=-759;P6=844;D=0123232323232323232323232453532653262653262626532626532653262653265326532626532653262653265326265353535353265353532653262653265353265353535353535353265326; # D225 2A52 9F74 B7FA
P0=-32001;P1=15924;P2=-380;P3=423;P4=4032;P5=-787;P6=827;D=0123232323232323232323232453532626532626262626262626262653532653532626262626535326535353265326265353535353265353532653262653265353265353535353535353265326; # C801 B06E 9F74 B7FA


Wenn ich "saubere Struktur" ignoriere kommt ein weiterer hinzu der auf "9F74 B7FA" endet. Mein Ansatz grundsätzlich alle unsauberen auszuschließen ist also richtig.

Erkenntnis: Die Nibbles 1-8 wechseln jedes Mal, egal ob lang oder kurz gedrückt wird.

VG Peter

P.S. Ich werde es gleich mal mit der Synthese versuchen: Die beliebtesten,gerundeten Parameter, die übliche Präambel, einer der Nibbles 1-8, Motor, Fernbedienung, Richtung. Wenn die Nibbles von Motor/FB unabhängig sind kann man daraus was machen. Ich habe mittlerweile genug mitgeschnitten, um einen ausreichend großen Wertevorrat zu haben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 Februar 2018, 14:21:19
poste mal alle Nachrichten, die in das Zeitfenster kurz + 5s Pause fallen. ggf. sind da Fragmente, mit denen man etwas anfangen kann.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: misux am 25 Februar 2018, 15:09:39
Zitat von: habeIchVergessen am 22 Februar 2018, 22:37:44
sieht eigentlich gut aus.

hast du mal verbose 4 probiert? zumindest im Log-File sollte dann etwas erscheinen.

Ja, habe mal auf verbose 4 gestellt und mal einen Tag laufen lassen... Den eintrag habe ich ca 4 Millionen mal bekommen...  Ist das normal? Sonst habe ich nix bekommen...

2018.02.24 06:35:09.452 4: signalDuino/msg READredu: MS;P1=450;P2=-4063;P3=-2051;P4=-8968;D=3141212131213121213131313131313121212121312121212121212121212121212121312131;CP=1;SP=4;R=223;
2018.02.24 06:35:24.817 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:35:40.788 4: signalDuino/msg READredu: MS;P1=459;P2=-8972;P3=-4067;P4=-1977;P5=-22208;D=01213131413141313141414141414141313131314131313131313131313156;CP=1;SP=2;R=225;
2018.02.24 06:35:41.344 4: signalDuino/msg READredu: MS;P1=475;P2=-1983;P3=-4058;P4=-8970;D=214131312131213131212121212121213131313121313131313131313131313131313121312;CP=1;SP=4;R=225;m=2;
2018.02.24 06:35:47.878 4: signalDuino/msg READredu: MU;P0=-32001;P1=484;P2=-995;P3=308;P4=-1966;P5=-128;D=0123414141212121414141414141212141414121414150;CP=1;R=221;
2018.02.24 06:35:47.880 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:35:48.215 4: signalDuino/msg READredu: MS;P1=498;P2=-997;P3=-1961;P4=-3928;D=214131212131312131313121212131313131313121213131312131313131213131213121212;CP=1;SP=4;R=221;m=2;
2018.02.24 06:35:48.217 4: signalDuino/msg READredu: MS;P1=498;P2=-997;P3=-1961;P4=-3928;D=14131212131312131313121212131313131313121213131312131313131213131213121212;CP=1;SP=4;R=221;
2018.02.24 06:35:48.642 4: signalDuino/msg READredu: MS;P0=460;P1=-995;P2=-1979;P3=-3936;P4=-28316;D=030201010202010202020101010202020202020101020202010202020201020201020101010401020202020202010102020201020202020102020102010101;CP=0;SP=3;R=219;m=2;
2018.02.24 06:36:12.773 4: signalDuino/msg READredu: MS;P3=455;P4=-8968;P5=-4068;P6=-2076;D=23435353635363535363636363635363535353536353535353535353535360;CP=3;SP=4;R=226;
2018.02.24 06:36:13.165 4: signalDuino/msg READredu: MU;P0=-2492;P1=481;P2=-4052;P3=-27620;P4=-1914;D=01212121312141214121214141414141214121212140;CP=1;R=223;
2018.02.24 06:36:24.824 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:36:44.851 4: signalDuino/msg READredu: MU;P0=472;P1=-1195;P2=-1955;P3=-208;P5=-338;P6=640;P7=-781;D=0102020103010301030103050167070702050105010;CP=0;R=223;
2018.02.24 06:36:44.853 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:44.949 4: signalDuino/msg READredu: MU;P0=489;P1=-1389;P2=-954;P3=-618;P4=783;P5=-1978;P6=-186;D=01020345010602050501420203450106050203020300;CP=0;R=228;
2018.02.24 06:36:44.951 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:45.162 4: signalDuino/msg READredu: MU;P0=-693;P1=465;P2=-1011;P3=-452;P5=-1926;P6=780;D=0121012121312131212121312131510621210101513;CP=1;R=225;
2018.02.24 06:36:45.164 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:45.555 4: signalDuino/msg READredu: MS;P1=-1978;P2=470;P5=-3876;P7=-1001;D=25212727212127212121272727212121212121272721212127212121212721212721272727;CP=2;SP=5;R=221;m=2;
2018.02.24 06:36:45.620 4: signalDuino/msg READredu: MU;P0=144;P1=-1981;P2=473;P3=-1023;P4=92;P5=-676;P6=-25132;D=01212123232345212123212121212321212321232323060;CP=2;R=221;
2018.02.24 06:36:45.702 4: signalDuino/msg READredu: MU;P0=-332;P1=92;P2=-999;P3=486;P4=-1976;P5=-27424;P6=260;D=01234343434343432323434343234343434323434323432323235;CP=3;R=221;
2018.02.24 06:37:17.469 4: signalDuino/msg READredu: MU;P0=-2037;P1=460;P2=-4071;D=010121012121212101212121212121212121212121210121210;CP=1;R=225;
2018.02.24 06:37:24.832 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:37:41.852 4: signalDuino/msg READredu: MU;P0=-1288;P1=472;P2=-1959;P3=-993;P4=-116;D=0121313121213121212131313121212121212131312140;CP=1;R=221;
2018.02.24 06:37:41.854 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:37:42.196 4: signalDuino/msg READredu: MS;P0=-1996;P1=437;P2=-997;P3=-3936;D=213101212101012101010121212101010101010121210101012101010101210101210121212;CP=1;SP=3;R=221;m=2;
2018.02.24 06:37:42.359 4: signalDuino/msg READredu: MS;P1=-1962;P2=466;P3=-1004;P4=-3936;P5=-26324;D=24212323212123212121232323212121212121232321251;CP=2;SP=4;R=219;
2018.02.24 06:37:42.741 4: signalDuino/msg READredu: MS;P0=484;P1=-995;P2=-27015;P4=-1954;P5=-3926;P6=348;D=05040101040401040404010101040404040404010104040265040101040401040404010101040404040404010104040401040404040104040104010101;CP=0;SP=5;R=220;O;m=2;
2
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 25 Februar 2018, 15:14:09
Zitat von: habeIchVergessen am 25 Februar 2018, 14:21:19
poste mal alle Nachrichten, die in das Zeitfenster kurz + 5s Pause fallen. ggf. sind da Fragmente, mit denen man etwas anfangen kann.
Ist überschaubar:

2018.02.25 10:07:30 4: mySIGNALduino/msg READ: MU;P0=-31350;P1=890;P2=-319;P3=-723;P4=483;P6=15612;P7=4080;D=01012121212134343434213434212134212134213421342121212134213421343421213434343434213434342134212134213434213434343434343434213421262424242424242424242424273421212121213434343421343421213421213421342134212121213421342134342121343434343421343434213421213421;CP=4;R=11;O;
2018.02.25 10:07:30 4: mySIGNALduino/msg READ: MU;P0=-718;P1=485;P2=-319;P3=885;P4=15616;P5=4092;D=01012301010101010101012301232421212121212121212121232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301012323012323012301230123232323;CP=1;R=11;O;
2018.02.25 10:07:31 4: mySIGNALduino/msg READ: MU;P0=-727;P1=481;P2=-331;P3=879;P4=15590;P5=4094;D=01230123010123230101010101230101012301232301230101242121212121212121212121250123232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301;CP=1;R=11;O;
2018.02.25 10:07:31 4: mySIGNALduino/msg READ: MU;P0=-728;P1=483;P2=-320;P3=886;D=012323012323012301230123232323012301230101232301010;CP=1;R=11;
2018.02.25 10:07:31 4: mySIGNALduino/msg READ: MU;P0=-754;P1=455;P2=-344;P3=862;P4=16224;P5=4052;P6=92;D=0101230101010101010101230123242121212121212121212121250123230101012301230123232323010123010123230123010123232323010101012323010101010123010101230123230123010123010101010101010101012326;CP=1;R=9;
2018.02.25 10:07:35 4: mySIGNALduino/msg READ: MU;P0=-28580;P1=494;P3=4034;P4=-712;P5=-300;P6=907;P7=15596;D=01034141415656564141414141564141415641414156415656414156564141565656415656414141414156414141564156564156414156414141414141414156415657515151515151515151515153414141565656414141414156414141564141415641565641415656414156565641565641414141415641414156415656;CP=1;R=10;O;
2018.02.25 10:07:35 4: mySIGNALduino/msg READ: MU;P0=-707;P1=489;P2=-304;P3=908;P4=15632;D=012301012301010101010101012301232421212121212121212;CP=1;R=11;
2018.02.25 10:07:35 4: mySIGNALduino/msg READ: MU;P0=-694;P1=514;P2=-286;P3=916;P4=15608;P5=4120;D=01010123232301010101012301010123010101230123230101232301012323230123230101010101230101012301232301230101230101010101010101230123242121212121212121212121250101012323230101010101230101012301010123012323010123230101232323012323010101010123010101230123230123;CP=1;R=11;O;
2018.02.25 10:07:35 4: mySIGNALduino/msg READ: MU;P0=-694;P1=506;P2=-298;P3=920;P4=15632;D=010123010101010101010123012324212121212121212121212;CP=1;R=11;
2018.02.25 10:07:35 4: mySIGNALduino/msg READ: MU;P0=-668;P1=527;P2=-279;P3=940;P4=15648;P5=4148;D=01010123232301010101012301010123010101230123230101232301012323230123230101010101230101012301232301230101230101010101010101230123242121212121212121212121250101012323230101010101230101012301010123012323010123230101232323012323010101010123010101230123230123;CP=1;R=11;O;
2018.02.25 10:07:36 4: mySIGNALduino/msg READ: MU;P0=-666;P1=478;P2=-324;P3=965;P4=16264;D=010123010101010101010123012324212121212121212121212;CP=1;R=11;
2018.02.25 10:07:36 4: mySIGNALduino/msg READ: MU;P0=-643;P1=569;P2=-254;P3=949;P4=116;D=0123232323010123232323230123010101010123012301012323012301232301012323010101010123010101230123230123010123010101010101010101012324;CP=1;R=11;
2018.02.25 10:07:40 4: mySIGNALduino/msg READ: MU;P0=4064;P1=444;P2=-352;P3=867;P5=-761;P7=15572;D=01232323512323515123512323235123235123512351512323515151232351515151512351515123512323512351512351515151515151512351232721212121212121212121212023232351515123232351232351512351232323512323512351235151232351515123235151515151235151512351232351235151235151;CP=1;R=10;O;
2018.02.25 10:07:40 4: mySIGNALduino/msg READ: MU;P0=-747;P1=460;P2=-334;P3=868;P4=15592;P5=4080;D=010101010101230123242121212121212121212121252323230;CP=1;R=10;
2018.02.25 10:07:40 4: mySIGNALduino/msg READ: MU;P0=-345;P1=861;P2=-750;P3=461;P4=15560;P5=4060;D=01010123010123230123010101230101230123012323010123232301012323232323012323230123010123012323012323232323232323012301040303030303030303030303050101012323230101012301012323012301010123010123012301232301012323230101232323232301232323012301012301232301232323;CP=3;R=10;O;
2018.02.25 10:07:40 4: mySIGNALduino/msg READ: MU;P0=-756;P1=458;P2=-351;P3=857;P4=15582;P5=4084;D=01010101012301232421212121212121212121212523232301032323012323010123012323230123230123012301012323010101232301010101012301010123012323012301012301010101010101012301232421212121212121212121212523232301010123232301232301012301232323012323012301230101232301;CP=1;R=10;O;
2018.02.25 10:07:41 4: mySIGNALduino/msg READ: MU;P0=-761;P1=454;P2=-368;P3=839;P4=15548;P5=4064;P6=-240;D=0101232301010101012301010123012323012301012301010104212121212121212121212125232323010101232323012323010123012323230123230123012301016323010101232301010101012301010123012323012301012301010101010301012301232;CP=1;R=10;
2018.02.25 10:07:45 4: mySIGNALduino/msg READ: MU;P0=-17232;P1=15916;P2=-360;P3=455;P4=4056;P5=852;P6=-747;D=01232323232323232323232324256325256325636325256363636325636363632525636363256325632525252563252563636363632563636325632525632563632563636363636363632563252123232323232323232323232425632525632563632525636363632563636363252563636325632563252525256325256363;CP=3;R=254;O;
2018.02.25 10:07:45 4: mySIGNALduino/msg READ: MU;P0=-737;P1=468;P2=-334;P3=873;P4=15588;P5=4078;D=01010123010101230123230123010123010101010101010123042121212121212121212121252301232301230101232301010101230101010123230101012301230123232323012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125230123230123010123230101;CP=1;R=0;O;
2018.02.25 10:07:45 4: mySIGNALduino/msg READ: MU;P0=-736;P1=476;P2=-321;P3=880;P4=15608;P5=4108;D=01012301010101232301010123012301232323230123230101010101230101010101010101230123242121212121212121212121252301232301230101232301010101230101010123230101012301230123232323012323010101010123010101230123230123010123010101010101010123012324212121212121212121;CP=1;R=1;O;
2018.02.25 10:07:45 4: mySIGNALduino/msg READ: MU;P0=-359;P1=445;P2=4062;P3=840;P4=-761;P5=15584;D=01010203410303410341410303414141410341414141030341410303414141414103414141034103034103414103414141414141414103410305010101010101010101430102034103034103414103034141414103414141410303414141034103410303030341030341414141410341414103410303410341410341414141;CP=1;R=0;O;
2018.02.25 10:07:50 4: mySIGNALduino/msg READ: MU;P0=4080;P1=-268;P2=-637;P3=554;P5=970;P7=15604;D=23152323232323231523152323232315151515232315231523231515232323232315232323152315152315232315232323232323232315231517131313131313131313131310232315151515152315232323232323152315232323231515151523231523152323151523232323231523232315231515231523231523232323;CP=3;R=0;O;
2018.02.25 10:07:50 4: mySIGNALduino/msg READ: MU;P0=-663;P1=961;P2=520;P3=-186;P4=-268;P5=15680;P7=4192;D=0102020231024145424232324242424242424247020241413141;CP=2;R=1;
2018.02.25 10:07:50 4: mySIGNALduino/msg READ: MU;P0=956;P1=-646;P2=562;P3=-279;P5=15648;P6=-211;P7=4176;D=01212121212123012301212121230303030121230123012123030121212121230121212301230301230121230121212121212121230123035323232323232623232323237121230303030301260121212121212301260121212123030303012123012301212306012121212123012121230123030123012123012121212121;CP=2;R=1;O;
2018.02.25 10:07:50 4: mySIGNALduino/msg READ: MU;P0=530;P1=-660;P2=-268;P3=951;P4=15650;P6=4146;D=01010231023242020202020202020202020261010232323232310101010102310231010101023232323101023102310102323101010101023101010231023231023101023101010101010101023102324202020202020202020202026101023232323231023101010101010231023101010102323232310102310231010232;CP=0;R=1;O;
2018.02.25 10:07:50 4: mySIGNALduino/msg READ: MU;P0=860;P1=-744;P2=475;P3=-290;P4=-1068;D=0121212121230121212301230301230121230121042121212121;CP=2;R=248;
2018.02.25 10:07:55 4: mySIGNALduino/msg READ: MU;P0=514;P1=15572;P2=4100;P3=917;P4=-695;P5=316;P7=-292;D=23454573737373737373734040404040734073404073404073734040404040734040407340737340734040734040404040404040734073717070707070707070707070727340407340734040407340407373737373737373404040404073407340407340407373404040404073404040734073734073404073404040404040;CP=0;R=250;O;
2018.02.25 10:07:55 4: mySIGNALduino/msg READ: MU;P0=-638;P1=559;P2=-239;P3=1008;P4=15648;P5=4160;P7=-138;D=01012301232421212121212121212121212523010123012301010123232323232323230101010101230123010123010123230101010101730101012301232301230101230101010101010101230123242121212121217121212121252301012301230101012301012323232323237323010101010123012301012301012323;CP=1;R=252;O;
2018.02.25 10:07:55 4: mySIGNALduino/msg READ: MU;P0=-616;P1=608;P2=-266;P3=995;D=0101010101230101012301232301230101230101010101010101;CP=1;R=252;
2018.02.25 10:07:55 4: mySIGNALduino/msg READ: MU;P0=15686;P1=-253;P2=552;P4=4170;P5=958;P6=-657;D=01212121212121212121212141562621562156262621562621515151515151515626262626215621562621562621515626262626215626262156215156215626215626262626262626215621510121212121212121212121214156262156215626262156262151515151515151562626262621562156262156262151562626;CP=2;R=252;O;
2018.02.25 10:07:55 4: mySIGNALduino/msg READ: MU;P0=522;P1=-273;P2=-674;P4=951;D=0102014202020142014142014202014202020202020202014201;CP=0;R=241;
2018.02.25 10:08:00 4: mySIGNALduino/msg READ: MU;P0=1038;P1=-588;P2=669;P3=-209;P6=-132;P7=15720;D=01212123012303012301212301212121212121212301230673262;CP=2;R=250;
2018.02.25 10:08:00 4: mySIGNALduino/msg READ: MU;P1=475;P2=-735;P3=92;P4=865;D=112134342134342121212121213421342134343421213434212121213434212121212424212121342134342134212134212121212121212134213433;CP=3;R=249;
2018.02.25 10:08:05 4: mySIGNALduino/msg READ: MU;P0=15658;P1=4224;P2=-620;P3=581;P4=-214;P5=988;D=23234523454523234523234545232323232345232323452345452345232345232323232323232345234540434343434343434343434341232323454523452323454523452345232345452323452323452345452323452323454523232323234523232345234545234523234523232323232323234523454043434343434343;CP=3;R=250;O;
2018.02.25 10:08:05 4: mySIGNALduino/msg READ: MU;P0=-191;P1=622;P2=-122;P3=4216;P4=-601;P5=1045;D=0121010103414141250541054141050541054105414105054141;CP=1;R=251;
2018.02.25 10:08:05 4: mySIGNALduino/msg READ: MU;P0=682;P1=-198;P2=4224;P3=-565;P4=1034;D=010101010101010101010123030301414301430301414301430;CP=0;R=251;
2018.02.25 10:08:06 4: mySIGNALduino/msg READ: MU;P0=-360;P1=468;P2=1512;P3=4214;P4=-744;P5=851;D=001010103414141050541054141050541054105414105054141054141054105054141054141020541414141410541414105410505410541410541414141414141410541050;CP=1;R=249;
2018.02.25 10:08:10 4: mySIGNALduino/msg READ: MU;P0=782;P1=-410;P2=-92;P5=-796;P6=415;P7=-1848;D=0102010101010101056105676565656105610701010105656101;CP=6;R=219;
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 Februar 2018, 15:52:43
Zitat von: misux am 25 Februar 2018, 15:09:39

2018.02.24 06:35:47.878 4: signalDuino/msg READredu: MU;P0=-32001;P1=484;P2=-995;P3=308;P4=-1966;P5=-128;D=0123414141212121414141414141212141414121414150;CP=1;R=221;
2018.02.24 06:35:47.880 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate

2018.02.24 06:36:44.851 4: signalDuino/msg READredu: MU;P0=472;P1=-1195;P2=-1955;P3=-208;P5=-338;P6=640;P7=-781;D=0102020103010301030103050167070702050105010;CP=0;R=223;
2018.02.24 06:36:44.853 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate

2018.02.24 06:36:44.949 4: signalDuino/msg READredu: MU;P0=489;P1=-1389;P2=-954;P3=-618;P4=783;P5=-1978;P6=-186;D=01020345010602050501420203450106050203020300;CP=0;R=228;
2018.02.24 06:36:44.951 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate

2018.02.24 06:36:45.162 4: signalDuino/msg READredu: MU;P0=-693;P1=465;P2=-1011;P3=-452;P5=-1926;P6=780;D=0121012121312131212121312131510621210101513;CP=1;R=225;
2018.02.24 06:36:45.164 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate

2018.02.24 06:37:41.852 4: signalDuino/msg READredu: MU;P0=-1288;P1=472;P2=-1959;P3=-993;P4=-116;D=0121313121213121212131313121212121212131312140;CP=1;R=221;
2018.02.24 06:37:41.854 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate

da sind ja Nachrichten für das Protokoll 72 (Siro Shutter). Nur fraglich, woher die kommen? Eine automatische Steuerung?

MS-Nachrichtenempfang kann man abschalten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 25 Februar 2018, 16:13:13
Zitat von: habeIchVergessen am 25 Februar 2018, 15:52:43
da sind ja Nachrichten für das Protokoll 72 (Siro Shutter). Nur fraglich, woher die kommen? Eine automatische Steuerung?
keine Ahnung, ich habe keine

Zitat von: habeIchVergessen am 25 Februar 2018, 15:52:43
MS-Nachrichtenempfang kann man abschalten.
config: MS=0;MU=1;MC=0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 Februar 2018, 16:27:00
ja, das war von misux.

aber jetzt zu dir

MU;P0=-31350;P1=890;P2=-319;P3=-723;P4=483;P6=15612;P7=4080;D=01012121212134343434213434212134212134213421342121212134213421343421213434343434213434342134212134213434213434343434343434213421262424242424242424242424273421212121213434343421343421213421213421342134212121213421342134342121343434343421343434213421213421;CP=4;R=11;O;
MU;P0=-718;P1=485;P2=-319;P3=885;P4=15616;P5=4092;D=01012301010101010101012301232421212121212121212121232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301012323012323012301230123232323;CP=1;R=11;O;
MU;P0=-727;P1=481;P2=-331;P3=879;P4=15590;P5=4094;D=01230123010123230101010101230101012301232301230101242121212121212121212121250123232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301;CP=1;R=11;O;
MU;P0=-728;P1=483;P2=-320;P3=886;D=012323012323012301230123232323012301230101232301010;CP=1;R=11;
MU;P0=-754;P1=455;P2=-344;P3=862;P4=16224;P5=4052;P6=92;D=0101230101010101010101230123242121212121212121212121250123230101012301230123232323010123010123230123010123232323010101012323010101010123010101230123230123010123010101010101010101012326;CP=1;R=9;



MU;P0=-31350;P1=890;P2=-319;P3=-723;P4=483;P6=15612;P7=4080;D=

01012121212134343434213434212134212134213421342121212134213421343421213434343434213434342134212134213434213434343434343434213421262424242424242424242424273421212121213434343421343421213421213421342134212121213421342134342121343434343421343434213421213421;CP=4;R=11;O;

   LsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsL

MU;P0=-718;P1=485;P2=-319;P3=885;P4=15616;P5=4092;D=

01012301010101010101012301232421212121212121212121232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301012323012323012301230123232323;CP=1;R=11;O;

lSlSsLlSlSlSlSlSlSlSlSsLlSsLs sSsSsSsSsSsSsSsSsSsSsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsL

MU;P0=-727;P1=481;P2=-331;P3=879;P4=15590;P5=4094;D=

01230123010123230101010101230101012301232301230101242121212121212121212121250123232323230101010123010123230123230123012301232323230123012301012323010101010123010101230123230123010123010101010101010123012324212121212121212121212125012323232323010101012301;CP=1;R=11;O;

lSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSs sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlS

MU;P0=-728;P1=483;P2=-320;P3=886;D=

012323012323012301230123232323012301230101232301010;CP=1;R=11;

lSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSl

MU;P0=-754;P1=455;P2=-344;P3=862;P4=16224;P5=4052;P6=92;D=

0101230101010101010101230123242121212121212121212121250123230101012301230123232323010123010123230123010123232323010101012323010101010123010101230123230123010123010101010101010101012326;CP=1;R=9;

lSlSsLlSlSlSlSlSlSlSlSsLlSsLs sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLlSlSlSsLlSsLlSsLsLsLsLlSlSsLlSlSsLsLlSsLlSlSsLsLsLsLlSlSlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSlSsLs



                           LsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs

sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs

sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSs

sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSsLlSsLs
                        1 0 0 0 0 0 1 1 1 1 0 1 1 0 0 1 0 0 1 0 1 0 1 0 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 1 0 1 1 1 0 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 0 1 0

83D9 2A15 9F74 B7FA

sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLsLsLsLlSlSlSlSsLlSlSsLsLlSsLsLlSsLlSsLlSsLsLsLsLlSsLlSsLlSlSsLsLlSlSl

sSsSsSsSsSsSsSsSsSsSsSsPlSsLsLlSlSlSsLlSsLlSsLsLsLsLlSlSsLlSlSsLsLlSsLlSlSsLsLsLsLlSlSlSlSsLsLlSlSlSlSlSsLlSlSlSsLlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSlSsLs
                        1 0 0 1 1 1 0 1 0 1 0 0 0 0 1 1 0 1 1 0 0 1 0 1 1 0 0 0 0 1 1 1 1 0 0 1 1 1 1 1 0 1 1 1 0 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0

9D43 6587 9F74 B7FE

hab mal die Nachrichten von 2018.02.25 10:07:30 genommen.

in der dritten kommt 4212121212121212121212125 (sSsSsSsSsSsSsSsSsSsSsSsP wobei P 10xS; Vorspann). Von P bis zur nächsten 4 stehen 32 Bit  in der vermuteten Kodierung.
Also in der 1., 2., 4. und 5. nach den Vorspann gesucht und siehe da die Daten stehen da auch drin. Leider fehlen am Anfang(1.)/Ende Daten.
Ende der 1. und Anfang der zweiten ergeben auch eine komplette Nachricht.

die letzte Nachricht ist ein Stop.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 25 Februar 2018, 17:51:50
Zitat von: habeIchVergessen am 25 Februar 2018, 16:27:00
die letzte Nachricht ist ein Stop.
mmh, ich habe aber immer die Up-Taste betätigt.

Meine Tests mit Austausch der Nibbles 1-8 gegen andere hat bisher auch noch nichts gebracht. Der Zusammenbau des Codes bewegt auch nicht nichts...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 Februar 2018, 18:14:46
versuch mal das zu senden

SR;;R=5;;P0=-800;;P1=400;;P2=-400;;P3=800;;P4=1000;;P5=4000;;D=21212121212121212121212501232323232301010101230101232301232301230123012323232301230123010123230101010101230101012301232301230101230101010101010101230123242;;
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 25 Februar 2018, 18:46:04
Zitat von: habeIchVergessen am 25 Februar 2018, 18:14:46
versuch mal das zu senden

SR;;R=5;;P0=-800;;P1=400;;P2=-400;;P3=800;;P4=1000;;P5=4000;;D=21212121212121212121212501232323232301010101230101232301232301230123012323232301230123010123230101010101230101012301232301230101230101010101010101230123242;;

da passiert nichts, auch nicht bei R=10

Ich habe mittlerweile weitere Erkenntnisse zu den Nibbles: Die sind fernbedienungs-, motor und richtungsabhängig. Einer meiner Motoren ist eben mit dem down-Nibble beim up-Command schön brav nach unten gefahren :-)

Die Synthese scheint es also (bisher noch) nicht zu bringen. Auf Basis der jetzigen Erkenntnisse lassen sich aber zumindest aus den mitgeschnittenen Codes sehr präzise die halbwegs brauchbaren rausfischen.

Es bleibt also spannend :-)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Byte09 am 25 Februar 2018, 18:51:12
Zitat von: misux am 25 Februar 2018, 15:09:39
Ja, habe mal auf verbose 4 gestellt und mal einen Tag laufen lassen... Den eintrag habe ich ca 4 Millionen mal bekommen...  Ist das normal? Sonst habe ich nix bekommen...

2018.02.24 06:35:09.452 4: signalDuino/msg READredu: MS;P1=450;P2=-4063;P3=-2051;P4=-8968;D=3141212131213121213131313131313121212121312121212121212121212121212121312131;CP=1;SP=4;R=223;
2018.02.24 06:35:24.817 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:35:40.788 4: signalDuino/msg READredu: MS;P1=459;P2=-8972;P3=-4067;P4=-1977;P5=-22208;D=01213131413141313141414141414141313131314131313131313131313156;CP=1;SP=2;R=225;
2018.02.24 06:35:41.344 4: signalDuino/msg READredu: MS;P1=475;P2=-1983;P3=-4058;P4=-8970;D=214131312131213131212121212121213131313121313131313131313131313131313121312;CP=1;SP=4;R=225;m=2;
2018.02.24 06:35:47.878 4: signalDuino/msg READredu: MU;P0=-32001;P1=484;P2=-995;P3=308;P4=-1966;P5=-128;D=0123414141212121414141414141212141414121414150;CP=1;R=221;
2018.02.24 06:35:47.880 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:35:48.215 4: signalDuino/msg READredu: MS;P1=498;P2=-997;P3=-1961;P4=-3928;D=214131212131312131313121212131313131313121213131312131313131213131213121212;CP=1;SP=4;R=221;m=2;
2018.02.24 06:35:48.217 4: signalDuino/msg READredu: MS;P1=498;P2=-997;P3=-1961;P4=-3928;D=14131212131312131313121212131313131313121213131312131313131213131213121212;CP=1;SP=4;R=221;
2018.02.24 06:35:48.642 4: signalDuino/msg READredu: MS;P0=460;P1=-995;P2=-1979;P3=-3936;P4=-28316;D=030201010202010202020101010202020202020101020202010202020201020201020101010401020202020202010102020201020202020102020102010101;CP=0;SP=3;R=219;m=2;
2018.02.24 06:36:12.773 4: signalDuino/msg READredu: MS;P3=455;P4=-8968;P5=-4068;P6=-2076;D=23435353635363535363636363635363535353536353535353535353535360;CP=3;SP=4;R=226;
2018.02.24 06:36:13.165 4: signalDuino/msg READredu: MU;P0=-2492;P1=481;P2=-4052;P3=-27620;P4=-1914;D=01212121312141214121214141414141214121212140;CP=1;R=223;
2018.02.24 06:36:24.824 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:36:44.851 4: signalDuino/msg READredu: MU;P0=472;P1=-1195;P2=-1955;P3=-208;P5=-338;P6=640;P7=-781;D=0102020103010301030103050167070702050105010;CP=0;R=223;
2018.02.24 06:36:44.853 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:44.949 4: signalDuino/msg READredu: MU;P0=489;P1=-1389;P2=-954;P3=-618;P4=783;P5=-1978;P6=-186;D=01020345010602050501420203450106050203020300;CP=0;R=228;
2018.02.24 06:36:44.951 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:45.162 4: signalDuino/msg READredu: MU;P0=-693;P1=465;P2=-1011;P3=-452;P5=-1926;P6=780;D=0121012121312131212121312131510621210101513;CP=1;R=225;
2018.02.24 06:36:45.164 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:36:45.555 4: signalDuino/msg READredu: MS;P1=-1978;P2=470;P5=-3876;P7=-1001;D=25212727212127212121272727212121212121272721212127212121212721212721272727;CP=2;SP=5;R=221;m=2;
2018.02.24 06:36:45.620 4: signalDuino/msg READredu: MU;P0=144;P1=-1981;P2=473;P3=-1023;P4=92;P5=-676;P6=-25132;D=01212123232345212123212121212321212321232323060;CP=2;R=221;
2018.02.24 06:36:45.702 4: signalDuino/msg READredu: MU;P0=-332;P1=92;P2=-999;P3=486;P4=-1976;P5=-27424;P6=260;D=01234343434343432323434343234343434323434323432323235;CP=3;R=221;
2018.02.24 06:37:17.469 4: signalDuino/msg READredu: MU;P0=-2037;P1=460;P2=-4071;D=010121012121212101212121212121212121212121210121210;CP=1;R=225;
2018.02.24 06:37:24.832 4: signalDuino/keepalive ok, retry = 0
2018.02.24 06:37:41.852 4: signalDuino/msg READredu: MU;P0=-1288;P1=472;P2=-1959;P3=-993;P4=-116;D=0121313121213121212131313121212121212131312140;CP=1;R=221;
2018.02.24 06:37:41.854 4: signalDuino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.02.24 06:37:42.196 4: signalDuino/msg READredu: MS;P0=-1996;P1=437;P2=-997;P3=-3936;D=213101212101012101010121212101010101010121210101012101010101210101210121212;CP=1;SP=3;R=221;m=2;
2018.02.24 06:37:42.359 4: signalDuino/msg READredu: MS;P1=-1962;P2=466;P3=-1004;P4=-3936;P5=-26324;D=24212323212123212121232323212121212121232321251;CP=2;SP=4;R=219;
2018.02.24 06:37:42.741 4: signalDuino/msg READredu: MS;P0=484;P1=-995;P2=-27015;P4=-1954;P5=-3926;P6=348;D=05040101040401040404010101040404040404010104040265040101040401040404010101040404040404010104040401040404040104040104010101;CP=0;SP=5;R=220;O;m=2;
2



Hi Misux,

bist ja jetzt scheinbar einen schritt weiter mit dem signalduino und er empfängt zumindest das Siroprotokoll - wäre jetzt wohl ein guter zeitpunkt, wieder in den Sirothread zu wechseln . um zu schauen, warum das Device scheinbar nicht angelegt wir ( oder wurde eins angelegt ? )

gruss Byte09

PS: hast du denTag ca. 4 Millionen mal die SiroFB gedrückt ?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: habeIchVergessen am 25 Februar 2018, 19:17:22
Zitat von: plin am 25 Februar 2018, 18:46:04
Die Synthese scheint es also (bisher noch) nicht zu bringen.
was sendest du?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 25 Februar 2018, 20:01:56
Wollt ihr eure Analysen vielleicht in einen eigenen Thread auslagern?

Das sprengt den Thread zur Firmware und hat auch nur wenig mit damit zu tun.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 26 Februar 2018, 17:39:20
Zitat von: Sidey am 25 Februar 2018, 20:01:56
Wollt ihr eure Analysen vielleicht in einen eigenen Thread auslagern?
Hallo Sidey,

können wir machen. Ich würde den "SIGNALDuino - Analyse unbekannter Funkprotokolle" nennen und mit einer kurzen Zusammenfassung der bisherigen Erknenntisse und der Vorgehensweise beginnen. Mir hat der rege Austausch jedenfalls geholfen meine Rollladenmotoren halbwegs funktionsfähig zu kriegen (wenn auch das Ende noch nicht erreicht ist).

Erledigt: https://forum.fhem.de/index.php/topic,85006.0.html

VG Peter
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: misux am 02 März 2018, 07:35:39
Zitat von: Byte09 am 25 Februar 2018, 18:51:12

Hi Misux,

bist ja jetzt scheinbar einen schritt weiter mit dem signalduino und er empfängt zumindest das Siroprotokoll - wäre jetzt wohl ein guter zeitpunkt, wieder in den Sirothread zu wechseln . um zu schauen, warum das Device scheinbar nicht angelegt wir ( oder wurde eins angelegt ? )

gruss Byte09

PS: hast du denTag ca. 4 Millionen mal die SiroFB gedrückt ?

Hallo! Sorry ich habe mich irgendwie verlaufen... aus versehen einen neuen Thread erstellt wo er nicht sein sollte... Etwas zuviel auf einmal gemacht ::)

So, nun hier weiter. Nee, ich habe nicht so oft die FB gedrückt  ??? und an dem SignaDuino ist noch NICHTS angelernt weil es irgendwie nicht funktioniert...

Aber wenn diese Einträge von der Fernbedienung kommen sollten, kann man die nicht verwenden?

Hmmm.... Oder sollte ich vielleicht eine andere Firmware auf die SignalDuino installieren um auszuschließen das es an der FW liegt?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MiKn am 18 März 2018, 19:22:49
Hi,

irgendwie läuft bei mir was falsch...

Ich habe mir einen Dooya Vorhangsmotor DT82 mit Fernbedienung DC1602 geholt.
Signalduino von In-Circuit
Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   DMSG       u40#A995129E6
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   FD         106
   ITClock    250
   LASTDMSG   u40#A995129E6
   MSGCNT     314
   NAME       sduino
   NR         982
   NR_CMD_LAST_H 3
   PARTIAL   
   RAWMSG     MU;P0=-751;P1=665;P2=-400;P3=320;P4=-8576;P5=4624;P6=-1512;D=0123030121230301230123012303030123030123012303012121212303012123034561212301230123012303012123030123012301230303012303012301230301212121230301212303;CP=3;R=23;
   RSSI       -62.5
   STATE      opened
   TIME       1521389645.185
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 (433Mhz )- compiled at Mar 10 2017 23:27:29
   versionmodul v3.3.3-dev


es wird automatisch ein neues Device mit autocreate angelegt:
defmod Dooya_1101010100110010101000100101_1 Dooya 1101010100110010101000100101_1
attr Dooya_1101010100110010101000100101_1 IODev sduino
attr Dooya_1101010100110010101000100101_1 SignalRepeats 5
attr Dooya_1101010100110010101000100101_1 channel 1
attr Dooya_1101010100110010101000100101_1 drive-down-time-to-100 3
attr Dooya_1101010100110010101000100101_1 drive-down-time-to-close 3
attr Dooya_1101010100110010101000100101_1 drive-up-time-to-100 2
attr Dooya_1101010100110010101000100101_1 drive-up-time-to-open 3
attr Dooya_1101010100110010101000100101_1 event-min-interval .*:300
attr Dooya_1101010100110010101000100101_1 event-on-change-reading .*
attr Dooya_1101010100110010101000100101_1 room Dooya
attr Dooya_1101010100110010101000100101_1 webCmd on:stop:off:pos

setstate Dooya_1101010100110010101000100101_1 open
setstate Dooya_1101010100110010101000100101_1 2018-03-18 15:59:56 exact 0
setstate Dooya_1101010100110010101000100101_1 2018-03-18 12:30:27 parsestate on
setstate Dooya_1101010100110010101000100101_1 2018-03-18 15:59:56 position 0
setstate Dooya_1101010100110010101000100101_1 2018-03-18 15:59:56 state open


Mit set Dooya_1101010100110010101000100101_1 prog reagiert die LED am Motor nur gar nicht. Mit der Prog Taste P2 an der Fernbedienung reagiert der Motor einwandfrei.

Drücke ich die Prog Taste an der Fernbedienung passiert dies im FHEM Log:
2018-03-18 19:17:37 SIGNALduino sduino DMSG u40#A6544A798
2018-03-18 19:17:40 SIGNALduino sduino DMSG u40#6544A798
2018-03-18 19:17:43 SIGNALduino sduino DMSG u40#CA894F30
2018-03-18 19:17:46 SIGNALduino sduino DMSG u40#6544A798
2018-03-18 19:17:47 SIGNALduino sduino DMSG u40#A6544A798
2018-03-18 19:17:48 SIGNALduino sduino DMSG u40#A894F30


Beim drücken der Fernbedienung "Rauf":
2018-03-18 19:22:12 Dooya Dooya_1101010100110010101000100101_3 parsestate: off
2018-03-18 19:22:12 SIGNALduino sduino DMSG u40#A99512988
2018-03-18 19:22:12 SIGNALduino sduino DMSG u40#544A63C
2018-03-18 19:22:12 SIGNALduino sduino DMSG u40#A9951298F

Bei Runter:
2018-03-18 19:20:10 Dooya Dooya_1101010100110010101000100101_3 parsestate: on
2018-03-18 19:20:10 SIGNALduino sduino DMSG u40#A894CC8
2018-03-18 19:20:11 SIGNALduino sduino DMSG u40#A99512999
2018-03-18 19:20:11 SIGNALduino sduino DMSG u40#A990

Der Motor reagiert aber nur auf die Fernbedienung, was muss ich machen???

danke,
MiK
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MiKn am 23 März 2018, 18:18:04
hmm, ich habe mir aus Spaß mal einen weiteren Nano eingebunden, da ich den In-Circuit nicht zum flashen in Bootloader Modus bekam :).

Leider geht bei mir auch mit aktueller Firmware nichts. Egal ob MS=1 & MC=1 bzw 16 in die Whitelist eintragen, etc.

Was kann ich tun um bei der Lösung beizutragen??! Von der selben Fernbedienung kommen auch mal LASTDMSG u57#5B6D5ADB56B6AD7 Nachrichten rein. Aber 57er sollte es bei Dooya Motoren doch gar nicht geben, oder?

Zitatdefmod sduino_flash SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
attr sduino_flash cc1101_frequency 433.92
attr sduino_flash flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino_flash group Homematic
attr sduino_flash hardware nanoCC1101
attr sduino_flash room System

setstate sduino_flash opened
setstate sduino_flash 2018-03-22 22:47:02 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
setstate sduino_flash 2018-03-21 10:14:23 config MS=0;;MU=1;;MC=0;;Mred=1;;Mdebug=1_MScnt=4;;MuSplitThresh=8000;;MdebFifoLimit=80
setstate sduino_flash 2018-03-23 17:36:31 ping OK
setstate sduino_flash 2018-03-22 22:45:01 state opened
setstate sduino_flash 2018-03-22 22:45:01 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 23 März 2018, 19:02:04
Jemand eine Idee, wie man das autocreate beim SignalESP ausschalten kann?

defmod SIGNALESP868 SIGNALduino 192.168.1.36:23
attr SIGNALESP868 cc1101_frequency 868.3
attr SIGNALESP868 flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr SIGNALESP868 hardware nanoCC1101
attr SIGNALESP868 icon cul_cul
attr SIGNALESP868 room CUL,Gateways
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 März 2018, 21:07:13
Hi,

das Autocreate von was genau möchtest Du denn abstellen?


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Intruder1956 am 27 März 2018, 09:08:43
guten morgen, kann mir jemand sagen warum der Signalduino mir trotz Verbose 1 oder 0 das Logfile vollschreibt ???
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A96A4J04-if00-port0@57600
   DMSG       sD6A07F2E00
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A96A4J04-if00-port0@57600
   FD         14
   LASTDMSG   sD6A07F2E00
   MSGCNT     30652
   NAME       Signal_Stick
   NR         48
   PARTIAL   
   RAWMSG     MS;P1=496;P3=-3904;P4=-1939;P6=-8521;D=516131314131413131413141314141414141413131313131313141413141313131415;CP=1;SP=6;R=252;O;m=2;
   RSSI       -76
   STATE      opened
   TIME       1522134305.44563
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.1-RC2 SIGNALduino cc1101 - compiled at Jan  6 2018 00:45:28
   .attraggr:
   .attrminint:
   .clientArray:
     FS20
     IT
     CUL_TCM97001
     SD_WS
     SD_WS07
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-02-02 21:10:18   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB  (DataRate:5603.79Baud)
     2018-01-21 10:05:01   config          MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=3;MuSplitThresh=7000;MdebFifoLimit=80
     2018-02-24 12:58:16   ping            OK
     2018-01-08 11:41:53   raw             MS;P2=-8606;P3=502;P4=-1944;P5=-3888;P6=-495;D=632353434353434343535343434343434343434353434343535343535353435353436;CP=3;SP=2;R=241;O;m=2;
     2018-03-25 22:57:33   state           opened
     2018-02-02 20:58:13   uptime          0 07:19:18
     2018-03-25 22:57:33   version         V 3.3.1-RC2 SIGNALduino cc1101 - compiled at Jan  6 2018 00:45:28
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     12.1
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     75
     8
     9
Attributes:
   devStateIcon Initialized:it_network@0CFB0C opened:it_network@0CFB0C disconnected:it_network@red
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      CUL
   hardware   nanoCC1101
   room       CUL
   verbose    0



2018.03.27 00:08:49 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_106, please define it
2018.03.27 00:39:04 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_106, please define it
2018.03.27 01:47:49 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_106, please define it
2018.03.27 02:01:01 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_106, please define it
2018.03.27 07:32:41 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_212, please define it
2018.03.27 07:38:11 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_212, please define it
2018.03.27 07:56:53 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_212, please define it
2018.03.27 07:57:26 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_212, please define it
2018.03.27 08:28:47 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_80, please define it
2018.03.27 08:41:59 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_80, please define it
2018.03.27 08:43:05 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_80, please define it
2018.03.27 08:44:44 2: Signal_Stick: CUL_TCM97001 Unknown device CUL_TCM97001_80, please define it


Danke Gruß Werner



Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: MiKn am 29 März 2018, 19:23:06
so, mein Problem ist gelöst. Vieleicht hilft es ja jemanden irgendwann :).


Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken. Auch wenn über autocreate ein Dooya Device angelegt wird. Mit verbose 5 kammen die folgenden Daten:

2018.03.28 15:20:28 1: sduino/init: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
2018.03.28 15:20:28 3: sduino device opened
2018.03.28 15:20:28 3: sduino sduinoIdList: whitelistIds=
2018.03.28 15:20:28 3: sduino sduinoIdList: blacklistIds=
2018.03.28 15:20:28 3: sduino sduinoIdList: development=
2018.03.28 15:20:30 2: sduino: initialized. v3.3.2
2018.03.28 15:20:30 3: sduino/init: enable receiver (XE)
2018.03.28 15:21:11 3: sduino: Unknown code u40#A99512EAA, help me!
2018.03.28 15:21:11 3: Dooya Unknown device 1101010100110010101000100101_13, please define it
2018.03.28 15:21:11 3: sduino: Unknown code u40#A99512EAA, help me!
[b]2018.03.28 15:21:11 3: sduino: ID=m72 skiped dispatch (developId=m). To use, please add m72 to the attr development[/b]
2018.03.28 15:21:11 3: Dooya Unknown device 1101010100110010101000100101_13, please define it
2018.03.28 15:21:11 2: autocreate: define Dooya_1101010100110010101000100101_13 Dooya 1101010100110010101000100101_13
2018.03.28 15:21:11 2: autocreate: define FileLog_Dooya_1101010100110010101000100101_13 FileLog ./log/Dooya_1101010100110010101000100101_13-%Y.log Dooya_1101010100110010101000100101_13
2018.03.28 15:21:11 1: PERL WARNING: Use of uninitialized value $gplot in concatenation (.) or string at ./FHEM/98_autocreate.pm line 274.
2018.03.28 15:21:11 3: sduino: Unknown code u40#A99512EAA, help me!
2018.03.28 15:21:11 3: sduino: ID=m72 skiped dispatch (developId=m). To use, please add m72 to the attr development
2018.03.28 15:21:22 3: sduino: Unknown code u40#A99512EAA, help me!
2018.03.28 15:21:22 1: PERL WARNING: Use of uninitialized value $t1down100 in concatenation (.) or string at ./FHEM/98_Dooya.pm line 476.
2018.03.28 15:21:22 1: PERL WARNING: Use of uninitialized value $t1downclose in concatenation (.) or string at ./FHEM/98_Dooya.pm line 476.
2018.03.28 15:21:22 1: PERL WARNING: Use of uninitialized value $t1upopen in concatenation (.) or string at ./FHEM/98_Dooya.pm line 476.
2018.03.28 15:21:22 1: PERL WARNING: Use of uninitialized value $t1up100 in concatenation (.) or string at ./FHEM/98_Dooya.pm line 476.


M72 aktiviert

attr sduino cc1101_frequency 433.920Mhz
attr sduino development y,m72
attr sduino whitelist_IDs 16,72,40,57


schwups wird über autocreate ein Siro Device angelegt und alles geht  ;D

2018.03.29 16:21:43 5: sduino Dispatch: u40#A995128AA, test gleich
2018.03.29 16:21:43 4: sduino Dispatch: u40#A995128AA, Dropped due to short time or equal msg
2018.03.29 16:21:43 5: sduino: dispatching bits: 1 0 1 0 1 0 0 1 1 0 0 1 0 0 0 0
2018.03.29 16:21:43 4: sduino: decoded matched MU Protocol id 40 dmsg u40#A990 length 16 RSSI = -54.5
2018.03.29 16:21:43 5: sduino Dispatch: u40#A990, test ungleich: disabled
2018.03.29 16:21:43 5: sduino Dispatch: u40#A990, -54.5 dB, dispatch
2018.03.29 16:21:43 5: sduino: dispatch u40#A990
2018.03.29 16:21:43 4: SIGNALduino_unknown incomming msg: u40#A990
2018.03.29 16:21:43 4: SIGNALduino_unknown rawData: A990
2018.03.29 16:21:43 4: SIGNALduino_unknown Protocol: 40
2018.03.29 16:21:43 4: SIGNALduino_unknown converted to bits: 1010100110010000
2018.03.29 16:21:43 4: Unknown, please report
2018.03.29 16:21:43 3: sduino: Unknown code u40#A990, help me!
2018.03.29 16:21:43 4: sduino: Fingerprint for MU Protocol id 72 -> Siro shutter matches, trying to demodulate
2018.03.29 16:21:43 5: sduino: Starting demodulation at Position 57
2018.03.29 16:21:43 5: sduino: dispatching bits: 1 1 0 1 0 1 0 1 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 1 0 1 0 0
2018.03.29 16:21:43 4: sduino: decoded matched MU Protocol id 72 dmsg P72#D532A25154 length 40 RSSI = -54.5
2018.03.29 16:21:43 5: sduino Dispatch: P72#D532A25154, test ungleich: disabled
2018.03.29 16:21:43 5: sduino Dispatch: P72#D532A25154, -54.5 dB, dispatch
2018.03.29 16:21:43 5: sduino: dispatch P72#D532A25154
2018.03.29 16:21:43 5: Siro_Parse: msg = D532A25154 length: P72#D532A25154
2018.03.29 16:21:43 5: Siro_Parse: rawData = D532A25154 length: 10
2018.03.29 16:21:43 5: Siro_Parse: converted to bits: 1101010100110010101000100101000101010100
2018.03.29 16:21:43 5: Siro_Parse: device ID: D532A25
2018.03.29 16:21:43 5: Siro_Parse: Channel: 1
2018.03.29 16:21:43 5: Siro_Parse: Cmd: 5  Newstate: stop
2018.03.29 16:21:43 5: Siro_Parse: deviceCode: D532A251
2018.03.29 16:21:43 2: Siro unknown device D532A251, please define it
2018.03.29 16:21:43 5: sduino: dispatching bits: 1 1 0 1 0 1 0 1 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 1 0 1 0 0
2018.03.29 16:21:43 4: sduino: decoded matched MU Protocol id 72 dmsg P72#D532A25154 length 40 RSSI = -54.5
2018.03.29 16:21:43 5: sduino Dispatch: P72#D532A25154, test gleich
2018.03.29 16:21:43 5: sduino Dispatch: P72#D532A25154, -54.5 dB, dispatch
2018.03.29 16:21:43 5: sduino: dispatch P72#D532A25154
2018.03.29 16:21:43 5: Siro_Parse: msg = D532A25154 length: P72#D532A25154
2018.03.29 16:21:43 5: Siro_Parse: rawData = D532A25154 length: 10
2018.03.29 16:21:43 5: Siro_Parse: converted to bits: 1101010100110010101000100101000101010100
2018.03.29 16:21:43 5: Siro_Parse: device ID: D532A25
2018.03.29 16:21:43 5: Siro_Parse: Channel: 1
2018.03.29 16:21:43 5: Siro_Parse: Cmd: 5  Newstate: stop
2018.03.29 16:21:43 5: Siro_Parse: deviceCode: D532A251
2018.03.29 16:21:43 2: Siro unknown device D532A251, please define it
2018.03.29 16:21:43 2: autocreate: define Siro_D532A251 Siro D532A251
2018.03.29 16:21:43 2: autocreate: define FileLog_Siro_D532A251 FileLog ./log/Siro_D532A251-%Y.log Siro_D532A251
2018.03.29 16:21:43 4: sduino/msg READredu: MU;P0=-398;P1=318;P2=-757;P3=664;P4=-8492;P5=4632;P6=-1532;D=0123012121230121230123012121230123012301230123456303012301230123012123030121230123012301212123012123012301212123012301230123012345630301230123012301212303012123012301230121212301212301230121212301230123012301234563030123012301230121230301212301230123012;CP=1;R=40;O;
2018.03.29 16:21:43 4: sduino: Fingerprint for MU Protocol id 16 -> Dooya shutter matches, trying to demodulate
2018.03.29 16:21:43 5: sduino: Starting demodulation at Position 49
2018.03.29 16:21:43 5: sduino: dispatching bits: 1 1 0 1 0 1 0 1 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 1 0 1 0 0
2018.03.29 16:21:43 4: sduino: decoded matched MU Protocol id 16 dmsg P16#D532A25154 length 40 RSSI = -54
2018.03.29 16:21:43 5: sduino Dispatch: P16#D532A25154, test ungleich: disabled
2018.03.29 16:21:43 5: sduino Dispatch: P16#D532A25154, -54 dB, dispatch
2018.03.29 16:21:43 5: sduino: dispatch P16#D532A25154
2018.03.29 16:21:43 4: SIGNALduino_unknown incomming msg: P16#D532A25154
2018.03.29 16:21:43 4: SIGNALduino_unknown rawData: D532A25154
2018.03.29 16:21:43 4: SIGNALduino_unknown Protocol: 16
2018.03.29 16:21:43 4: SIGNALduino_unknown converted to bits: 1101010100110010101000100101000101010100
2018.03.29 16:21:43 4: SIGNALduino_unknown / shutter Dooya 1101010100110010101000100101000101010100 received
2018.03.29 16:21:43 4: 11010101001100101010001 0101 0001 0101 0100
2018.03.29 16:21:43 4: SIGNALduino_unknown found shutter from Dooya. id=13972130, remotetype=5,  channel=1, direction=stop, all_shutters=false
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 29 März 2018, 20:52:03
Liest der S'duino die Temperatur des analogen Temperatur Sensors aus so wie z.B. die ESP32 CC1100 Library (https://github.com/loboris/ESP32_CC1101/blob/master/components/cc1100/libcc1100.c (https://github.com/loboris/ESP32_CC1101/blob/master/components/cc1100/libcc1100.c))?

Mein S'duino scheint bei längerem Sendebetrieb die Temperatur  etwas zu verschieben und einige meiner Empfänger reagieren dann ggf. nicht mehr. Wenn ich die Temeratur auslesen könnte wäre ich in der Lage die Sendefrequenz entsprechend nachzujustieren.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 29 März 2018, 22:32:35
Der Temperatursensor im cc1101 wird aktuell nicht ausgelesen nein.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 Mai 2018, 23:37:59
Hallo,

Mit der getUptime() in der RF_Receiver.ino scheint irgendwas nicht zu passen.

Ich habe am Abend bei einem get uptime folgendes erhalten:
49 10:19:33 |2018-04-29 22:33:00
In der Variable now müsste ca 4270773000 gewesen sein ( ca 6 Stunden vor dem Überlauf von millis() )

und am nächsten Tag
0 15:53:37 | 2018-04-30 21:10:00
Nun müsste now < last sein und times_rolled=1
zu second müsste 4 294 967 addiert worden sein (ca 49 Tage)

Hier ist die Routine die beim signalduino verwendet wird:
inline unsigned long getUptime()
{
unsigned long now = millis();
static uint16_t times_rolled = 0;
static unsigned long last = 0;
// If this run is less than the last the counter rolled
unsigned long seconds = now / 1000;
if (now < last) {
times_rolled++;
seconds += (( long(4294967295) / 1000 )*times_rolled);
}
last = now;
return seconds;
}


Dies müsste doch ein "unsigned long" sein?
seconds += (( long(4294967295) / 1000 )*times_rolled);

Kann jemand erkennen was da nicht passen könnte?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 Mai 2018, 22:10:21
Zitat von: Ralf9 am 06 Mai 2018, 23:37:59
Hallo,

und am nächsten Tag
0 15:53:37 | 2018-04-30 21:10:00
Nun müsste now < last sein und times_rolled=1
zu second müsste 4 294 967 addiert worden sein (ca 49 Tage)

Kann jemand erkennen was da nicht passen könnte?


Hi Ralf,

ich denke ich weiss was da nicht passt.
Werde es überarbeiten.

Edit:
Der Fehler wurde mit 3.3.1 RC6 behoben

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Mai 2018, 22:36:45
Ich habe inzwischen auch herausgefunden, was da nicht passt.
Das mit dem times_rolled kann so nicht funktionieren.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: fh168 am 09 Mai 2018, 17:07:23
Ich habe hier

https://github.com/merbanan/rtl_433

eine lustige Library gesehen.
Die kann u.a. sogar TPMS empfangen, also Reifendruck am Auto.
Vielleicht könnte man die mit SignalDuino verheiraten?

Ich habe die mal auf meinen Raspi ausprobiert, da werden noch einige mehr Stationen empfangen als beim Signalduino.

LG
/robin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 10 Mai 2018, 12:42:37
Hallo,
ich habe gerade 2 Probleme gleichzeitig (und das deshalb hier dupliziert):

1. nach Flash auf 3.1.1-RC6 wird nicht mehr gesendet/empfangen.
   Ich habe danach (mehrfach) RC4 und RC6 umgeflashed (nur das eine Zeichen im Befehl geändert). RC4 ist ok, RC6 ist tot, allerdings reagieren die Befehle Version, Uptime, ...
   Die Hardware ist ein Nano ohne CC1101
2. Das Normale Update ALL gibt Fehlermeldungen:

Code:
...UPD FHEM/firmware/SIGNALduino_nano328.hex
2018.05.10 11:54:43 1 : UPD FHEM/firmware/SIGNALduino_promini328.hex
2018.05.10 11:54:44 1 : UPD FHEM/firmware/SIGNALduino_uno.hex
2018.05.10 11:54:44 1 : UPD FHEM/lib/signalduino_protocols.hash
2018.05.10 11:54:44 1 : Got 53692 bytes for FHEM/lib/signalduino_protocols.hash, expected 55094
2018.05.10 11:54:44 1 : aborting.
2018-05-10 11:54:44 Global global UPDATE

Bin ich das oder ist da gerade etwas schief?

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 10 Mai 2018, 13:04:15
Hi,
Nee Signalduino Update schlägt gerade fehl. Kann ich bestätigen.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RappaSan am 12 Mai 2018, 15:49:41
Zitat von: fh168 am 09 Mai 2018, 17:07:23
Ich habe hier

https://github.com/merbanan/rtl_433

eine lustige Library gesehen.
Die kann u.a. sogar TPMS empfangen, also Reifendruck am Auto.
Vielleicht könnte man die mit SignalDuino verheiraten?

Ich habe die mal auf meinen Raspi ausprobiert, da werden noch einige mehr Stationen empfangen als beim Signalduino.

LG
/robin

Ich habe hier auch noch 2 von den Empfängersticks und ebenfalls ausprobiert.
Ist ja Wahnsinn, was da alles reinkommt.
Wie bekomme ich denn einzelne empfangene Sensoren -z.B. einen  THGR122N per MQTT ins FHEM, ist mir irgendwie noch nicht klar.

Der Output des Programms mit Aufruf "rtl_433 -G" sieht so aus:

2018-05-12 15:47:29     :       OS :    THGR122N
        House Code:      241
        Channel:         1
        Battery:         LOW
        Temperature:     25.70 C
        Humidity:        43 %
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 14 Mai 2018, 21:21:12
Zitat von: Harst am 10 Mai 2018, 12:42:37
1. nach Flash auf 3.1.1-RC6 wird nicht mehr gesendet/empfangen.
   Ich habe danach (mehrfach) RC4 und RC6 umgeflashed (nur das eine Zeichen im Befehl geändert). RC4 ist ok, RC6 ist tot, allerdings reagieren die Befehle Version, Uptime, ...
   Die Hardware ist ein Nano ohne CC1101
Das lag an einem fehlerhaften define im quellcode. Den Fehler habe ich aussortiert und eine RC7 steht bereit.
Über Rückmeldungen würde ich mich freuen.

Zitat von: Harst am 10 Mai 2018, 12:42:37
2. Das Normale Update ALL gibt Fehlermeldungen:

Auch diesen Fehler habe ich beseitigt. Danke für den Hinweis.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 14 Mai 2018, 21:26:23
Hallo Sidey,

alles wieder ok

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 31 Mai 2018, 10:56:57
Nach dem heutigen Update der "14_SD_WS.pm" empfange ich meine Temperatur/feuchtsensoren vom Typ: 33
nicht mehr.
Modell: infactory FWS-310 https://www.pearl.de/a-NC5849-3041.shtml (https://www.pearl.de/a-NC5849-3041.shtml)

Nachdem ich die letzte Version der Datei wiederhergestellt habe geht es wieder mit der bereits bekannt Einschränkung, dass der Batteriewert falsch interpretiert wird. Das ist nicht so schlimm.

Hier noch ein List eines Sensors:
Internals:
   CFGFN     
   CHANGED   
   CODE       SD_WS_33_TH_1
   DEF        SD_WS_33_TH_1
   LASTInputDev sduino
   MSGCNT     63
   NAME       SD_WS_33_TH_1
   NR         594
   STATE      T: 21.1 H: 76.0 D: 16.7
   TYPE       SD_WS
   bitMSG     00001111100000111100110110110001000000010100
   lastMSG    0F83CDB1014
   lastReceive 1527756325.10437
   sduino_DMSG W33#0F83CDB1014
   sduino_MSGCNT 63
   sduino_RAWMSG MS;P0=-7871;P2=-1960;P3=578;P4=-3954;D=030323232323434343434323232323234343434323234343234343234343232323432323232323232343234;CP=3;SP=0;R=0;m=0;
   sduino_RSSI -74
   sduino_TIME 2018-05-31 10:45:25
   READINGS:
     2018-05-31 09:52:55   D               16.7
     2018-05-31 10:45:25   battery         critical
     2018-05-31 10:45:25   channel         1
     2018-05-31 09:52:55   dewpoint        16.7
     2018-05-31 10:45:25   humidity        76
     2018-05-31 10:45:25   state           T: 21.0555555555556 H: 76
     2018-05-31 10:45:25   temperature     21.0555555555556
Attributes:
   alias      KG.WC.TH
   event-on-change-reading .*
   icon       temperature_humidity
   room       SD_WS
   stateFormat {sprintf("T: %.1f H: %.1f D: %.1f",
ReadingsVal($name,"temperature",0),
ReadingsVal($name,"humidity",0),
ReadingsVal($name,"dewpoint",0))}


Wenn weitere Protokolle benötigt werden, kann ich diese gerne noch einstellen.

Gruß
Thomas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Mai 2018, 13:06:43
Ich habe gestern angefangen die Batterie Reading anzupassen.

Fehlermeldung hast Du keine im Log? Es geht nur einfach nicht mehr?

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 31 Mai 2018, 13:38:22
Ich habe nur diese Zeile im Log gefunden
SD_WS_33_TH_1, unknown Event battery: critical

Seltsam war auch, dass die Devices scheinbar komplett verschwunden sind.
Nach dem Restotr waren sie dann wieder wie vorher wieder da.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 31 Mai 2018, 14:17:41
und da war auch noch mehr:
Please define SD_WS_33_TH_1 first
Cannot load module SD_WS
Cannot load module SD_WS
Cannot load module SD_WS
2018.05.31 09:26:02 1: configDB: global: unknown attribute uniqueID. Type 'attr global ?' for a detailed list.

/opt/fhem/FHEM/14_SD_WS.pm has too many errors.
syntax error at /opt/fhem/FHEM/14_SD_WS.pm line 526, near "elsif"
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 521.
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 520.
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 519.
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 517.
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 514.
Global symbol "$sign" requires explicit package name (did you forget to declare "my $sign"?) at /opt/fhem/FHEM/14_SD_WS.pm line 512.
Global symbol "$vorpre" requires explicit package name (did you forget to declare "my $vorpre"?) at /opt/fhem/FHEM/14_SD_WS.pm line 510.
Global symbol "$sign" requires explicit package name (did you forget to declare "my $sign"?) at /opt/fhem/FHEM/14_SD_WS.pm line 510.
2018.05.31 09:26:01 0: syntax error at /opt/fhem/FHEM/14_SD_WS.pm line 508, near "},"
2018.05.31 09:26:01 1: reload: Error:Modul 14_SD_WS deactivated:
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 31 Mai 2018, 15:58:54
siehe:
https://forum.fhem.de/index.php/topic,58397.0.html
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Mai 2018, 23:31:40
Zitat von: Papaloewe am 31 Mai 2018, 10:56:57
Nach dem heutigen Update der "14_SD_WS.pm" empfange ich meine Temperatur/feuchtsensoren vom Typ: 33
nicht mehr.
Modell: infactory FWS-310 https://www.pearl.de/a-NC5849-3041.shtml (https://www.pearl.de/a-NC5849-3041.shtml)

Ich habe den Syntaxfehler behoben, außerdem bin ich den Fall noch mal durchgegangen und habe den Batterie Zustand "ok oder low" getauscht.
Sollte damit jetzt korrekt dargestellt werden.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 01 Juni 2018, 10:57:43
ZitatIch habe den Syntaxfehler behoben, außerdem bin ich den Fall noch mal durchgegangen und habe den Batterie Zustand "ok oder low" getauscht.
Sollte damit jetzt korrekt dargestellt werden.

Ja, funktioniert jetzt prima.

Vielen Dank.

Gruß
Thomas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Horti am 01 Juni 2018, 11:34:51
Guten Morgen,

seit gestern Abend wird mein Temperatursensor in FHEM nicht mehr vernunftig empfangen. Die letzten lesbaren Meldungen waren
2018-05-31_19:48:45 Draussen_Temp T: 26.8
2018-05-31_19:48:45 Draussen_Temp temperature: 26.8
2018-05-31_19:51:36 Draussen_Temp battery: ok
2018-05-31_19:51:36 Draussen_Temp channel: 1


Seitdem sehe ich nur noch Meldungen wie
2018-06-01 11:29:36 CUL nanoCUL433 UNKNOWNCODE sEA10FE880CD;  480: 9072
2018-06-01 11:29:36 CUL nanoCUL433 UNKNOWNCODE sEA10FE880CC;  464: 9184
2018-06-01 11:29:36 CUL nanoCUL433 UNKNOWNCODE sEA10FE880CD;  464: 9120
2018-06-01 11:29:36 CUL nanoCUL433 UNKNOWNCODE sEA10FE880CD;  496: 9168
2018-06-01 11:29:36 CUL nanoCUL433 UNKNOWNCODE sEA10FE880CD;  496: 9088
2018-06-01 11:29:53 CUL nanoCUL433 UNKNOWNCODE s132102828E7;  480: 9008
2018-06-01 11:29:53 CUL nanoCUL433 UNKNOWNCODE s132102828E7;  480: 9024
2018-06-01 11:29:53 CUL nanoCUL433 UNKNOWNCODE s132102828E8;  480: 9008
2018-06-01 11:29:54 CUL nanoCUL433 UNKNOWNCODE s132102828EA;  496: 8992
2018-06-01 11:30:14 CUL nanoCUL433 UNKNOWNCODE s9180C2F0013;  464: 4016


Ich nutze zwar keinen SignalDuino, der Sensor nutzte bisher aber ein SignalDuino-Modul über CUL433: SD_WS07. Das heutige Update von FHEM hat nichts gebracht, die originale Mutterwetterstation empfängt den Sensor nach wie vor ohne Probleme.

Kann sich jemand einen Reim drauf machen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Papaloewe am 01 Juni 2018, 13:56:09
Ich würde mal behaupten du befindest dich im falschem Thread.

Wenn du nichts gändert hast und auch kein update gemacht hast, tippe ich mal auch ein Reichweiten-, bzw. Empfangsproblem.
Geh enfach mal näher ran mit dem Sensor an den nanoCUL und schau mal was passiert. Vielleicht reichen auch ein paar neue Batterien?

Gruß
Thomas
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Horti am 01 Juni 2018, 14:18:15
Wie gesagt, die Wetterstation empfängt ja den Sensor noch, und die reagiert sensibler auf Lageänderungen oder nachlassende Batterien. Der CUL empfängt ja auch was, kann es scheinbar nur nicht mehr interpretieren.

Ich habe noch andere ungelöste Probleme mit diesem Sensor, in anderen Threads ist allerdings nie was Brauchbares zusammengekommen:
https://forum.fhem.de/index.php/topic,69229.msg794301.html#msg794301 (https://forum.fhem.de/index.php/topic,69229.msg794301.html#msg794301)
https://forum.fhem.de/index.php/topic,35064.msg710618.html#msg710618 (https://forum.fhem.de/index.php/topic,35064.msg710618.html#msg710618)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Medel am 03 Juni 2018, 14:17:03
Hallo,

ich habe Funksteckdosen von Aldi Sender GT-9000, Empfänger GT-FSI-07
da diese mittels Protokoll Nr 49 unterstützt werden sollen habe ich dies mit P49#101011101100111010111110#R4 zu schalten.
leider hat es nicht funktioniert
Da ich das Protokoll schon auseinander genommen habe war ich mir sicher dass meine Codes auch stimmen.
Im Timing scheinen allerdings einige Fehler zu sein.
Ich habe es dann wie folgt geändert:

"49"    => ## quigg / Aldi gt_9000
{
            name => 'quigg_gt9000',
id          => '49',
clockabs      => 500,
one => [2,-1],
zero => [1,-2],
start => [6,-15],
format => 'twostate',
preamble => 'U49#', # prepend to converted message
#clientmodule    => '',    # not used now
modulematch     => '^U49#.*',  # not used now
length_min      => '22',
length_max      => '28',
},

danach ging es. leider wird aber immer noch beim Empfangen der falsche Code erkannt.
z. B.
U49#4000FC sollte aber A0007E sein.
manche werden auch gar nicht unter U49 erkannt
z.B.
A65D1E
wird aber meist unter Protokoll 5 richtig erkannt.

Hier noch meine Erkenntnisse zum Protokoll:
Es scheinen 2 verschiedene Protokollformen gesendet zu werden. Sie unterscheiden sich jeweils am Anfang
Meine Steckdosen reagieren aber immer nur auf den von mir beschriebenen Teil:
Start:
3000ms => 1
7000ms => 0
Daten High:
1000ms => 1
500ms => 0
Daten Low:
500ms => 1
1000ms =>0
das Ganze wird 4 mal wiederholt.
Die Fernbedienung wechselt dabei die Kodes bei jedem Tastenblock zwischen 4 möglichen. Dies ist aber soweit ich feststellen konnte nicht unbedingt erforderlich.
Im Anhang meine Kodeliste


Mfg

Mario

Im Anhang die Kodes meiner Fernbedienungen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 03 Juni 2018, 20:12:13
Zitat von: Medel am 03 Juni 2018, 14:17:03
Hallo,

ich habe Funksteckdosen von Aldi Sender GT-9000, Empfänger GT-FSI-07

Tia, ich denke an solchen Dosen haben wir schon ein paar Mal gewerkelt. Das Problem ist auch eigentlich der Sender und nicht die Dose.
Letzteres reagiert vermutlich auf ein Protokoll, die Fernbedienung ist so universell einsetzbar, dass sie mehrere Protokolle sendet (4 war mein letzter Stand).

Das Senden der vier Protokoll beschert uns leider ein kleines Problem im Signalduino. Die kommen sehr kurz hintereinander und dadurch, dass auch noch jede Sequenz mehrfacher wiederholt wird, passt nicht alles in den Empfangspuffer.

Die Schwierigkeit besteht darin, das Protokoll zu identifizieren, welches die Dose schaltet.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Medel am 03 Juni 2018, 21:55:04
Hallo,

also ich konnte nur 2 Protokolle bei meinen Sendern finden, die abwechseln gesendet werden.
Sie unterscheiden sich aber nur im 1. (high) und 2. (low) Bit in der Länge.

Es wird aber bei jedem gleichen Tastendruck eine andere Datensequenz (4 pro Taste) gesendet.
Soweit ich feststellen konnte ist es meinen Schaltsteckdosen aber egal ob der gleiche oder der nächste gesendet wird.

Gruß

Mario
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 11 Juni 2018, 20:40:03
Hallo zusammen,

ich betreibe schon seit ca. einem Jahr meinen Fhem Server. Hauptsächlich werden momentan vier Technoline TX29 DTH Temperatursensoren ausgelesen und damit mein Ventilator im Bad gesteuert. Der Ventilator wird über ein Selbstbau Homematic Akteur und ein nanoCUL gesteuert. Die Sensoren wurden bis jetzt auch über ein selbst kompilierten nanoCUL mit dem Lacrosse Befehl ausgelesen (868MHz). Jetzt würde ich jedoch gerne meinen Rolladen mit einem Rolladen7 Motor versehen. Dafür würde ich die Temperatursensoren gerne über einen SignalDuino auslesen, der dann auch den Rolladen steuert.

Jetzt habe ich meinen nanoCUL als SignalDuino geflashet und versucht auf 868.300MHz die Technolite Sensoren auszulesen. Leider ohne Erfolg. Es kommen einfach keine Nachrichten an, obwohl es genau mit der selben Hardware sehr gut mit dem nanoCUL geht. Gibt es irgendetwas was ich übersehen haben könnte?

Ich habe den SignalDuino in Fhem angelegt, das Atribut hardware auf nanoCC1101 gesetzt und geflashet. Anschließend die Frequenz auf 868.300 gestellt. Auch habe ich mal mit der Bandbreite und den Verstärkungen rumgespielt, aber ohne Erfolg.
Selbst in verbose 5 tauchen im Log nur die pings auf, sonst aber keine Signale.

Gibt es noch irgendetwas, was ich übersehen habe? 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 11 Juni 2018, 22:36:28
Welche Firmware hast Du geflasht?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 11 Juni 2018, 22:43:42
Schau mal:
Zitat von: RaspiLED am 11 Juni 2018, 00:42:04
Hi Ralf,
wir haben laut wiki die Firmware dev-r33 genommen. Die war von 03/2017.
Dann nehmen wir eine neuere von Github!?
Laut:
https://forum.fhem.de/index.php?topic=82379.0
Durch

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


Wie spielst Du so eine Nachricht eigentlich in Deinen Signalduino ein?

Danke und Gruß
Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 11 Juni 2018, 22:44:06
Ich bin so vorgegangen, wie hier beschrieben: https://wiki.fhem.de/wiki/SIGNALduino

Da habe ich sowohl die stable als auch die dev Version probiert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 11 Juni 2018, 23:03:56
OK, das heißt ich soll mit folgenden Befehl flashen?
set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_332rc1.hex

Ich probiere es morgen mal aus. Danke für den Hinweis.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 12 Juni 2018, 12:59:40
Ja ;-) Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 12 Juni 2018, 18:28:24
Hallo Stefan,

Ich wollte genauer wissen, welche Firmware (welche Datei) du geflasht hast.

Im Wiki werden ja mehrere Hardware spezifische genannt.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 12 Juni 2018, 18:51:07


Zitat von: RaspiLED am 11 Juni 2018, 22:43:42
Schau mal:
Gruß Arnd

Hi,

Da sollte man ein wenig aufpassen, das ist ein Fork von Ralf9.

Manche Änderungen sind vielleicht keine Änderungen zur aktuellen RC7.

So richtig bewerten, was er da alles geändert hat kann ich nicht, da mir leider Beschreibungen zu den Änderungen fehlen.
Dadurch ist aktuell nicht absehbar wann und welche Änderungen wieder zurück in die Firmware vom SignaldDuino Projekt fließen.
Für sachdieiche Hinweise bin ich dankbar.

Grüße Sven

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 12 Juni 2018, 19:23:37
Hi Sidey,
Da ich geflasht habe, gebe ich mal die Antwort:


update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
update
shutdown reboot
attr MYSDUINO model nanoCC1101
set MYSDUINO flash


Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 12 Juni 2018, 20:05:09
@raspiLED: genau so habe ich es gemacht.
Den anderen Befehl kann ich wahrscheinlich erst am Wochenende ausprobieren.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 12 Juni 2018, 20:38:38
Also ich habe es jetzt doch noch ausprobieren können.
Nach dem flashen empfängt der signalDuino auf 434... Daten, die wahrscheinlich von einem Teperatursensor von meinen Nachbarn stammen. Wenn ich ihn auf 868.300 umstelle nichts mehr. Also werden meine Daten noch nicht empfangen.

Scheinbar war mein Fehler, dass ich ihn danach wieder auf genau 434.000Mhz umgestellt habe und nicht auf die Anfangsfrequenz.

D.h. der Signalduino funktioniert generell, aber ich empfange noch nicht die gewünschten Sensoren. Mein CC1101 ist eigentlich auf 868MHz optimiert.

Gibt es Vorschläge, was ich noch ändern muss?
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 12 Juni 2018, 20:43:15
Hast Du die Frequenz richtig gesetzt?

set SDUINO cc1101_freq 433.920

IT 433.920 MHz
Somfy 433.420 MHz
Homematic/MAX!/LaCrosse 868.300 MHz

Hast Du die Attribute gesetzt?

attr SDUINO cc1101_frequency 433
oder
attr SDUINO cc1101_frequency 868

attr SDUINO hardware nanoCC1101


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 14 Juni 2018, 08:27:12
Ich hab die Einstellungen noch mal ausprobiert und bekomme die Sensoren trotzdem nicht rein.

Gibt es noch Ideen, woran es liegen könnte? Oder kann ich noch irgendwelche Informationen zur Verfügung stellen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 14 Juni 2018, 08:56:00
Naja, wir sind blind ;-)
Fangen wir mal an:

get SDUINO cmds
get SDUINO config
get SDUINO protocollIDs
get SDUINO version
get SDUINO ccconf
list SDUINO


Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 14 Juni 2018, 09:38:50
Hi,

Eventuell muss auch noch die Bandbreite und die Empfangs Symbolrate angepasst werden.

Ich weiss leider nicht, wie die Sensoren exakt senden.

Verbose 5 am sduino hilft auch um zu sehen ob überhaupt Mal etwas empfangen wurde.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 16 Juni 2018, 10:10:18
Entschuldigung, dass es etwas länger gedauert hat.
Jetzt habe ich alle Tests noch einmal in Ruhe machen können.

cmds: V R t X F S P C r W x e
config: MS=1;MU=1;MC=1
protocolIDs:

ID    modulname       protocolname # comment

  0 MS CUL_TCM97001    weather1 # Logilink, NC, WS, TCM97001 etc
  1 MS SD_RSL          ConradRSL
  2 MS SD_AS           AS, Self build arduino sensor # developModule. SD_AS module is only in github available
  3 MS IT              itv1
3.1 MS IT              itv1_sync40 # IT remote Control PAR 1000
  4 MS IT              arctech2
  5 MU IT              unitec6899
  6 MS                 weatherID6
  7 MS SD_WS07         weatherID7 # EAS800z, FreeTec NC-7344
  8 MU CUL_TX          TX3 Protocol
  9 MU SD_WS09         CTW 600 # FunkWS WH1080/WH3080/CTW600
10 MC OREGON          OSV2o3
11 MC SD_AS           AS
12 MC hideki          Hideki protocol # Hideki messages are sometimes received as inverted (check in sub)
13 MS FLAMINGO        FLAMINGO FA21
13.1 MU FLAMINGO        FLAMINGO FA21 / LM-101LD # FLAMINGO oder Unitec Rauchmelder
13.2 MS FLAMINGO        LM-101LD Rauchm # Unitec Rauchmelder
14 MS                 Heidemann HX
15 MS                 TCM Bell
16 MU Dooya           Dooya shutter
17 MS IT              arctech
18 MC OREGON          OSV1
20 MU                 livolo
21 MU                 einhell garagedoor
22 MS                 TX-EZ6
23 MS                 perl unknown
24 MU                 visivon remote
25 MS                 les led remote
26 MU                 remote26
27 MU                 remote27
28 MU                 IC Ledspot
29 MU                 HT12e remote
30 MU SD_UT           unitec47031 # developModule. SD_UT module is only in github available
31 MU                 pollin isotronic
32 MS                 freetec 6946
33 MS SD_WS           weather33
35 MS IT              HE800 # Homeeasy
36 MU                 socket36
37 MU SD_WS           Bresser 7009994
38 MS CUL_TCM97001    weather38
39 MU RFXX10REC       X10 Protocol
40 MU                 romotec
41 MS                 elro doorbell # Elro (Smartwares) Doorbell DB200
43 MC SOMFY           Somfy RTS
44 MU SD_WS           BresserTemeo
44.1 MU SD_WS           BresserTemeo
45 MU Revolt          Revolt
46 MU                 EKX1BE
47 MC SD_WS_Maverick  Maverick protocol
48 MU                 TFA Dostmann
49 MU                 quigg_gt9000
50 MU SD_WS           optus_XT300
51 MS SD_WS           weather51 # IAN 275901 Wetterstation Lidl
52 MC OREGON          OS_PIR
55 MS IT              quigg_gt1000
56 MU                 Celexon
57 MC                 m-e
58 MC                 tfa 30.3208.0
59 MU                 AK-HD-4
60 MU CUL_WS          WS2000
61 MU FS10            FS10 # Remote Control (434Mhz)
62 MU IT              Clarus_Switch
63 MU                 Warema # developId, is still experimental
64 MU SD_WS           WH2
65 MS IT              HE_EU # Homeeasy
66 MU CUL_TX          WS7035
67 MU CUL_TX          WS7053
68 MS CUL_TCM97001    PFR-130
69 MU                 Hoermann
70 MU CUL_FHTTK       FHT80TF # Door/Window switch (868Mhz)
71 MU SD_WS           PV-8644 # infactory Poolthermometer
72 MU Siro            Siro shutter # developModule. Siro is not in github or SVN available
72.1 MS Siro            Siro shutter # developModule. Siro is not in github or SVN available
73 MU FHT             FHT80 # Roomthermostat (868Mhz only receive)
74 MU FS20            FS20 # Remote Control (868Mhz only receive)
75 MU SD_RSL          ConradRSL2
76 MU                 xm21 # reserviert, LED Lichtrekette on
76.1 MU                 xm21 # reserviert, LED Lichtrekette off
77 MU CUL_TX          NANO_DS1820_4Fach # Seltbau Sensor
78 MU SIGNALduino_un  geiger # geiger blind motors
79 MU                 VTX-BELL_Funkklingel

version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506926Z-if00-port0@57600
   DMSG       W58#45C7744445DE0
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506926Z-if00-port0@57600
   FD         14
   LASTDMSG   W58#45C7744445DE0
   MSGCNT     17
   NAME       sduino
   NR         355
   PARTIAL   
   RAWMSG     MC;LL=-993;LH=970;SL=-479;SH=514;D=05747117777443E002BA388BBBBA21F0015D1C45F5747117777443E002BA388BBBBA21F0015D1C45DDDD10F8;C=487;L=349;R=235;
   RSSI       -84.5
   STATE      opened
   TIME       1529136086
   TYPE       SIGNALduino
   cc1101_frequency 868
   sendworking 0
   unknownmessages 2018-06-16 09:58:48-MU;P0=966;P1=-984;P2=533;P3=-481;D=0123230123232323010123230321012301232323232323232;CP=2;R=235;
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   versionmodul v3.3.3-dev_20.04.
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-06-16 10:04:33   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-06-16 10:03:05   cmds             V R t X F S P C r W x e
     2018-06-16 10:03:25   config          MS=1;MU=1;MC=1
     2018-06-16 09:57:20   ping            OK
     2018-06-16 09:52:19   state           opened
     2018-06-16 10:04:16   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     13.2
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     65
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
     8
     9
Attributes:
   cc1101_frequency 868.300
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5


Im Logfile mit verbose 5 steht eigentlich nicht viel:
2018.06.16 10:06:19 5: AddSendQueue: sduino: P (1)
2018.06.16 10:06:20 5: sduino SW: P
2018.06.16 10:06:20 4: sduino/msg READ: OK
2018.06.16 10:06:20 5: sduino/noMsg Parse: OK
2018.06.16 10:06:20 5: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2018.06.16 10:06:20 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2018.06.16 10:07:19 4: sduino/keepalive ok, retry = 0
2018.06.16 10:08:19 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2018.06.16 10:08:19 5: AddSendQueue: sduino: P (1)
2018.06.16 10:08:20 5: sduino SW: P
2018.06.16 10:08:20 4: sduino/msg READ: OK
2018.06.16 10:08:20 5: sduino/noMsg Parse: OK
2018.06.16 10:08:20 5: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2018.06.16 10:08:20 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2018.06.16 10:09:19 4: sduino/keepalive ok, retry = 0
2018.06.16 10:10:19 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2018.06.16 10:10:19 5: AddSendQueue: sduino: P (1)
2018.06.16 10:10:20 5: sduino SW: P
2018.06.16 10:10:20 4: sduino/msg READ: OK
2018.06.16 10:10:20 5: sduino/noMsg Parse: OK
2018.06.16 10:10:20 5: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2018.06.16 10:10:20 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2018.06.16 10:11:19 4: sduino/keepalive ok, retry = 0
2018.06.16 10:12:19 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2018.06.16 10:12:19 5: AddSendQueue: sduino: P (1)
2018.06.16 10:12:20 5: sduino SW: P
2018.06.16 10:12:20 4: sduino/msg READ: OK
2018.06.16 10:12:20 5: sduino/noMsg Parse: OK
2018.06.16 10:12:20 5: sduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2018.06.16 10:12:20 4: sduino/HandleWriteQueue: nothing to send, stopping timer


Was ich jetzt gesehen habe, dass der nanoCUL vorher mit dem Modul "IT+ bitrate 17.241 kbps" gelaufen ist.
Jetzt wollte ich mal ausprobieren, die DataRate umzustellen, hab aber leider den Befehl nicht finden können. Kann man die DataRate einfach über FHEM umstellen oder muss dafür die Firmware neu gebaut werden?

Sollten denn die Technoline TX29DTH-IT generell vom SignalDuino unterstützt werden?

EDIT: Logeinträge mit eingefügt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 17 Juni 2018, 00:52:38
Zitat von: StefanH am 16 Juni 2018, 10:10:18

version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

Aktualisiere bitte einmal die Firmware:
set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC7/SIGNALDuino_nanocc1101.hex

Zitat von: StefanH am 16 Juni 2018, 10:10:18
Jetzt wollte ich mal ausprobieren, die DataRate umzustellen, hab aber leider den Befehl nicht finden können. Kann man die DataRate einfach über FHEM umstellen oder muss dafür die Firmware neu gebaut werden?

Sollten denn die Technoline TX29DTH-IT generell vom SignalDuino unterstützt werden?

Die Datarate kann man umstellen, wenn man die Register ändert. Jetzt weiss ich leider nicht mehr 100% wie man das macht :(

Zumindest weiss ich, dass die Datenrate aus MDMCFG3 und MDMCFG4 bestimmt wird. Mit den Default werten aus der Doku, solltest Du besser hinkommen:
http://www.ti.com/lit/ds/symlink/cc1101.pdf

MDMCFG4 liegt in Register 12 (EEProm) bzw. Register 10 des CC1101.

0x8C schreibst Du so hinein:
get sduino raw W128C


0x22 schreibst Du dann noch in MDMCFG3  so hinein:
get sduino raw W1322

Ein get sduino ccconf sollte dann die eingestellte Baudrate anzeigen.

Grüße Sidey


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 17 Juni 2018, 09:51:01
get oder set für's Schreiben?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 17 Juni 2018, 10:19:32
Danke für den Hinweis zum Schreiben der Register. Scheint auch gut zu funktionieren.
Ich habe jetzt folgende Einstellungen probiert:

get sduino raw W1209
get sduino raw W135C


Damit komme ich auf eine Datarate von 17257,69 Baud, was ja in dem Bereich liegen sollte, wo es klappen könnte.

version: V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud)

Die Bandweite und die Verstärkungen habe ich jetzt so eingestellt, wie sie beim nanoCUL voreingestellt sind im Lacrosse Modus.

Trotzdem nix. Echt seltsam.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: StefanH am 20 Juni 2018, 19:45:45
Ich habe jetzt die Konfiguration aus dem nanoCUL kopiert und werde sie jetzt dann mal in den SignalDuino übertragen.
Spricht irgendetwas dagegen, dass es dann klappen müsste?
// This is the default - equals Mode 1
const uint8_t PROGMEM NATIVE_CFG[46] = {
 
  CC1100_FSCTRL1, 0x06,
  CC1100_FREQ2, 0x21,   // FREQ2     Frequency control word, high byte.
  CC1100_FREQ1, 0x65,   // FREQ1     Frequency control word, middle byte.
  CC1100_FREQ0, 0x6A,   // FREQ0     Frequency control word, low byte.
 
  CC1100_MCSM1, 0x00,   // always go into IDLE
  CC1100_MCSM0, 0x18,
  CC1100_FOCCFG, 0x16,
  CC1100_AGCCTRL2, 0x43,
  CC1100_AGCCTRL1, 0x68,
  CC1100_FSCAL1, 0x00,
  CC1100_FSCAL0, 0x11,
 
  CC1100_IOCFG2, 0x01,   // IOCFG2  RX FIFO at CC1100_FIFOTHR given byte count
  CC1100_IOCFG0, 0x46,   // IOCFG0  not used
 
  CC1100_SYNC0, 0xd4,
  CC1100_SYNC1, 0x2d,
 
  CC1100_FIFOTHR, 2,     // 12 byte in RX - see page 72 of CC1101.pdf
 
  CC1100_PKTCTRL1, 0x00,   // PKTCTRL1  Packet automation control.
  CC1100_PKTCTRL0, 0x02,   // PKTCTRL0  Packet automation control - infinite len
 
  CC1100_MDMCFG4, 0x89,   // MDMCFG4   Modem configuration.
  CC1100_MDMCFG3, 0x5C,   // MDMCFG3   Modem configuration.
  CC1100_MDMCFG2, 0x06,   // !! 05 !! MDMCFG2   Modem configuration.
 
  CC1100_DEVIATN, 0x56,   // DEVIATN   Modem deviation setting (when FSK modulation is enabled).
 
  0xff
};
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 20 Juni 2018, 20:09:40
Hi,

Grundsätzlich spricht nichts dagegen.
Ich habe mich jetzt nicht weiter mit den Registern beschäftigt.
Wichtig ist halt, dass Du die Register passend für die Sensoren wählst.

Ob was Empfang wird, siehst Du mit Verbose 4.
Du könntest auch die Sensoren noch Mal inspizieren, was da vielleicht noch alles steht.
Nach meinen Recherchen sendet dein Sensor OOK und nicht FSK.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: thunder1902 am 22 Juni 2018, 11:19:02
Hallo!

Ich wollte mir ein Signalduino bauen - aber ich komme nicht weiter.

Ich habe einen Arduino Mini Pro 8MHZ, 3,3V, einen CC1101 in 433MHZ-Version und ein FTDI in Verwendung.

Wenn ich das ganze zusammenbaue, und die Firmware draufspiele, passiert erstmal gar nix.

Wenn ich die Firmware selbst kompiliere (3.3.1-RC7) und draufspiele, kommt im Debug-Modus folgende Ausgabe:

Reading values fom eeprom
CCInit SRES Started
POR Done
CCVersion=4
CCPartnum=0
CC1101 found
Starting timerjob
CC1100_PKTCTRL0=50 vs EEPROM PKTCTRL0=50
C1100_IOCFG2=13 vs EEPROM IOCFG2=13
receiver enabled


Nun passiert gar nichts mehr. Er reagiert nicht auf Befehle - gar nichts.

Hab dann etwas recherchiert - und das hier gefunden:
https://github.com/RFD-FHEM/RFFHEM/issues/125

Ich hab also den Pin2 gelöst, ein "e" gesendet, und Pin wieder dran gelötet. Wieder nichts.

Hab das ganze auch mit 'nem Arduino Mini Pro mit 16MHZ probiert. Gleiches Ergebnis.
Bin mit meinem Latein am Ende.

Kann mir da jemand helfen???

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Juni 2018, 09:32:27
Hi,

Das sieht so aus, als ob der Interrupt ständig auslöst.
Pin2 also erst mal trennen bzw. Steckbar gestalten.

Den Debug Meldungen nach, wird der cc1101 korrekt initialisiert.

Mit der bereits compilierte Firmware (RC7) hast Du das identische Verhalten?

Ich würde den pro Mini jetzt ohne pin2 starten und dann die Register auslesen.
Mit dem Befehl C99n spuckt er dir aus (soweit ich mich erinnere).

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Juni 2018, 23:28:34
Hast Du beachtet,  daß wenn Du eine miniCUL Firmware verwenden willst, daß Du auch die miniCUL Verkabelung verwenden mußt:
GDO0 auf  D2/PD2
GDO2 auf  D3/PD3
LED auf  D4/PD4
Wenn bei version die Frequenz stimmen soll, dann muß bei 433 MHz A0/PC0 mit GND verbunden werden, wenn man ganz sicher gehen will, dann 50-100 Ohm als Strombegrenzung im Fehlerfall.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Mave am 04 Juli 2018, 15:40:36
Hallo zusammen,

ich habe schon seit einiger Zeit einen SignalDuino im Einsatz um meine Somfy Jalousien zu steuern.
Funktionieren tut es prinzipiell ganz hervorragend.

Allerdings lassen sich nicht alle 3 angesteuerten Jalousien gleichzeitig bewegen. Manchmal fährt nur eine oder zwei, manchmal fahren alle.

Ich vermute, dass der Empfang der Somfy Rohrmotoren nicht ideal ist. Da hatte ich früher auch schon Probleme mit der Somfy Fernbedienung.

Jetzt würde ich das Problem gerne mal angehen und entweder das Signal des SignalDuino verstärken (eventuell bessere Antenne?), einen zweiten SignalDuino (als Repeater?) einsetzen oder den SignalDuino näher an den Jalousien positionieren, was aber bedeuten würde, dass ich den SignalDuino nicht mehr an meinem Haupt-FHEM-Server betreiben kann (eventuell zweiten RPi mit FHEM2FHEM?).

Über fachkundige Empfehlungen würde ich mich sehr freuen.

Vielen Dank.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 04 Juli 2018, 16:15:28
Moin
Dann nimm doch den SignalESP! Der braucht nur WLAN und 5V.
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Mave am 04 Juli 2018, 20:03:12
Hey Chris,

vielen Dank für Deinen Tipp.

Und wo kann ich so ein Teil bekommen?

Grüße Mave
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 Juli 2018, 20:44:36
Hi,
Zeig uns doch mal ein list von Deinem Signalduino nachdem Du die get ccconf und patable gezogen hast.

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 04 Juli 2018, 21:19:34
Achso so flasht man:

Zitat von: Sidey am 03 Juli 2018, 22:26:21

https://github.com/RFD-FHEM/SIGNALDuino/releases/tag/3.3.1-RC7

Flashen geht einfach über z.B. set SIGNALduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC7/SIGNALDuino_nanocc1101.hex


Grüße Sidey

Oder allgemeiner hier:

https://forum.fhem.de/index.php/topic,58396.msg740610.html#msg740610 (https://forum.fhem.de/index.php/topic,58396.msg740610.html#msg740610)

Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Mave am 04 Juli 2018, 22:33:37
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021IV4-if00-port0@57600
   DMSG       W50#E0A09172472A
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021IV4-if00-port0@57600
   FD         11
   ITClock    250
   LASTDMSG   W50#E0A09172472A
   MSGCNT     7
   NAME       SDUINO433
   NR         51
   NR_CMD_LAST_H 1
   PARTIAL   
   RAWMSG     MU;P0=-29438;P1=504;P2=-968;P3=1259;P4=-9672;P5=120;D=01212123232323232123212323232323212323212323232123212121232321232321232323212121232321232123212303232323212345;CP=1;R=235;
   RSSI       -84.5
   STATE      opened
   TIME       1530572503
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-07-04 22:28:45   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:3173.83Baud)
     2018-07-04 22:29:03   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2018-07-04 21:51:48   ping            OK
     2018-06-29 13:17:47   state           opened
     2018-06-29 13:17:47   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   XMIT_TIME:
     1530729000
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     43
   msIdList:
   muIdList:
     50
Attributes:
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   room       Devices
   verbose    3
   whitelist_IDs 43,50
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 05 Juli 2018, 07:06:05
Zitat von: Mave am 04 Juli 2018, 20:03:12
Hey Chris,

vielen Dank für Deinen Tipp.

Und wo kann ich so ein Teil bekommen?

Grüße Mave
Moin
Du brauchst z.B. einen WemosD1 und ein CC1101, 6 Draehte und ein USB Netzteil! https://wiki.fhem.de/wiki/SIGNALduino#Hardware
Locutus hatte eine Zeit lang mal Adapterplatinen verkauft, evtl. hat das wer anders uebernommen!?
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 05 Juli 2018, 07:38:08
Hi,
Dann setze die patabale doch auch mal auf +10 statt nur +5. Dass erhlht die Sendestärke ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Mave am 05 Juli 2018, 08:46:30
Okay, werde ich mal testen.

Danke.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 22 Juli 2018, 15:26:01
Mal 'ne etwas andere Frage, die aber unmittelbar mit meinem SIGNALduino 433 MHz und dem autocreate zu tun hat: Wie kriege ich raus wo welches Device ist?

Ich habe draußen ein TCM-Thermometer hängen (erkannt/created als OREGON THR128_0a_1). Es tauchen aber noch zwei andere auf, vermutlich von Nachbarn. Um die angezeigte Temperatur bewerten zu können (Sonne/Schatten/drinnen/draußen) wäre es nun hilfreich rauszukriegen wo die Dinger aufgehängt sind. Intensive Kommunikation mit den Nachbarn könnte zu ungewünschten Nebeneffekten führen (Der zapft mein Thermometer an? Was sonst noch???).

Welche Antenne bräuchte mein SIGNALduino, um die Richtung der Signale relativ gut einschätzen zu können?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 23 Juli 2018, 07:54:17
Unmöglich mit einfachen Mitteln.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 23 Juli 2018, 11:09:23
Um herauszufinden, wo ein Gerät sendet, kann man ein Notebook und eine SDR (z.B. einen TV-Stick) nehmen.
Dann muss man halt an einer Stelle anfangen und die Empfangsstärke messen. Von dort in eine Richtung gehen und wieder messen.
Ist aber mühsam.

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 26 Juli 2018, 09:12:38
Ich möchte einen Wasserzähler mit selbst gebauter ableseeinheit auslesen (allein mein Problem, wie das umgesetzt wird) und das Ergebnis, weil ich Strom sparen will und den Signalduino nutzen möchte, via 433 MHz übertragen. Jetzt meine Frage:

Welches Protokoll eignet sich am besten, um eine ganze Zahl via Signalduino (also einem einfachen 433 Funkmodul) zu übertragen und dann in FHEM zu empfangen und auszuwerten? Wie sähe die Sendeabfolge aus bzw wo kann ich nachlesen, wie ich das (zB mit einem attiny) programmieren kann?

Der Signalduino würde also von mir für einen anderen Zweck ,,missbraucht".


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 26 Juli 2018, 17:51:20


Zitat von: andies am 26 Juli 2018, 09:12:38


Welches Protokoll eignet sich am besten, um eine ganze Zahl via Signalduino (also einem einfachen 433 Funkmodul) zu übertragen und dann in FHEM zu empfangen und auszuwerten? Wie sähe die Sendeabfolge aus bzw wo kann ich nachlesen, wie ich das (zB mit einem attiny) programmieren kann?

Schau dir doch mal arduino Sensor an.
https://github.com/RFD-FHEM/ArduinoSensor

Ich würde dir aber empfehlen es mit mysensors zu realisieren :)

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 26 Juli 2018, 18:55:16
Zitat von: Sidey am 26 Juli 2018, 17:51:20
Ich würde dir aber empfehlen es mit mysensors zu realisieren :)
Ihr habt Euch abgesprochen, oder?
;-)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 27 Juli 2018, 11:24:03
Ich habe eine andere Lösung:

https://github.com/RFD-FHEM/ArduinoSensor/blob/master/SensorTransmitter/SensorTransmitter.h

dann meldet sich der Sensor als Wetterstation. Ich habe das Modul noch erweitert und wollte meinen Regentonnenfüllstand bei Gelegenheit dokumentieren.

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 31 Juli 2018, 12:59:53
Hallo,

ich habe aktuelle die Firmware V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 im Einsatz. Es gibt doch neuere Versionen. Die Frage ist können die Somfy RTS? Und wie bekomme ich die dann geflasht? Im Moment halte ich die obige Version ja fest.

Grüße und Danke

Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 31 Juli 2018, 15:28:47
Hi,
Somfy sendet doch nur auf 433.420 MHz anstatt 433.920 MHz und wird schon ewig von der Signalduino Plattform unterstützt.
Oder verstehe ich Deine Frage falsch?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 31 Juli 2018, 22:03:35
Zitat von: maddinthebrain am 31 Juli 2018, 12:59:53
ich habe aktuelle die Firmware V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 im Einsatz. Es gibt doch neuere Versionen. Die Frage ist können die Somfy RTS? Und wie bekomme ich die dann geflasht? Im Moment halte ich die obige Version ja fest.

Die aktuellste Version ist hier zu finden:
https://github.com/RFD-FHEM/SIGNALDuino/releases

Wenn ich mal wieder einen kühlen Kopf habe, dann bau ich den Updateprozess im Modul um, damit man die direkt auswählen kann.

Wie Du flashen kannst, steht im Wiki:
https://wiki.fhem.de/wiki/SIGNALduino#Flashen_einer_Firmware_.C3.BCber_HTTP


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 02 August 2018, 08:48:59
Zitat von: RaspiLED am 31 Juli 2018, 15:28:47
Hi,
Somfy sendet doch nur auf 433.420 MHz anstatt 433.920 MHz und wird schon ewig von der Signalduino Plattform unterstützt.
Oder verstehe ich Deine Frage falsch?
Gruß Arnd


Gesendet von iPhone mit Tapatalk

Hallo,

Ich hatte mal das Problem, dass nach einem Update von der angebenen Version Somfy nicht mehr ging. Und dann hieß zu dem Zeitpunkt vor einem Jahr würde nur diese Spezialversion dies unterstützen. Da kommt die Frage her. Gibt es eine Übersicht was die aktuelle Version alles Unterstützt?

Wenn Somfy dabei ist, ist alles in Butter.

Grüße Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 August 2018, 21:09:33
Probier es aus, dann wissen wir mehr.

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 02 August 2018, 22:42:36
Yup, es funzt! Dankeschön! Ich schau auch mal ob die restlichen Sensoren auch gehen bzw. noch zuverlässiger werden. Ich gebe bei Gelegenheit mal ne Rückmeldung. Ich habe verschiedene Oregon Sensoren, eine Wh1080, den Somfyantrieb.

Schöne Zeit

Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 06 August 2018, 15:01:22
So ich habe mal, die Situation ein paar Tage beobachtet. Ergebnis hat zwei Seiten:


Ich habe eine ganz generelle Frage: Ist die Labe der Antenne der Transcievers wichtig? Also ob diese waagerecht liegt oder senkrecht steht. Ich hatte gelesen, dass es eine Polarisation der Funksignale gibt.

Viele Grüße

Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 August 2018, 19:28:11
Kannst Du bitte mal beim 868MHz Signalduino über ein Zeitraum von ca 10-20 Minuten die empfangenen  MU-Nachrichten posten?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 06 August 2018, 22:04:00
Zitat von: Ralf9 am 06 August 2018, 19:28:11
Kannst Du bitte mal beim 868MHz Signalduino über ein Zeitraum von ca 10-20 Minuten die empfangenen  MU-Nachrichten posten?

Gruß Ralf

Mach ich gerne, wie soll ich das am besten aufzeichnen?

Grüße Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 August 2018, 22:13:56
Mit Verbose 4 beim  868MHz Signalduino

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 06 August 2018, 22:19:19
Hier mal 10min. Ich hoffe es reicht.

Events (Filter: sduino.*)   FHEM log   ResetCreate/Modify Device

2018.08.06 22:05:17 4 : sduino2/msg READ: MU;P0=-986;P1=1458;P2=473;P3=844;P4=-6072;D=01010101020102010101020201010101010102020101034;CP=1;R=15;
2018.08.06 22:05:17 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:05:17 4 : sduino2/msg READ: MS;P0=-5472;P1=-15244;P2=-994;P5=432;P6=1448;D=50525252526252526252625152526252626262526262620;CP=5;SP=0;R=18;
2018.08.06 22:05:17 4 : sduino2/msg READ: MU;P0=-1948;P1=892;P2=-985;P3=1463;P4=472;P5=-11020;D=0123242323242323232354242323242323232423242423232323232424;CP=4;R=210;
2018.08.06 22:05:17 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:05:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:06:05 4 : sduino2/msg READ: MS;P1=1409;P2=-1023;P3=459;P4=-10088;P5=350;P6=844;P7=-15320;D=145212121232123212121212121212121212121212121212121212121212121212121232323232123212126712121212325;CP=1;SP=4;R=15;
2018.08.06 22:06:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:06:53 4 : sduino2/msg READ: MU;P0=462;P1=-979;P2=1462;P3=952;P4=-10212;D=010121210121212101210121212121212121212121212134;CP=2;R=14;
2018.08.06 22:06:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:06:53 4 : sduino2/msg READ: MU;P0=-993;P1=1399;P2=372;P3=492;D=010201010101010101010303030301030101010101010303010101030101010101;CP=1;R=14;
2018.08.06 22:06:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:06:53 4 : sduino2/msg READ: MS;P0=990;P1=466;P2=-982;P3=1459;P5=-15736;P7=-26248;D=1532321232320732323232323232323232123232323205021232323232323212123232321232323232321;CP=1;SP=5;R=14;
2018.08.06 22:07:41 4 : sduino2/msg READ: MU;P0=264;P1=-376;P2=648;P3=-986;P4=476;P5=1449;P6=-15340;P7=892;D=0123434343434343435343535343534353534343535343534353534353535343535343534353535353535353535353535353535353567353535343434343534353535353535343435353534353534353434;CP=4;R=15;
2018.08.06 22:07:41 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:07:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:08:29 4 : sduino2/msg READ: MU;P0=487;P1=-1068;P2=1449;P3=110;P4=-10928;P5=-168;P7=-2220;D=010101010101010121012121012101212101013435373531;CP=0;R=13;
2018.08.06 22:08:29 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:08:29 4 : sduino2/msg READ: MU;P0=-176;P1=136;P2=-976;P3=1467;P4=480;P5=-31036;P6=1140;P7=-15496;D=01232323242323242324232323232323232323232323232323232323232323232323232323242424242324232323232323242423232424232423232323542424242424242426732424232324232423232423232324232324232423232323232323232323232323232323232323232323232323232324242424232423232323;CP=3;R=13;O;
2018.08.06 22:08:29 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:08:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:09:14 3 : Defining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
2018.08.06 22:09:17 4 : sduino2/msg READ: MU;P0=455;P1=-10250;P2=156;P3=-993;P4=1455;P6=948;D=012343034343034303434303034343034303614303434303430343434343434343434343434343434343434343434343434343434303030303430343434343434303034343030343034343434;CP=4;R=13;
2018.08.06 22:09:17 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:09:26 3 : Defining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
2018.08.06 22:09:31 3 : Defining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
2018.08.06 22:09:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:10:05 4 : sduino2/msg READ: MU;P0=112;P1=-136;P2=156;P3=-180;P4=487;P5=-982;P6=1398;P7=-11072;D=3454545454545454565456565456545656545456565456545656545656565656565456545656565656565656567012;CP=4;R=14;
2018.08.06 22:10:05 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:10:05 4 : sduino2/msg READ: MU;P0=1457;P1=-988;P2=477;P3=-31024;P5=-5588;P6=164;P7=-112;D=0101212101010101010101010101012121212101210101010101012121010101012121210101232567;CP=2;R=22;
2018.08.06 22:10:05 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:10:05 4 : sduino2/msg READ: MU;P0=-1508;P1=1405;P2=-991;P3=452;P4=-10916;D=01232121212121212321232121212121212121214;CP=1;R=14;
2018.08.06 22:10:05 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:10:05 4 : sduino2/msg READ: MU;P0=-1316;P1=1451;P2=-994;P3=475;D=012121212121212121212121232323232123212121212121232321212121232323212123;CP=1;R=213;
2018.08.06 22:10:05 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:10:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:10:53 4 : sduino2/msg READ: MU;P0=224;P1=-978;P2=1463;P3=475;P4=1128;P5=-11168;D=012131212131213121213131212131213121213121212121212131213121212121212145;CP=2;R=19;
2018.08.06 22:10:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:10:53 4 : sduino2/msg READ: MU;P0=-156;P1=92;P2=-448;P3=136;P4=-985;P5=1467;P6=475;D=012345464646464546454545454545464645454545464646454546;CP=6;R=210;
2018.08.06 22:10:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:11:41 4 : sduino2/msg READ: MU;P0=442;P1=-1030;P2=1456;P3=-28636;P4=184;D=0101212121010101012121012101212121212121212121212121212121212121212121212121212121010101012101212121212121010121210121210121012123010101010143;CP=2;R=14;
2018.08.06 22:11:41 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:11:41 4 : sduino2: decoded matched MU Protocol id 9 dmsg P9#C7940000007A064A length 64 RSSI = -67
2018-08-06 22:11:41 SIGNALduino sduino2 UNKNOWNCODE P9#C7940000007A064A
2018.08.06 22:11:41 3 : sduino2: Unknown code P9#C7940000007A064A, help me!
2018.08.06 22:11:41 4 : sduino2/msg READ: MU;P0=-1083;P1=1459;P2=475;P3=824;P4=-5140;P5=116;D=010101010101020101010202020201010201020101010101010101010101010101010101034505;CP=1;R=21;
2018.08.06 22:11:41 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:11:41 4 : sduino2/msg READ: MU;P0=1350;P1=-975;P2=494;P3=-5176;D=0101210101010101212121210121010101010101212101012101012103;CP=2;R=212;
2018.08.06 22:11:41 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:11:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:12:48 4 : sduino2/KeepAlive not ok, retry = 1 -> get ping
2018.08.06 22:12:49 4 : sduino2/msg READ: OK
2018.08.06 22:12:49 4 : sduino2/HandleWriteQueue: nothing to send, stopping timer
2018.08.06 22:13:17 4 : sduino2/msg READ: MS;P0=1459;P1=474;P5=-1029;P6=-10488;P7=308;D=0605050505050505050505151515150515050505050505760515150505150;CP=0;SP=6;R=15;
2018.08.06 22:13:17 4 : sduino2/msg READ: MU;P0=732;P1=474;P2=-981;P3=1458;P4=1116;P5=-10320;P6=264;D=12123212121212124562123232121232321232123232321212121232321232120;CP=1;R=17;
2018.08.06 22:13:17 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:13:17 4 : sduino2/msg READ: MU;P0=-1031;P1=437;P2=1409;P3=904;P4=-5496;D=01010202020202020202020202020202020202020202020201010101020102020202020201034202010102020102;CP=2;R=19;
2018.08.06 22:13:17 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:13:48 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:14:05 4 : sduino2/msg READ: MU;P0=-976;P1=480;P2=1466;D=0101010201020202020202010201020202010102020102;CP=1;R=210;
2018.08.06 22:14:05 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:14:49 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:14:53 4 : sduino2/msg READ: MU;P0=136;P1=-624;P2=484;P3=-10224;P4=92;P5=-1051;P6=1452;P7=176;D=0123456525656525652565652525656525652565656525252525656525652565656565656565656565656565656565656565656523257;CP=6;R=14;
2018.08.06 22:14:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:14:53 4 : sduino2/msg READ: MU;P0=297;P1=-999;P2=439;P3=1443;P4=-5152;P5=-117;P6=112;P7=-31096;D=010121212131213131313131312131213131312121340505650721212121212121213121313121312131312121313121312;CP=2;R=16;
2018.08.06 22:14:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:14:53 4 : sduino2/msg READ: MU;P0=-975;P1=1459;P2=-170;P3=560;P4=422;P5=108;P6=-5100;P7=160;D=010101012301040104010101010101010101010101010101010101010101010105672;CP=1;R=19;
2018.08.06 22:14:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:14:53 4 : sduino2/msg READ: MU;P0=-977;P1=482;P2=1473;P3=-92;P4=204;P5=-200;P6=360;P7=-2544;D=010234567101010201020202020202010201020202010102020102;CP=1;R=210;
2018.08.06 22:14:53 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:15:41 4 : sduino2/msg READ: MU;P0=-977;P1=1469;P6=483;D=010101010101010101060606060106010101010101060106010106060101060106;CP=1;R=211;
2018.08.06 22:15:41 4 : sduino2: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2018.08.06 22:15:49 4 : sduino2/keepalive ok, retry = 0
2018.08.06 22:16:29 4 : sduino2/msg READ: MS;P0=452;P1=-15280;P2=1423;P3=-1000;P5=-6032;P6=848;P7=-31044;D=050323232323232323232323232323232323232323232323232303030303230323230163032323230303232703030303030303032;CP=0;SP=5;R=15;
2018.08.06 22:16:29 4 : sduino2/msg READ: MS;P1=-983;P2=1467;P3=472;P4=-10548;D=243131313121312121212121213121312131212121310;CP=2;SP=4;R=26;
2018.08.06 22:16:49 4 : sduino2/keepalive ok, retry = 0


Grüße Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 August 2018, 23:50:43
ZitatHier mal 10min. Ich hoffe es reicht.

In den 10min ist keine brauchbare Nachricht dabei, fast alle Nachrichten sind zu kurz.
Ist evtl eine Störquelle in der Nähe des 868MHz Signalduino?

Interessant wäre zum Vergleich ein 10-20Min log mit der firmware die Du vorher drauf hattest.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 08 August 2018, 12:34:52
Ich fahre demnächst in Urlaub. Diese Thematik schaue ich mir nach meiner Rückkehr an. Das mit den Störquellen kann sein. Was könnte so was sein? Der Raspi, andere WLAN Geräte?

Spielt auch die Lage der Antenne eine Rolle? Also ob sie horizontal liegt oder vertikal steht.

Grüße Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 11 August 2018, 12:04:19
Hi,

ich habe eine Frage an die Experten:
Ich habe einen Sduino und einen Sduino mit cc1101.
Seit ich die RC7 auf beide gespielt hab geht der cc1101 nach einer gewissen Zeit (ca. 24h) auf closed.
Das ganze ist reproduzierbar.
Der andere ohne cc1101 hat das Verhalten nicht.
Vor RC7 hatte ich das Problem nicht, beide liefen immer durch

Ein Ausstöpseln und anschließen mit folgendem reset verbindet ihn wieder.

Ich habe Nanos mit dem reboot Problem.
Würde eine Verbinden der PINS 25 und 26 an den nanos helfen so dass er sich selbst wieder resettet?
Siehe: https://forum.fhem.de/index.php/topic,47010.0.html

Hier ein log wenn er sich closed:

2018.08.11 11:38:12 3: sduino IT: IT_Bewegungsmelder1 2018-08-11 11:38:12->on
2018.08.11 11:38:16 3: sduino_cc1101/KeepAlive not ok, retry = 2 -> get ping
2018.08.11 11:39:16 3: sduino_cc1101/KeepAlive not ok, retry = 3 -> get ping
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino: Unknown code i1FFDFF00, help me!
sending code[4294562]
sending code[4294562]
2018.08.11 11:40:17 3: sduino IT: IT_1527x4187a on->on
2018.08.11 11:40:17 3: sduino_cc1101/keepalive not ok, retry count reached. Reset
2018.08.11 11:40:17 3: sduino_cc1101 reset
2018.08.11 11:40:17 3: Opening sduino_cc1101 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0
2018.08.11 11:40:17 3: Setting sduino_cc1101 serial parameters to 57600,8,N,1
2018.08.11 11:40:17 1: sduino_cc1101/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 1: sduino_cc1101/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 3: sduino_cc1101 device opened
2018.08.11 11:40:19 3: sduino: Unknown code u26#BE785D, help me!
2018.08.11 11:40:19 3: sduino_cc1101/init: disable receiver (XQ)
2018.08.11 11:40:19 3: sduino_cc1101/init: get version, retry = 0
2018.08.11 11:40:29 3: sduino_cc1101/init: get version, retry = 1
2018.08.11 11:40:39 3: sduino_cc1101/init: get version, retry = 2
2018.08.11 11:40:49 3: sduino_cc1101/init: get version, retry = 3
2018.08.11 11:40:49 2: sduino_cc1101/init retry count reached. Reset
2018.08.11 11:40:49 3: sduino_cc1101 reset
2018.08.11 11:40:49 3: Opening sduino_cc1101 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0
2018.08.11 11:40:49 3: Setting sduino_cc1101 serial parameters to 57600,8,N,1
2018.08.11 11:40:49 1: sduino_cc1101/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:49 1: sduino_cc1101/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:49 3: sduino_cc1101 device opened
2018.08.11 11:40:51 3: sduino_cc1101/init: disable receiver (XQ)
2018.08.11 11:40:51 3: sduino_cc1101/init: get version, retry = 0
2018.08.11 11:41:01 3: sduino_cc1101/init: get version, retry = 1
2018.08.11 11:41:11 3: sduino_cc1101/init: get version, retry = 2
2018.08.11 11:41:21 3: sduino_cc1101/init: get version, retry = 3
2018.08.11 11:41:21 2: sduino_cc1101/init retry count reached. Closed
2018.08.11 11:41:21 2: sduino_cc1101 closed


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 11 August 2018, 13:24:58
Hi,
Ja sollte meiner Meinung nach helfen.
Kommt man halt nur schwer dran ;-) wenn schon alles verlötet ist.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 11 August 2018, 16:36:42
Da hast du recht, deshalb wollte ich erstmal fragen  ;)

Vielen Dank, dann werde ich versuchen dran zu kommen  ;D

P.S.: Ok habs verlötet. Ging eigentlich ganz einfach. Habs gleich bei all meinen Clones gemacht.
Ich werde berichten ob es hilft.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 14 August 2018, 22:16:55
Zitat von: stefanru am 11 August 2018, 16:36:42
Da hast du recht, deshalb wollte ich erstmal fragen  ;)

Vielen Dank, dann werde ich versuchen dran zu kommen  ;D

Hi Stefan,

Du schreibst, das Problem kommt erst mit RC7. Mit welcher Firmware hattest Du das Problem denn vorher nicht?

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 14 August 2018, 22:53:30
Hi Sidey,

war eine selbst kompilierte 3.3.1 denke so vom März - April.
Leider kann ich dir Version nicht mehr genau benennen die drauf war.

Das Problem dass nach einem Reboot des Raspberry der Sduino erst nach trennen und neu verbinden ging hatte ich immer.
Aber einmal von Hand verbunden lief er durch.

Mit RC7 ging er von alleine alle 1-2 Tage in Closed.
Aber nach dem löten ist alles bestens und er geht auch direkt nach einem Reboot.

Ich werde mal die Logs beobachten ob der Fehler mit auftritt aber von einem automatischen reconnect überdeckt wird. Konnte aber so etwas bisher noch nicht erkennen.
Sieht also gut aus.
Kann nur empfehlen vorsichtig die 2 Pins zu verlöten.
Ich wollte es eh schon lange machen hab mich aber nie getraut. Es war am Ende nicht so schwer und ich hab keinen einzigen zerstört ;-)

Danke und Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 18 August 2018, 19:52:31
So will nochmal Rückmeldung geben.
Nach dem Zusammenlöten bleibt er nun eindeutig online.
Ab und zu sieht man im Log so etwas:

2018.08.18 13:28:26 3: sduino_cc1101/KeepAlive not ok, retry = 2 -> get ping
2018.08.18 13:29:26 3: sduino_cc1101/KeepAlive not ok, retry = 3 -> get ping

das ist aber alles. Er funktioniert einwandfrei.

Was mir aber aufgefallen ist, nach einiger Zeit liefert ein get ccconf komische Werte.
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

Sowohl Frequenz wie auch Baudzahl sind total schräg. Er sendet aber nach wie vor einwandfrei.
Ist das ein Problem oder nur ein Fehler in der Rückgabe?

Der Sduino ist an einem Raspberry am USB Port angeschlossen.

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 18 August 2018, 23:32:19
Zitat von: stefanru am 18 August 2018, 19:52:31
Was mir aber aufgefallen ist, nach einiger Zeit liefert ein get ccconf komische Werte.
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

Sowohl Frequenz wie auch Baudzahl sind total schräg. Er sendet aber nach wie vor einwandfrei.
Ist das ein Problem oder nur ein Fehler in der Rückgabe?



Das ist seltsam. Er funktioniert trotzdem einwandfrei? Kannst Du die Register einmal manuell auslesen?


Ich habe nun die RC7 seit 11 Tagen an meinem Testsystem am laufen. Bei mir stimmt die ccconf Ausgabe.
V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 19 August 2018, 00:39:57
Hm,

wirklich komisch.
Meinst du ein get raw C99?

Habe etwas beobachtet.

Also zuerst:
ccconf: freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 C4 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 18 1F 41 00 59 7F 3F 88 31 0B


Dann ändert sich die Baudrate so    
freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: 03 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B


Danch auch die Frequenz
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)
Bei mehrmaligem get cconf bekomme ich aber einmal 433 und dann wieder 95
Register sind dann so:

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B

oder so:

ccregAll:

ccreg 00: 03 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B


Kannst du damit etwas anfangen?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: KölnSolar am 19 August 2018, 16:44:50
Zitatwirklich komisch

find ich nicht  ;D ;)
IT stellt ja seine "eigene" Frequenz ein und wieder zurück auf die vorher eingestellte.

Woher die 95,92 dann kommen bleibt aber komisch  :-\

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 19 August 2018, 17:42:57
Ok Frequenz könnte verstellt werden.
Sende aber kein IT, nur Somfy.

Und warum ändert sich die Baudrate? von 5603.79Baud auf 3173.83Baud.
Komischerweise scheint das alles der Funktion nicht zu schaden?

Gruß,
Stefan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: KölnSolar am 19 August 2018, 18:30:49
Hmm,
kein IT ?
2018.08.11 11:38:12 3: sduino IT: IT_Bewegungsmelder1 2018-08-11 11:38:12->on
2018.08.11 11:38:16 3: sduino_cc1101/KeepAlive not ok, retry = 2 -> get ping
2018.08.11 11:39:16 3: sduino_cc1101/KeepAlive not ok, retry = 3 -> get ping
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino: Unknown code i1FFDFF00, help me!
sending code[4294562]
sending code[4294562]
2018.08.11 11:40:17 3: sduino IT: IT_1527x4187a on->on
2018.08.11 11:40:17 3: sduino_cc1101/keepalive not ok, retry count reached. Reset
2018.08.11 11:40:17 3: sduino_cc1101 reset
2018.08.11 11:40:17 3: Opening sduino_cc1101 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0
2018.08.11 11:40:17 3: Setting sduino_cc1101 serial parameters to 57600,8,N,1
2018.08.11 11:40:17 1: sduino_cc1101/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 1: sduino_cc1101/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 3: sduino_cc1101 device opened

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: stefanru am 19 August 2018, 19:20:46
Ja aber er sendet das nicht, das ist ein Empfang. Dafür wechselt er doch nicht die Frequenz, oder?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 September 2018, 18:56:39
Hallo,

lässt sich ganz grob abschätzen wieviel freeram übrig bleiben muß, damit der sduino noch stabil und sicher funktioniert?

Für den cmdstring sollten ca 400 byte reichen. Wieviel freeram ist für das was sonst noch alles dynamisch reserviert wird ganz grob nötig?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 23 September 2018, 07:53:35
Zitat von: stefanru am 19 August 2018, 17:42:57
Ok Frequenz könnte verstellt werden.
Sende aber kein IT, nur Somfy.
Ich hatte mal ein ähnliches Problem: https://forum.fhem.de/index.php/topic,82379.msg805840.html#msg805840
(https://forum.fhem.de/index.php/topic,82379.msg805840.html#msg805840)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jogimaster am 23 September 2018, 16:01:10
Hallo,

ich habe den Threat gefunden und habe mir die Wemos Shield Platine von locutus fertigen lassen.
Wie habt ihr die Durchkontaktierung für D4 und D6 vorgenommen?
Die Pins sind sehr sehr dünn und nicht freigelegt im Layout? Aufbohren würde meiner Meinung nach die Platine zerstören. Alle anderen Teile lassen sich ja ohne Probleme bestücken, auch die SMD Bauteile.

Gruß
Jogimaster
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 23 September 2018, 18:30:18
Zitat von: jogimaster am 23 September 2018, 16:01:10
Hallo,

ich habe den Threat gefunden und habe mir die Wemos Shield Platine von locutus fertigen lassen.
Wie habt ihr die Durchkontaktierung für D4 und D6 vorgenommen?
Die Pins sind sehr sehr dünn und nicht freigelegt im Layout? Aufbohren würde meiner Meinung nach die Platine zerstören. Alle anderen Teile lassen sich ja ohne Probleme bestücken, auch die SMD Bauteile.

Gruß
Jogimaster

Warum willst du die Pins "durch kontaktieren"? Die sind doch normal als Pins am Wemos verfügbar.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jogimaster am 26 September 2018, 19:58:47
Sorry, etwas doof formuliert.

im eagle_pcb.jpg sind 2 Pins vorgesehen, die 2 Pins vom CC1101 Modul mit der Unterseite und dem Wemos D1 verbinden sollen. Diese sind nicht durchkontaktiert für eine doppelseitige LP.
D6 zu SO zum Beispiel. Nur Wemos, CC1101, SMA Buchse und SMD LED und R auflöten sollten nicht reichen!? Oder irre ich mich?

Denke ich zu kompliziert?

Gruß
Jogimaster
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 26 September 2018, 20:10:58
Zitat von: jogimaster am 26 September 2018, 19:58:47
Sorry, etwas doof formuliert.

im eagle_pcb.jpg sind 2 Pins vorgesehen, die 2 Pins vom CC1101 Modul mit der Unterseite und dem Wemos D1 verbinden sollen. Diese sind nicht durchkontaktiert für eine doppelseitige LP.
D6 zu SO zum Beispiel. Nur Wemos, CC1101, SMA Buchse und SMD LED und R auflöten sollten nicht reichen!? Oder irre ich mich?

Denke ich zu kompliziert?

Gruß
Jogimaster

Sicher, dass diese nicht durchkontaktiert sind? Von welcher Platine sprechen wir eigentlich? Was sagt denn Locotus zu seinen Platinen, hast du ihn mal gefragt?

Wenn du von folgender Platine redest, wird D4 doch überhaupt nicht verwendet: https://forum.fhem.de/index.php/topic,58396.msg646685.html#msg646685
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jogimaster am 27 September 2018, 12:48:16
Ja, es handelt sich um die Platine von locutus. Er nimmt aber keine PM's an, bittet hier im Forum zu fragen.
Es haben ja auch viele die Platine von ihm bekommen, daher hier die Nachfrage. Zur Verdeutlichung habe ich mal ein Foto gemacht.
Es geht um die rot markierten Stellen. Da muss doch eine Verbindung zwischen den beiden Seiten hergestellt werden!? Sonst fehlen doch 2 Verbindungen zwischen CC1101 und Wemos D1.

Jogimaster
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 27 September 2018, 13:13:39
Hallo Jogimaster
Ich habe zwei SignalESP im Einsatz, mit der Platine von Locutus! Die laufen einwandfrei. Zudem sind die doch verbunden, wenn Du Dir den Schaltplan ansiehst! Das was du eingekringelt hast ist doch eine Verbindung von der einen zur anderen Seite der Platine!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: PeMue am 27 September 2018, 13:25:52
Zitat von: pc1246 am 27 September 2018, 13:13:39
Das was du eingekringelt hast ist doch eine Verbindung von der einen zur anderen Seite der Platine!
= Durchkontaktierung (https://de.wikipedia.org/wiki/Durchkontaktierung)

Gruß PeMue
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jogimaster am 27 September 2018, 19:26:15
@all

Vielen Dank! Ich habe mir heute ein neues Multimeter besorgt und alle Bahnen nochmal durchgemessen. Es stimmt, die rot von mir markierten Punkte sind durchkontaktiert. Die Verbindung steht. Das alte Multimeter konnte scheinbar keine Widerstände/Durchgang mehr zu messen.

Bestücke gerade die Platine.

Gruß
Jogimaster
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 09 Oktober 2018, 11:17:38
Bezugnehmend auf https://forum.fhem.de/index.php/topic,58396.msg824906.html#msg824906 (https://forum.fhem.de/index.php/topic,58396.msg824906.html#msg824906)
So, hatte noch mit einem Defekt zu kämpfen und auch nur wenig Zeit. Nun läuft der 868MHz Signalduino wieder. Leider ist das Ergebnis trotz Umzugs und besserer Antenne ne absolute Katastrophe. Es werden in 24h vielleicht noch 1-2 Pakete des Außenteils der Wetterstation erfolgreich empfangen. Die Wetterstation selber funktioniert weiterhin einwandfrei. Das mit dem Störsender glaube daher nicht wirklich.
Hier mal ein Auszug aus dem Log mit verbose 4.
2018.10.09 06:21:24 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:21:53 4: sduino2/msg READ: MU;P0=-1962;P1=-3394;P2=-4952;P4=-760;P5=-385;P6=1908;D=626060606164656164656564656564656465656465646565646565646564606;CP=6;R=24;
2018.10.09 06:21:53 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:21:53 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:21:53 4: sduino2/msg READ: MU;P0=-3318;P1=1723;P2=-1985;P3=-366;P4=-4716;P5=-704;P6=-6452;P7=2304;D=01213121213101313141212121015131015131315131313131513131313151315131315131513121615127313151;CP=1;R=3;
2018.10.09 06:21:53 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:21:53 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:22:27 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:22:42 4: sduino2/msg READ: MU;P0=-372;P1=1733;P2=-3434;P3=-667;P4=-2271;P6=-6752;P7=-5076;D=01213101013101310101310131010131013101013101310141610141013131714121313131;CP=1;R=24;
2018.10.09 06:22:42 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:22:42 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:23:30 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:23:30 4: sduino2/msg READ: MU;P0=-2167;P1=1889;P2=-772;P3=-3288;P4=-384;P5=-5341;P6=4660;D=012131412151010101314631214141214141214141414121414121414141412141410151210141465101314641;CP=1;R=24;
2018.10.09 06:23:30 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:23:30 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:23:30 4: sduino2/msg READ: MU;P0=-2190;P1=1702;P3=-384;P4=-3539;P5=-4680;P6=-688;P7=-6544;D=010131010131413131510101014131614131313131313161316131613131313161313161316161017;CP=1;R=3;
2018.10.09 06:23:30 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:23:30 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:24:17 4: sduino2/msg READ: MU;P0=1884;P1=-377;P3=-734;P4=-2065;P5=-6876;P7=-4972;D=10303030303030303030303030303030405010403010307040;CP=0;R=23;
2018.10.09 06:24:17 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:24:17 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:24:33 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:25:06 4: sduino2/msg READ: MU;P0=1930;P1=-1956;P4=-761;P5=-3425;P6=-5312;P7=-384;D=010104010104050404060101010507070507070704070404040404040707070407040707040707010604010704070601050704070;CP=0;R=25;
2018.10.09 06:25:06 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:25:06 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:25:36 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:26:39 4: sduino2/KeepAlive not ok, retry = 1 -> get ping
2018.10.09 06:26:40 4: sduino2/msg READ: OK
2018.10.09 06:26:40 4: sduino2/HandleWriteQueue: nothing to send, stopping timer
2018.10.09 06:26:41 4: sduino2/msg READ: MU;P0=-10220;P1=1823;P2=-2025;P3=-366;P4=-3509;P5=-756;P6=-4880;D=012131212131415131612121214131514151313151313131313151315131513131;CP=1;R=24;
2018.10.09 06:26:41 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:26:41 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:27:29 4: sduino2/msg READ: MU;P0=-3657;P1=1977;P2=-759;P3=-5904;P4=-2053;P5=-368;P7=4696;D=012121314141410151510151515121512151215151575151215151215151515141315141515121;CP=1;R=24;
2018.10.09 06:27:29 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:27:29 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:27:43 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:28:18 4: sduino2/msg READ: MU;P0=-6864;P1=-687;P2=1698;P3=-2126;P4=7000;P5=-3354;P6=-356;D=123234526262526262621212121212621212126212121212121212121232026232121212;CP=2;R=25;
2018.10.09 06:28:18 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:28:18 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:28:18 4: sduino2/msg READ: MU;P0=1895;P2=-2102;P3=-746;P4=-3546;P6=-390;P7=-5748;D=020302020304030607020203060406060406060603060306030606030603030606030306030606020703020306030;CP=0;R=24;
2018.10.09 06:28:18 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:28:18 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:28:46 4: sduino2/keepalive ok, retry = 0
2018.10.09 06:29:06 4: sduino2/msg READ: MU;P0=-3772;P1=-385;P2=1703;P3=-691;P4=-2037;P5=-5770;P6=-984;D=1212321212321232121232123212425232423232625232420232;CP=2;R=24;
2018.10.09 06:29:06 4: sduino2: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2018.10.09 06:29:06 4: sduino2: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate


Vielleicht kann jemand was damit anfangen.

Hier noch das aktuelle List sduino2

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0@57600
   DMSG       P9#FF4A63FAB4000002F20D94
   DevState   initialized
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0@57600
   FD         19
   LASTDMSG   P9#FF4A63FAB4000002F20D94
   LASTInputDev sduino2
   MSGCNT     3844
   NAME       sduino2
   NR         60
   PARTIAL   
   RAWMSG     MU;P0=-5492;P1=471;P2=-986;P3=1457;P4=-31036;D=01212121212121212321232321232123232121232323212121212121212321232123212123212323232323232323232323232323232323232323232323232123212121212323212323232323212123212123232123212341212121212121212321232321232123232121232323212121212121212321232123212123212323;CP=1;R=28;O;
   RSSI       -60
   STATE      opened
   TIME       1539032034
   TYPE       SIGNALduino
   sduino2_DMSG P9#FF6A7544083230A0108B38
   sduino2_MSGCNT 41
   sduino2_RAWMSG MU;P0=-10456;P1=483;P2=-985;P3=1465;P4=-31036;D=01212121212121212321212321232123232121212321232123212323232123232323232321232323232321212323212323232121232323232123212323232323232323212323232321232323212321212323212121232341212121212121212321212321232123232121212321232123212323232123232323232321232323;CP=1;R=27;O;
   sduino2_RSSI -60.5
   sduino2_TIME 2018-10-08 22:04:18
   sendworking 0
   unknownmessages
   version    V 3.3.1-RC7 SIGNALduino cc1101  - compiled at May 11 2018 23:00:28
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-10-08 23:04:23   ccconf          freq:868.300MHz bWidth:270KHz rAmpl:42dB sens:4dB  (DataRate:350.24Baud)
     2017-10-10 19:06:07   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2017-10-08 11:38:43   config          MS=1;MU=1;MC=1
     2018-10-09 11:03:17   ping            OK
     2018-10-07 01:03:25   state           opened
     2018-10-07 01:03:25   version         V 3.3.1-RC7 SIGNALduino cc1101  - compiled at May 11 2018 23:00:28
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     75
     8
     9
Attributes:
   DbLogExclude .*
   WS09_CRCAUS 2
   event-on-change-reading state
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   icon       cul_868
   room       Funk & Kommunikation
   verbose    0


Viele Grüße

Martin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: gloob am 09 Oktober 2018, 11:27:27
Zitat von: maddinthebrain am 09 Oktober 2018, 11:17:38
Bezugnehmend auf https://forum.fhem.de/index.php/topic,58396.msg824906.html#msg824906 (https://forum.fhem.de/index.php/topic,58396.msg824906.html#msg824906)
So, hatte noch mit einem Defekt zu kämpfen und auch nur wenig Zeit. Nun läuft der 868MHz Signalduino wieder. Leider ist das Ergebnis trotz Umzugs und besserer Antenne ne absolute Katastrophe. Es werden in 24h vielleicht noch 1-2 Pakete des Außenteils der Wetterstation erfolgreich empfangen. Die Wetterstation selber funktioniert weiterhin einwandfrei. Das mit dem Störsender glaube daher nicht wirklich.

Was für ein Funkmodul nutzt du denn? Ich hatte in letzter Zeit viele Probleme mit fehlerhaften CC1101 Modulen. Vielleicht kannst du mal ein Bild davon posten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 09 Oktober 2018, 14:03:10
Was ist es für eine Wetterstation?
Mal beim der WE verbose=5 setzen.
Wenn es eine wh1080 ist bitte ins Forum für die wh1080.
https://forum.fhem.de/index.php/topic,39451.msg720247.html#msg720247
Pejonp
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: maddinthebrain am 09 Oktober 2018, 20:42:56
Zitat von: pejonp am 09 Oktober 2018, 14:03:10
Was ist es für eine Wetterstation?
Mal beim der WE verbose=5 setzen.
Wenn es eine wh1080 ist bitte ins Forum für die wh1080.
https://forum.fhem.de/index.php/topic,39451.msg720247.html#msg720247
Pejonp

Fortsetzung unter https://forum.fhem.de/index.php/topic,39451.msg844155.html#msg844155 (https://forum.fhem.de/index.php/topic,39451.msg844155.html#msg844155)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Markus. am 14 Oktober 2018, 07:15:56
Hallo Zusammen,

wo finde ich denn die letzte Version der SignalESP-Firmware für Wemos D1 Mini und CC1101(433) ?
Verwende eigentlich nur IT.

Gruß

Markus
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 23 Oktober 2018, 16:34:54
Kann mir jemand helfen, ich habe massenweise Fehlermeldungen der Form
2018.10.23 08:53:07 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2018.10.23 08:55:37 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2018.10.23 08:55:38 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2018.10.23 09:11:27 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2018.10.23 09:20:38 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2018.10.23 09:25:37 2: sduino: CUL_TCM97001 Unknown device CUL_TCM97001_172, please define it

obwohl ich doch eigentlich diese Meldungen unterdrückt habe (verbose 0!!):
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
   DMSG       W44x#0F2DA20AF0D25DF5D4
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0@57600
   FD         11
   LASTDMSG   W44x#0F2DA20AF0D25DF5D4
   MSGCNT     4285
   NAME       sduino
   NR         21
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     MU;P0=200;P1=-3893;P2=3868;P3=-5864;P4=1956;P5=-1951;D=0123454545454141414145454145414145414145414545454145454545454145414541414141454545454141454145454145454145414141454141414141454145414141454145414540;CP=4;R=21;
   RSSI       -63.5
   STATE      opened
   TIME       1540305197
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun  1 2018 23:56:22
   versionmodul v3.3.3-dev_20.04.
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-06-26 16:33:12   ITParms         Unsupported command
     2018-08-25 13:08:06   ccconf          freq:433.920MHz bWidth:650KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-07-31 11:37:24   ccpatable       C3E = 00 C0 00 00 00 00 00 00  => 10_dBm
     2017-06-26 16:53:00   ccreg           C3E = 00 84 00 00 00 00 00 00
     2018-05-27 15:09:18   config          MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=80
     2018-05-27 15:09:14   freeram         450
     2018-05-08 21:22:16   logEntry        freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:3173.83Baud)
     2018-10-06 08:42:00   ping            OK
     2018-05-06 22:06:13   raw             C0Dn03=10B071
     2018-10-21 16:12:05   state           opened
     2018-05-27 15:09:00   uptime          0 00:07:35
     2018-10-21 16:12:05   version         V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun  1 2018 23:56:22
   XMIT_TIME:
     1540300413
     1540300623
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     2
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     22
     23
     25
     32
     33
     35
     38
     51
     55
     65
     68
     72.1
   muIdList:
     5
     8
     9
     13.1
     16
     17.1
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     39
     44
     44.1
     45
     46
     48
     49
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
Attributes:
   blacklist_IDs 41,40,37
   devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      intern
   hardware   nanoCC1101
   verbose    0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 23 Oktober 2018, 16:41:43
Hallo andies,

einfach mal die FHEM-Suche ind er Einstiegsseite bemühen "CUL_TCM97001" oder "CUL_TCM97001 Unknown device Unknown, please define it".

Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 23 Oktober 2018, 16:44:20
ja, hatte ich - da wurde auf den CUL verwiesen (ein Eintrag). Ich habe aber den SIGNALduino und, was mich verwirrt, er meldet trotz verbose 0.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 23 Oktober 2018, 23:29:17
Eine Ursache kann ein TCM97001 sensor sein der schlecht empfangen wird oder bei dem die Batterie fast leer ist.

Mit get sduino protocolIDs kannst Du sehen, daß die IDs 0, 38 und 68 das CUL_TCM97001 Modul verwenden.

Wenn Du keine Sensoren vom CUL_TCM97001 Modul hast, dann kannst Du diese IDs in die Blacklist eintragen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 24 Oktober 2018, 07:19:57
Danke, mache ich (Ich hatte  bisher gedacht, die ID 2 gehöre zu diesem Gerät).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 18 November 2018, 23:21:48
Guten Abend,

8) HINWEIS für die USER der aktuellen DEV-r33 Version. Nach einem Update auf diese Version werden die Protokolle 14, 15, 32, 41, 57, 79 absofort in deinem Modul ausgewertet.

Die Klingeln werden nicht mehr via DOIF ausgewertet. Beim Empfang eines Signales wird ein neues Device angelegt wo man auch die Klingel selbst ansteuern könnte via SET Befehl.

Wenn FRAGEN oder Fehler auftauchen, könnt ihr hier oder in Github einen ISSUES (https://github.com/RFD-FHEM/RFFHEM/issues) erstellen.

Danke
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 15 März 2019, 14:26:48
Zitat von: Ralf9 am 23 Oktober 2018, 23:29:17
Wenn Du keine Sensoren vom CUL_TCM97001 Modul hast, dann kannst Du diese IDs in die Blacklist eintragen.
Hi Ralf, ich brauche nochmal Deine Hilfe. Ich habe mir nun einen Sensor des TCM97001-Moduls besorgt und habe daher die Blacklist gekürzt. Ich empfange schön den Sensor, aber auch wieder massenhaft diese Fehlermeldungen.

Es gab einen Patchvorschlag,  wonach im Modul TCM97001 selber die Fehlermeldung auf das global-device gezogen wird und dann mit global verbose 0 diese Meldung unterdrückt wird.  Das funktioniert aber (auch nach einem Neustart) bei mir nicht. Der Signalduino selbst hat schon verbose 0 und im Quelltext des Signalduino-Moduls steht auch kein Code, der die Fehlermeldung auslösen könnte.

Wie kann ich das ausstellen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 15 März 2019, 15:54:42
Hallo andies,
wie sieht genau deine Meldung(en) aus?
Wenn du mal bitte ein Logauszug mit verbose 4 aufzeichnen würdest, so kann man erkenntliche Informationen entnehmen.

Das TCM Modul kann sehr anfällig sein auf Fehlinterpretationen oder anderen ,,Müll".

Liebe Grüße


Gesendet von mobil -> Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 15 März 2019, 17:35:40
Danke für die Hilfe!
Bisher habe ich folgende Einträge
2019.03.15 15:33:21 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.15 16:15:54 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.15 16:52:17 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.15 16:55:59 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.15 17:18:48 2: sduino: CUL_TCM97001 Unknown device Unknown, please define it

Das device selbst sieht so aus
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
   DMSG       s336CAC000000
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0@57600
   FD         10
   FUUID      5c782b53-f33f-1115-5537-1acd607a016042cf
   IDsNoDispatch 2,72.1,82
   LASTDMSG   s336CAC000000
   MSGCNT     549
   NAME       sduino
   NR         21
   NR_CMD_LAST_H 4
   PARTIAL   
   RAWMSG     MS;P0=-2015;P1=478;P2=-4050;P3=-9057;D=013101012121010121210121210121210101210121012121010101010101010101010101010;CP=1;SP=3;R=254;O;m0;
   RSSI       -75
   STATE      opened
   TIME       1552667690
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages
   version    V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun  1 2018 23:56:22
   versionmodul v3.3.3
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2017-06-26 16:33:12   ITParms         Unsupported command
     2018-10-31 09:41:38   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2019-02-07 23:02:01   ccpatable       C3E = 00 C0 00 00 00 00 00 00  => 10_dBm
     2017-06-26 16:53:00   ccreg           C3E = 00 84 00 00 00 00 00 00
     2018-11-07 07:33:31   config          MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=0;MdebFifoLimit=80
     2018-05-27 15:09:14   freeram         450
     2018-05-08 21:22:16   logEntry        freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:3173.83Baud)
     2019-03-04 19:43:58   ping            OK
     2018-11-12 10:26:21   raw             fifolimit=115
     2019-03-15 13:47:21   state           opened
     2018-05-27 15:09:00   uptime          0 00:07:35
     2019-03-15 13:47:21   version         V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun  1 2018 23:56:22
   XMIT_TIME:
     1552662591
     1552662592
     1552662592
     1552662801
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     22
     23
     25
     33
     35
     51
     55
     65
   muIdList:
     5
     8
     9
     13.1
     16
     17.1
     19
     20
     21
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     39
     44
     44.1
     45
     46
     48
     49
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     74
     75
     79
     80
     81
     83
     84
     85
     86
Attributes:
   blacklist_IDs 41,40,37,38,68
   devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
   development u86
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      intern
   hardware   nanoCC1101
   verbose    0

Ich bin mir sicher, dass ein Nachbar da auch ein Gerät hat. Genügt das?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 15 März 2019, 19:07:52
ZitatIch habe mir nun einen Sensor des TCM97001-Moduls
Interessant wäre die Bezeichnung des Sensors und die sduino_RAWMSG vom Sensor

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 15 März 2019, 19:49:50
Zitat von: Ralf9 am 15 März 2019, 19:07:52
Interessant wäre die Bezeichnung des Sensors und die sduino_RAWMSG vom Sensor
Das ist ein W174 Regenmesser von Ventus. Hier ein list des Gerätes, da ist eine RawMsg (meines Wissens) drin:
Internals:
   CODE       CUL_TCM97001_51
   DEF        CUL_TCM97001_51
   FUUID      5c8a6ad7-f33f-1115-a1ca-98db8a737f9a7434
   LASTInputDev sduino
   MSGCNT     586
   NAME       Regenmesser
   NR         236
   STATE      1.75 mm
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1552675719.13577
   sduino_DMSG s336C9C002000
   sduino_MSGCNT 588
   sduino_RAWMSG MS;P3=478;P4=-4052;P5=-2022;P6=-9075;D=536353534343535343435343435343435353435353434343535353535353535353535353435;CP=3;SP=6;R=248;O;m0;
   sduino_RSSI -78
   sduino_TIME 2019-03-15 19:48:39
   READINGS:
     2019-03-14 15:53:48   battery         ok
     2019-03-15 19:48:39   israining       no
     2019-03-15 19:48:39   rain            14.25
     2019-03-14 23:55:00   rain_midnight   12.5
     2019-03-15 19:48:39   rain_today      1.75
     2019-03-15 19:48:39   state           R: 14.25
Attributes:
   comment    https://forum.fhem.de/index.php?topic=88553.0
   event-min-interval .*:300
   event-on-change-reading .*
   group      Wetter
   model      W174
   room       Wetter
   stateFormat rain_today mm
   userReadings rain_today {ReadingsVal($name, "rain", 0)-ReadingsVal($name, "rain_midnight",0)}
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 15 März 2019, 20:17:26
ZitatDas ist ein W174 Regenmesser

Bei dem aktuellen fhem Modul v3.3.4 (stable) oder dev-r34 ist es die ID 0.3, bei einer älteren Version ist es evtl eine andere ID.
Mit dieser Anpassung wird die ID im sensor im Internal "sduinoD_ID" angezeigt
https://forum.fhem.de/index.php/topic,96830.msg899905.html#msg899905

Du kannst in die Blacklist außer der 0.3 alle ID des CUL_TCM97001 Moduls eintragen.


Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 16 März 2019, 00:38:28
Zitat von: andies am 15 März 2019, 19:49:50
Das ist ein W174 Regenmesser von Ventus. Hier ein list des Gerätes, da ist eine RawMsg (meines Wissens) drin:
Internals:
   CODE       CUL_TCM97001_51
   DEF        CUL_TCM97001_51
   FUUID      5c8a6ad7-f33f-1115-a1ca-98db8a737f9a7434
   LASTInputDev sduino
   MSGCNT     586
   NAME       Regenmesser
   NR         236
   STATE      1.75 mm
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1552675719.13577
   sduino_DMSG s336C9C002000
   sduino_MSGCNT 588
   sduino_RAWMSG MS;P3=478;P4=-4052;P5=-2022;P6=-9075;D=536353534343535343435343435343435353435353434343535353535353535353535353435;CP=3;SP=6;R=248;O;m0;
   sduino_RSSI -78
   sduino_TIME 2019-03-15 19:48:39
   READINGS:
     2019-03-14 15:53:48   battery         ok
     2019-03-15 19:48:39   israining       no
     2019-03-15 19:48:39   rain            14.25
     2019-03-14 23:55:00   rain_midnight   12.5
     2019-03-15 19:48:39   rain_today      1.75
     2019-03-15 19:48:39   state           R: 14.25
Attributes:
   comment    https://forum.fhem.de/index.php?topic=88553.0
   event-min-interval .*:300
   event-on-change-reading .*
   group      Wetter
   model      W174
   room       Wetter
   stateFormat rain_today mm
   userReadings rain_today {ReadingsVal($name, "rain", 0)-ReadingsVal($name, "rain_midnight",0)}


Hallo, diesen Sensor habe ich auch.
Der Sensor feuert so viele Nachrichten raus, das der SIGNALduino gern mal etwas falsch empfängt.
Ich habe es schon lange veruscht aufzugreifen aber das ist von Empfänger zu Empfänger unterschiedlich.

Bei meinem radino erhalte ich gern mal ebensolche Fehlermeldungen und auf dem nano nicht.
Eine Mitschrift der fehlerhaften Nachrichten zeigte, es ist stets ein Bit was falsch interprätiert wurde und das TCM Modul dann etwas anderes damit anstellen wollte.
Eine Lösung dafür wird es wohl eher weniger geben.

MfG
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 16 März 2019, 09:31:47
Ich habe vielleicht einen Fehler im Modul CUL_TCM970001 gefunden, aber wie bekomme ich die Korrektur ins offizielle System?

https://forum.fhem.de/index.php/topic,98334.msg916853.html#msg916853 (https://forum.fhem.de/index.php/topic,98334.msg916853.html#msg916853)

Ich verlinke das hier nur, weil der eigene Thread untergegangen ist.

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 16 März 2019, 10:41:54
Zitat von: Ralf9 am 15 März 2019, 20:17:26
Bei dem aktuellen fhem Modul v3.3.4 (stable) oder dev-r34 ist es die ID 0.3, bei einer älteren Version ist es evtl eine andere ID.
Ich habe die Anpassung gerade vorgenommen, aber es erscheint als ID nur 0. Ich habe gerade ein update gemacht und shutdown restart, im Modul aber heißt es
version V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
versionmodul v3.3.3

Da stimmt was nicht bei mir?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 16 März 2019, 10:54:43
Noch ein Hinweis: https://forum.fhem.de/index.php/topic,88553.msg919696.html#msg919696
Könnte das das Problem sein?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 16 März 2019, 14:25:33
Zitat von: andies am 15 März 2019, 19:49:50
Das ist ein W174 Regenmesser von Ventus. Hier ein list des Gerätes, da ist eine RawMsg (meines Wissens) drin:

Bei mir läuft der W174 als ID 0.3.

2019.03.16 14:21:51 4: sduino_dummy/msg get raw: MS;P1=-2016;P2=477;P3=-9060;P4=-4041;D=23212121242121212424242421242421212121212124212421242421212121212124212124;CP=2;SP=3;R=73;O;m2;
2019.03.16 14:21:51 4: sduino_dummy: Matched MS Protocol id 0.3 -> weather (v4)
2019.03.16 14:21:51 4: sduino_dummy: Decoded matched MS Protocol id 0.3 dmsg s11EC0AC09000 length 40  RSSI = -37.5
2019.03.16 14:21:51 4: sduino_dummy: CUL_TCM97001 W174_17 detected rain gauge message ok
2019.03.16 14:21:51 4: sduino_dummy: CUL_TCM97001 W174_17 battery bit: 1
2019.03.16 14:21:51 4: sduino_dummy: CUL_TCM97001 W174_17 rain total: 212 l/qm
2019.03.16 14:21:51 4: sduino_dummy: Matched MS Protocol id 0.4 -> weather (v5)
2019.03.16 14:21:51 4: sduino_dummy: Decoded matched MS Protocol id 0.4 dmsg s11EC0AC09000 length 40  RSSI = -37.5


@andies,
sammel doch mal ein paar RAWMSG oder nimm nicht nur die ID0.3. Teste die anderen auch mal und wenn der Sensor ebenso nicht erscheint, dann wird was anderes ggf faul sein.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 16 März 2019, 14:27:50
Was das TCM Modul an geht

2019.03.16 14:08:32 2: radino_433Mhz: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.16 14:09:09 2: radino_433Mhz: CUL_TCM97001 Unknown device Unknown, please define it
2019.03.16 14:16:33 2: radino_433Mhz: CUL_TCM97001 Unknown device Unknown, please define it


hätte ich den Vorschlag, wir fertigen einen Patch an, um noch die DMSG in Klammern zu ergänzen. So kann man sehen welcher Sensor dies ggf umherspuckt.
Log3 "Unknown", 2, "$iodev: CUL_TCM97001 Unknown device Unknown, please define it ($msg)";
Wie denkt Ihr darüber?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 16 März 2019, 14:32:46
Zitat von: HomeAuto_User am 16 März 2019, 14:25:33
@andies,
sammel doch mal ein paar RAWMSG oder nimm nicht nur die ID0.3. Teste die anderen auch mal und wenn der Sensor ebenso nicht erscheint, dann wird was anderes ggf faul sein.
Nee, das ist ein Missverständnis. Der Sensor wird von mir empfangen, ich bin zufrieden und sehe auch die Werte. Ich hatte nur zuviel Logmeldungen, dass ein (weiteres) TCM-Gerät nicht empfangen wird und das minütlich. Das Log-Problem habe ich in den Griff bekommen, weil ich gesehen habe, dass wahrscheinlich in der TCP...pm ein Fehler ist (siehe den Link oben) - seit ich das repariert habe, sind keine Fehlermeldungen mehr im Log.

Ich wundere mich nur jetzt, wieso ich beim upgrade anscheinend keine neue Fassung des Moduls erhalten habe. Aber das ist zweitrangig, weil bei mir alles funktioniert!

Den Patch würde ich trotzdem unterstützen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 16 März 2019, 14:39:20
Wenn es nach deiner Änderung im Modul (dein Link) klappte, so reiche das doch als Patch ein um dauerhaft auch anderen damit zu helfen.

Ich werde morgen mal deine Änderung bei mir testen was passiert.


Gesendet von mobil -> Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 16 März 2019, 21:24:54
Zitat von: andies am 16 März 2019, 14:32:46
Ich wundere mich nur jetzt, wieso ich beim upgrade anscheinend keine neue Fassung des Moduls erhalten habe. Aber das ist zweitrangig, weil bei mir alles funktioniert!

Die Version hat sich geändert, demzufolge auch der Link für das Update:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Danach solltest du auch eine aktuelle Firmware flashen. Das geht jetzt komfortabel aus dem Internet:
get availableFirmware
set sduino flash 3.3.1-RC10
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 16 März 2019, 21:31:31
danke, aber da lief was schief:


avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "3.3.1-RC10"
avrdude: error opening 3.3.1-RC10: No such file or directory
avrdude: input file 3.3.1-RC10 auto detected as invalid format
avrdude: can't open input file 3.3.1-RC10: No such file or directory
avrdude: read from file '3.3.1-RC10' failed

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 16 März 2019, 22:05:55
Angepasst
https://wiki.fhem.de/wiki/SIGNALduino#Flashen_des_Arduino_mit_der_SIGNALduino_Firmware (https://wiki.fhem.de/wiki/SIGNALduino#Flashen_des_Arduino_mit_der_SIGNALduino_Firmware)

Es wäre nicht schlecht, wenn Ihr auch das Wiki anpasst. Das Problem beim Signalduino ist, dass die Entwicklung extrem unübersichtlich geworden ist. Vielleicht sollten wir Threads zu alten Versionen schließen und dann auch Leute auffordern, eine update zu machen. Sonst denkt man immer noch, 3.3.0 wäre aktuell...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 17 März 2019, 10:37:57
Zitatversion V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22
versionmodul v3.3.3
Bei meiner firmware ist die aktuelle Version V 3.3.2.1-rc8

Bei dem fhem Modul v3.3.4 (stable) im normalen fhem update (svn) sind noch ein paar kleine bugs.

Bei versionmodul wird noch die v3.3.3 angezeigt. Wenn Du version eingibst, kannst Du am Datum sehen ob Du die v3.3.4 hast.
# $Id: 00_SIGNALduino.pm 18693 2019-02-22 23:26:20Z Sidey $
#
# v3.3.4 (stable release 3.3)

SDUINO_VERSION            => "v3.3.3",


Da in der controls_fhem.txt die "signalduino_protocols.hash" nicht enthalten ist, wird die "signalduino_protocols.hash"  beim fhem update nicht geholt.
Als workaround wird die "signalduino_protocols.hash" vom svn nachgeladen, falls es im lib Verzeichnis kein "signalduino_protocols.hash" gibt.
%ProtocolListSIGNALduino = eval GetFileFromURL("https://svn.fhem.de/fhem/trunk/fhem/FHEM/lib/signalduino_protocols.hash",4,"",1,4);
D.H. wenn Du aus der dev-r33 noch eine ältere "signalduino_protocols.hash"  hast, wird diese nicht automatisch aktualisiert.

Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 17 März 2019, 11:01:48
Zitat von: Ralf9 am 17 März 2019, 10:37:57
Bei meiner firmware ist die aktuelle Version V 3.3.2.1-rc8
Uups, jetzt bin ich Dir anscheinend voraus, da fühle ich mich eigentlich gar nicht wohl

version V 3.3.1-RC10 SIGNALduino cc1101 - compiled at Dec 29 2018 01:43:10


Zitat von: Ralf9 am 17 März 2019, 10:37:57
Bei dem fhem Modul v3.3.4 (stable) im normalen fhem update (svn) sind noch ein paar kleine bugs.
Auch da habe ich schon
versionProtocols 1.01
versionmodul v3.4.0_dev_16.03

Ich hoffe mal, das ist kein Problem.

Zitat von: Ralf9 am 17 März 2019, 10:37:57
Als workaround wird die "signalduino_protocols.hash" vom svn nachgeladen, falls es im lib Verzeichnis kein "signalduino_protocols.hash" gibt.
%ProtocolListSIGNALduino = eval GetFileFromURL("https://svn.fhem.de/fhem/trunk/fhem/FHEM/lib/signalduino_protocols.hash",4,"",1,4);
D.H. wenn Du aus der dev-r33 noch eine ältere "signalduino_protocols.hash"  hast, wird diese nicht automatisch aktualisiert.
Das habe ich leider nicht ganz verstanden. Gebe ich das in die Kommandozeile oben ein?

Und letzte Frage: Ich habe vermutlich ein Problem mit einem neuen Gerät (W134), wo stelle ich da Code ein? (Momentan bin ich aber erstmal am prüfen, ob das Ding überhaupt etwas auf 433MHz sendet, das sieht nämlich komisch aus.)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 17 März 2019, 11:10:23
Wo wird die Signalduino_protocols.hash abgelegt?

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 17 März 2019, 11:27:32
ZitatWo wird die Signalduino_protocols.hash abgelegt?

sie liegt in
/FHEM/lib/signalduino_protocols.hash

Gruß Ralf

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 17 März 2019, 11:31:33
Habe die Datei da gar nicht liegen....
Nur die sd_protocols.pm

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 17 März 2019, 11:40:24
Wir vermischen jetzt immer mehr zwei verschiedene Entwicklerversionen, was sowohl die Firmware des SIGNALduino betrifft, als auch die SIGNALduino-Perl-Module:

https://github.com/RFD-FHEM

https://github.com/Ralf9

Diese beiden Zweige sind nicht 100%ig kompatibel. Das macht die Sache langsam aber sicher unnötig kompliziert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 17 März 2019, 11:44:05
Zitatversionmodul v3.4.0_dev_16.03
Dies ist die aktuelle Entwicklerversion, die ist aktueller als die v3.3.4 (stable).

ZitatDas habe ich leider nicht ganz verstanden. Gebe ich das in die Kommandozeile oben ein?

Dies gilt nur für die v3.3.4 (stable) aus dem normalen fhem update, da muss man falls man noch eine signalduino_protocols.hash aus einer alten dev-r33 hat, diese von Hand reinkopieren.

Dies gilt nicht für die Entwicklerversion dev-r34, da funktioniert das aktualisieren des protocolhash. Dort heißt die Datei  "SD_ProtocolData.pm"

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 17 März 2019, 12:12:59
Zitat von: elektron-bbs am 17 März 2019, 11:40:24
Das macht die Sache langsam aber sicher unnötig kompliziert.

Für mich als Anwender ist das fast wie der GAU. Aber woher soll ich das kapieren, zumal die Threads teilweise Hunderte Einträge haben.

Nochmal mein Vorschlag: Kann jemand, der sich auskennt, hier mal ein paar Einträge in Wikipedia vornehmen? So dass auch die Unbedarften kapieren, was sie tun und was sie besser lassen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 17 März 2019, 12:16:58
So, am besten hier: https://wiki.fhem.de/wiki/SIGNALduino#Zwei_Entwicklungsversionen (https://wiki.fhem.de/wiki/SIGNALduino#Zwei_Entwicklungsversionen)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 17 März 2019, 13:59:22
Zitat von: andies am 17 März 2019, 11:01:48
Und letzte Frage: Ich habe vermutlich ein Problem mit einem neuen Gerät (W134), wo stelle ich da Code ein? (Momentan bin ich aber erstmal am prüfen, ob das Ding überhaupt etwas auf 433MHz sendet, das sieht nämlich komisch aus.)
Ich habe mal eine debug-Ausgabe gemacht. Eigentlich habe ich zweimal die Batterien eingeklemmt, es erscheint aber nur eine Uhrzeit, nämlich 19 bzw 20 Sekunden nach 13:56.

Hat sich erledigt. Der Hersteller hat mir allen Ernstes geschrieben, er wisse nicht, auf welcher Frequenz das Gerät sende; "aber 433 ist es nicht". Herrlich.
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 21 März 2019, 06:56:06
Guten Tag,

@andies, um was für ein Device handelt es sich direkt? Welcher Hersteller bzw welche Stationsnummer sind dazugehörig?

W134 ist zu wenig als Angabe.

Die Frequenz bekommst du ggf mit einem SDR heraus wenn die Modulation Dir keinen Strich durch die Rechnung macht.
(TI+ Bsp )

Kannst du mal Bilder vom Sensor zeigen?

Mfg


Gesendet von mobil -> Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 21 März 2019, 09:25:52
Zitat von: HomeAuto_User am 21 März 2019, 06:56:06
@andies, um was für ein Device handelt es sich direkt? Welcher Hersteller bzw welche Stationsnummer sind dazugehörig?
Es ist der Ersatzwindmesser Ventus W134 (https://www.reichelt.de/ersatz-windmesser-fuer-funkwetterstation-ventus-w134-p164896.html (https://www.reichelt.de/ersatz-windmesser-fuer-funkwetterstation-ventus-w134-p164896.html)) der Funkwetterstation W145. Letztere konnte ich hier gar nicht kaufen. Ich habe mit bWidth herumgespielt und einfach keine Signale bekommen. Dann habe ich mich an den Hersteller gewandt und gefragt, auf welcher Frequenz der sendet; könnte ja theoretisch sein, dass die von 433.92 auf 434.00 oder was auch immer gewechselt haben (siehe Somfy). Die Antwort war: "Sorry but we don't have this exact information, but I know it's not same frequency" [as 433.92MHz, siehe https://forum.fhem.de/index.php/topic,98631.msg920553.html#msg920553 (https://forum.fhem.de/index.php/topic,98631.msg920553.html#msg920553))

(Eigene) Bilder habe ich leider keine.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 21 März 2019, 10:55:45
Hallo,
laut Doku 433 MHz:
https://www.bedienungsanleitu.ng/ventus/w145/anleitung?p=45 (https://www.bedienungsanleitu.ng/ventus/w145/anleitung?p=45)

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 21 März 2019, 11:01:09
Ja, ich weiß. Aber die Antwort oben ist ein Originalzitat einer Mail des Herstellersupports. Da kann man nichts machen. Reichelt hat das Ding daraufhin anstandslos zurückgenommen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: thunder1902 am 20 Mai 2019, 09:34:49
Hallo!

Ich habe jetzt schon 2 Stück CC1101-433 MHZ Module ausprobiert. Bei beiden Modulen bekomme ich keinen einzigen Empangs-Datensatz aus dem Signalduino.
Habe einmal dieses Modul https://de.aliexpress.com/item/1pcs-433MHz-CC2202-Wireless-rf-Module-E07-M1101D-TH-10mW-500m-SPI-433M-SMD-with-Spring/32810247068.html (https://de.aliexpress.com/item/1pcs-433MHz-CC2202-Wireless-rf-Module-E07-M1101D-TH-10mW-500m-SPI-433M-SMD-with-Spring/32810247068.html)

und einmal dieses hier: https://www.ebay.de/itm/CC1101-433M-2500-NRF-Wireless-Transceiver-Module-350m-Distance-Transmission-/262902521530 (https://www.ebay.de/itm/CC1101-433M-2500-NRF-Wireless-Transceiver-Module-350m-Distance-Transmission-/262902521530).

Ich verwende einen Arduino Mini Pro mit 8MHZ, 3,3V.

Im FHEM wird er korrekt initialisiert - aber er empfängt keine Daten. Ich kann mit meinem 433 Sender rumdrücken wie ich will - er empfängt einfach nichts.
Im Log steht zwar - Receiver enabled usw - aber er emfängt nichts.

Gibt es irgendwie eine Möglichkeit wie man herausfinden kann, ob das CC1101 Modul kaputt ist?

Wenn ich den Signalduino an den Seriellen Monitor hänge - müsste da auch schon was kommen, wenn er etwas empfängt - oder muss der Empfänger durch irgendein Kommando erst aktiviert werden?

Danke schonmal für eure Hilfe!!!!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 Mai 2019, 09:38:17
Na nimm doch einen Sender (billig) und schicke diese IT Intertechno-Signale über den Äther, https://forum.arduino.cc/index.php?topic=93924.0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: thunder1902 am 20 Mai 2019, 09:54:11
@andies:
Einen Sender (von meinen IT- Steckdosen) habe ich doch bereits....
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 Mai 2019, 10:00:32
Klar, aber mit dem ardunio weißt du genau, was in der Luft ist und das musst du dann empfangen - es sei denn, der Empfänger ist Schrott...
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 20 Mai 2019, 20:28:25
Hi,

Ich tippe auf einen Verkabelungsfehler. Zeige mal Fotos insb. von den Lötverbindungen und Kabeln.

Oder die Freq steht nicht auf 433.920 MHz, sieht set DEV Freq und get DEV ccconf

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Kawaci am 20 Juni 2019, 14:22:34
Hallo leute!
Ich habe einen espduino mit cc1101 für somfy Markise! Das blöde ist das ich die Markise nicht mehr über fhem steuern kann! Würde ein Update vom espduino helfen? Wenn ja muss ich dann die Markise neu pairen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 Juni 2019, 14:28:14
Somfy hat einen Rolling Code. FHEM muss also so behandelt werden wie eine eigene Fernbedienung. Mit einer vorhandenen anlernen funktioniert nicht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Esjay am 02 Juli 2019, 09:29:15
Guten Morgen die Herren,
mein Arbeitskollege steigt auch gerade in Fhem ein, und bekommt seinen "SIGNALduino Stick mit 433/868MHz RF-Transceiver für FHEM" (radino) nicht ans Laufen.
Ziel soll es sein, seine Somfy Markise mittels Fhem zu steuern.
Ich muss sagen, das ich null Ahnung von Signalduino habe, daher bitte etwas Nachsicht:

Anbei mal ein List seines Devices

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   DMSG       W58#462F14300D240
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   FD         7
   FUUID      5d111850-f33f-7c49-b7fe-4e0b23fc655f032b
   IDsNoDispatch 2,72.1,82
   LASTDMSG   W58#462F14300D240
   MSGCNT     6369
   NAME       SomfyGate
   NR         25
   PARTIAL   
   RAWMSG     MC;LL=-989;LH=960;SL=-501;SH=486;D=002B9D0EBCFF2DBF0015CE875E7F96DF800AE740;C=489;L=157;R=224;
   RSSI       -90
   STATE      opened
   TIME       1562051811
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages 2019-07-02 09:05:44-MU;P0=369;P1=-1083;P2=-2079;P3=-4012;D=01020102020102010202020202010201010101010203010102010101020301010202020201020101010101010101020102020102010202020202010201010101010203010102020202010201010101010101010201020201020102020202020102010101010102030101020202020102010101010101010102010202010201;CP=0;R=232;O;#2019-07-02 09:05:46-MU;P0=-32001;P1=359;P2=-1100;P3=-2058;P4=-4040;D=012131212121212131412121313131312131212121212121212131213131213121313131313121312121212121;CP=1;R=210;#2019-07-02 09:05:56-MS;P1=446;P3=-8489;P4=200;P5=-2001;P6=-4078;D=134516161615151615151616161515161615151515161616151616151515151516;CP=1;SP=3;R=253;O;m2; ; ;#2019-07-02 09:05:58-MU;P0=437;P1=-4080;P2=-1999;P3=-8944;D=01020201010202020201010102010102020202020103010202020201010102020102020101010202010102020;CP=0;R=211;#2019-07-02 09:05:58-MS;P2=-4052;P3=481;P4=-1019;P5=-2016;D=32343435343435353535343434343434353535353534343535343535353434353534353535;CP=3;SP=2;R=234;O;m0;5;5;#2019-07-02 09:06:21-MU;P0=-1045;P1=1457;P2=478;D=01020101010201010201010101020102020202020101010202010202010101010201010201;CP=2;R=211;#2019-07-02 09:06:40-MS;P0=-4020;P1=384;P2=296;P3=-1081;P4=-2068;D=10231314141414131413131313131313131413141413141314141414141314131313131314;CP=1;SP=0;R=231;O;m2; ; ;#2019-07-02 09:06:40-MS;P0=-4014;P1=371;P3=-1088;P4=-2066;D=10131314141414131413131313131313131413141413141314141414141314131313131314;CP=1;SP=0;R=231;O;m1; ; ;#2019-07-02 09:06:40-MS;P0=-4019;P1=395;P3=-1071;P4=-2069;D=10131314141414131413131313131313131413141413141314141414141314131313131314;CP=1;SP=0;R=231;O;m0; ; ;#2019-07-02 09:06:40-MS;P0=376;P1=-2070;P2=-1095;P3=-4012;D=03020201010101020102020202020202020102010102010201010101010201020202020201;CP=0;SP=3;R=231;O;m2; ; ;#2019-07-02 09:06:42-MS;P0=370;P1=-2070;P2=-1088;P3=-4018;D=03020201010101020102020202020202020102010102010201010101010201020202020201;CP=0;SP=3;R=231;O;m1; ; ;#2019-07-02 09:06:42-MS;P0=375;P1=-2066;P2=-1092;P3=-4018;D=0302020101010102010202020202020202010201010201020101010101020102010101010201020202020202020202020202020202020102010102010201010101010201020202020201;CP=0;SP=3;R=231;m0; ; ;#2019-07-02 09:06:42-MU;P0=375;P1=-2066;P2=-1092;P3=-4018;P4=-32001;D=03020201010101020102020202020202020102010102010201010101010201020202020204;CP=0;R=231;#2019-07-02 09:06:55-MS;P2=-4060;P3=484;P4=-1006;P5=-2012;D=32343435343435353535343434343434353535353534343535343535353434353534353534;CP=3;SP=2;R=231;O;m0;5;4;#2019-07-02 09:06:56-MC;LL=-984;LH=962;SL=-487;SH=493;D=7E002B80;C=487;L=30;R=8;#2019-07-02 09:07:01-MU;P0=-1992;P1=449;P2=-4067;P3=-8952;P4=336;D=010121210101010121212101212101012101012131210101010121212101012101210124;CP=1;R=210;#2019-07-02 09:07:09-MU;P0=-1056;P1=466;P2=-4168;P3=1450;D=01010101210103010303010303030103030103030303010301010101030103030101030101030303010101010101;CP=1;R=216;#2019-07-02 09:07:23-MC;LL=-988;LH=969;SL=-480;SH=514;D=75E7FA5DF8;C=491;L=37;R=218;#2019-07-02 09:07:37-MS;P1=387;P2=-4024;P3=-1079;P4=-2065;D=12131314141414131413131313131313131413141413141313141414141314131313131314;CP=1;SP=2;R=230;O;m2; ; ;#2019-07-02 09:07:37-MS;P1=373;P2=-4016;P3=-1094;P4=-2068;D=12131314141414131413131313131313131413141413141313141414141314131313131314;CP=1;SP=2;R=230;O;m0; ; ;#2019-07-02 09:07:37-MS;P1=390;P2=-4004;P3=-1072;P4=-2082;D=12131314141414131413131313131313131414141413141313131313141314131313131314;CP=1;SP=2;R=230;O; ; ;#2019-07-02 09:07:37-MS;P0=362;P1=-1089;P2=-2085;P3=-4014;D=03010102020202010201010101010101010201020201020101020202020102010101010102;CP=0;SP=3;R=229;O;m2; ; ;#2019-07-02 09:07:38-MS;P0=380;P1=-1088;P2=-2073;P3=-4019;D=03010102020202010201010101010101010201020201020101020202020102010101010102;CP=0;SP=3;R=229;O;m1; ; ;#2019-07-02 09:07:39-MS;P0=362;P1=-1098;P2=-2078;P3=-4019;D=0301010202020201020101010101010101020102020102010102020202010201020202020102010101010101010101010101010101010201020201020101020202020102010101010102;CP=0;SP=3;R=229;m0; ; ;#2019-07-02 09:07:39-MU;P0=362;P1=-1098;P2=-2078;P3=-4019;P4=-32001;D=03010102020202010201010101010101010201020201020101020202020102010101010104;CP=0;R=229;#2019-07-02 09:07:54-MU;P0=176;P1=-1016;P2=474;P3=-2038;P4=-4096;D=0123212323232321212323212323212421212321212323232321212121212121232123232121232123232323212123232123232;CP=2;R=216;#2019-07-02 09:08:20-MC;LL=-969;LH=982;SL=-475;SH=526;D=3AF3FD2EFC;C=491;L=38;R=217;#2019-07-02 09:08:33-MU;P0=-4086;P1=428;P2=-2007;P3=-8952;P4=320;D=0121212121010101210101212101012101310121212121010101212101210104;CP=1;R=217;#2019-07-02 09:08:34-MS;P2=-2068;P3=380;P4=-4020;P6=-1087;D=34363632323232363236363636363636363236323236363232323232323632363636363636;CP=3;SP=4;R=232;O;m1;6;6;#2019-07-02 09:08:34-MS;P2=-2066;P3=366;P4=-4034;P6=-1093;D=34363632323232363236363636363636363236323236363232323232323632363636363636;CP=3;SP=4;R=232;O;m0;6;6;#2019-07-02 09:08:34-MS;P2=-2068;P3=368;P4=-4037;P6=-1105;D=34363632323232363236363636363632323232323236323636363636363632363636363636;CP=3;SP=4;R=232;O;6;6;#2019-07-02 09:08:35-MS;P0=388;P1=-2063;P2=-1070;P3=-4018;D=03020201010101020102020202020202020102010102020101010101010201020202020202;CP=0;SP=3;R=231;O;m1; ; ;#2019-07-02 09:08:35-MS;P0=394;P1=-2063;P2=-1070;P3=-4018;D=0302020101010102010202020202020202010201010202010101010101020102010101010201020202020202020202020202020202020102010102020101010101010201020202020202;CP=0;SP=3;R=231; ; ;#2019-07-02 09:08:43-MC;LL=-971;LH=990;SL=-467;SH=502;D=AE69BEF7BCC8FC005734DF7BDE647E002B9A6FB;C=488;L=156;R=9;#2019-07-02 09:08:43-MC;LL=-957;LH=978;SL=-458;SH=545;D=DEF323F;C=489;L=28;R=246;#2019-07-02 09:08:45-MU;P0=-3936;P1=1452;P2=-1058;P3=467;D=01232121212321212321212121232123232323212321212323212323212121232323232323;CP=3;R=209;#2019-07-02 09:09:04-MU;P0=-2005;P1=443;P2=-4069;P3=-8960;P4=312;D=0101212121012121010121210121312101010101212121010124;CP=1;R=216;#2019-07-02 09:09:16-MC;LL=-968;LH=976;SL=-466;SH=525;D=75E7FA5DF8;C=489;L=37;R=217;#2019-07-02 09:09:31-MS;P0=-4066;P1=365;P2=-1099;P3=-2067;D=10121213131313121312121212121212121312131312131212131313131213121212121212;CP=1;SP=0;R=231;O;m2; ; ;#2019-07-02 09:09:31-MS;P0=-4066;P1=365;P2=-1093;P3=-2067;D=10121213131313121312121212121212121312131312131212131313131213121212121212;CP=1;SP=0;R=231;m1; ; ;#2019-07-02 09:09:31-MU;P0=-1053;P1=470;P2=1452;D=0101020202020101020101020101020201020101;CP=1;R=231;#2019-07-02 09:09:31-MU;P0=-1069;P1=470;P3=1452;P4=-18624;P5=330;P6=176;P7=-4080;D=010303030301030101010103030303010103010103010103030103010145060505750505;CP=1;R=232;#2019-07-02 09:09:31-MS;P0=-2063;P1=362;P2=-1090;P3=-4018;D=13121210101010121012121212121212121012101012101212101010101210121212121212;CP=1;SP=3;R=232;O;m2;!;!;#2019-07-02 09:09:32-MS;P0=-2081;P1=376;P2=-1078;P3=-3997;D=13121210101010121012121212121212121012101012101212101010101210121212121212;CP=1;SP=3;R=232;O;m1; ; ;#2019-07-02 09:09:32-MS;P0=-2081;P1=392;P2=-1078;P3=-3997;D=1312121010101012101212121212121212101210101210121212121212;CP=1;SP=3;R=232;m0; ; ;#2019-07-02 09:09:34-MC;LL=-1015;LH=950;SL=-514;SH=467;D=0AE69BEF78;C=490;L=37;R=16;#2019-07-02 09:09:37-MC;LL=-975;LH=980;SL=-479;SH=514;D=CD37DEFF9B078;C=491;L=49;R=209;#2019-07-02 09:09:46-MU;P0=256;P1=-1054;P2=475;P3=-2028;P4=-4064;D=01232323232121212121212123212323212123212323232321212323212323232421212321212323232321212121212121232123232121232123232;CP=2;R=221;#2019-07-02 09:09:47-MS;P0=-2001;P1=486;P2=-1003;P3=-4060;D=13121210121210101010121212121212121010101012121010121010101212101012101010;CP=1;SP=3;R=222;O;m0; ; ;#2019-07-02 09:10:14-MC;LL=-966;LH=985;SL=-463;SH=542;D=75E7F96DF8;C=492;L=37;R=217;#2019-07-02 09:10:21-MU;P0=1000;P1=-1045;P2=1458;P3=476;D=012121312121312121212131213131313121212121313121313121313121213121313;CP=3;R=209;#2019-07-02 09:10:28-MS;P1=374;P2=-4019;P3=-1090;P4=-2051;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=233;O;m1; ; ;#2019-07-02 09:10:28-MS;P1=366;P2=-3997;P3=-1102;P4=-2071;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=233;O;m0; ; ;#2019-07-02 09:10:28-MS;P1=389;P2=-4006;P3=-1081;P4=-2079;D=12131314141414131413131313131313131414141413141313131313131314131313131313;CP=1;SP=2;R=233;O; ; ;#2019-07-02 09:10:28-MS;P0=361;P1=-1091;P2=-2074;P3=-4026;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m2; ; ;#2019-07-02 09:10:30-MS;P0=395;P1=-1067;P2=-2068;P3=-4021;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m1; ; ;#2019-07-02 09:10:31-MS;P0=388;P1=-1079;P2=-2067;P3=-4021;D=0301010202020201020101010101010101020102020102010102020202010201020202020102010101010101010101010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;m0; ; ;#2019-07-02 09:10:31-MU;P0=388;P1=-1079;P2=-2067;P3=-4021;P4=-32001;D=03010102020202010201010101010101010201020201020101020202020102010101010104;CP=0;R=230;#2019-07-02 09:10:35-MS;P0=-4076;P1=446;P3=-8477;P4=136;P5=-2002;P6=264;D=134560101015151015151015101515101015151515151515101010151510101510;CP=1;SP=3;R=252;O;m2; ; ;#2019-07-02 09:10:38-MU;P0=450;P1=-1998;P2=-4068;P3=-8960;D=010101010201010101010101020202010102020102030201010101020202010102010102010201010202010101010101010;CP=0;R=211;#2019-07-02 09:10:43-MS;P0=-1026;P1=458;P2=-2031;P3=-4096;P4=344;D=13101012101012121212101010101010101210121210101212121212121010121240121212;CP=1;SP=3;R=220;m2; ; ;#2019-07-02 09:10:43-MU;P0=-1008;P1=475;P2=-2020;P3=-4088;P4=-576;D=01012121212121210101212101012121012121213101012101012121214;CP=1;R=220;#2019-07-02 09:10:45-MS;P1=485;P2=-2032;P3=-1015;P4=-4089;P5=-152;D=1413131213131212121213131313131313121312121313121212121212131312121312121212121313131313131312131513131313131213121213131212121212121313121213121212;CP=1;SP=4;R=220;m0; ; ;#2019-07-02 09:11:06-MS;P1=448;P2=-8968;P3=96;P4=-11608;P6=-1989;P7=-4076;D=12341617171716161716171716171616171716161616161616171717161616171617;CP=1;SP=2;R=252;O;m2; ; ;#2019-07-02 09:11:07-MU;P0=455;P1=-1988;P2=-4072;P3=-8952;D=0101010202010101010101010202020101010201020302010101010202020101020102020102010102020101010101010;CP=0;R=210;#2019-07-02 09:11:09-MU;P0=-1040;P1=484;P2=1457;D=0102020102020202010201010101020202020101020101010101010101020102;CP=1;R=210;#2019-07-02 09:11:09-MC;LL=-940;LH=1008;SL=-454;SH=595;D=002B9D0EBC;C=499;L=40;R=225;#2019-07-02 09:11:25-MS;P1=371;P2=-4025;P3=-1088;P4=-2066;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=230;O;m2; ; ;#2019-07-02 09:11:25-MS;P1=386;P2=-4032;P3=-1075;P4=-2071;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=230;O;m1; ; ;#2019-07-02 09:11:25-MS;P1=371;P2=-4032;P3=-1095;P4=-2065;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=230;O;m0; ; ;#2019-07-02 09:11:25-MS;P1=391;P2=-4020;P3=-1079;P4=-2081;D=12131314141414131413131313131313131414141413141313131313131314131313131313;CP=1;SP=2;R=230;O; ; ;#2019-07-02 09:11:25-MS;P0=384;P1=-1078;P2=-2064;P3=-4018;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=229;O;m2; ; ;#2019-07-02 09:11:26-MS;P0=377;P1=-1090;P2=-2071;P3=-4025;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=229;O;m1; ; ;#2019-07-02 09:11:27-MS;P0=366;P1=-1106;P2=-2065;P3=-4025;D=0301010202020201020101010101010101020102020102010102020202010201020202020102010101010101010101010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=229;m0; ; ;#2019-07-02 09:11:27-MU;P0=366;P1=-1106;P2=-2065;P3=-4025;P4=-32001;D=03010102020202010201010101010101010201020201020101020202020102010101010104;CP=0;R=229;#2019-07-02 09:11:29-MU;P0=200;P1=-3932;P2=492;P3=-1949;P4=336;P5=-528;P6=-8600;D=01232121212323212323232343252643212323212121212123232123232323;CP=2;R=220;#2019-07-02 09:11:37-MS;P0=-4095;P1=433;P2=-8969;P3=200;P4=-11600;P5=-2004;D=12341510101015151015101015101515101015151515151515101010151515101510;CP=1;SP=2;R=251;O;m2; ; ;#2019-07-02 09:11:39-MU;P0=443;P1=-2002;P2=-4067;P3=-8944;D=010101010201010101010101020202010101020102030201010101020202010102010202010201010202010101010101010;CP=0;R=211;#2019-07-02 09:11:40-MU;P0=-664;P1=414;P2=-2103;P4=140;P5=-112;P6=-1087;P7=-4136;D=01212121245421216161212161242121716161216164;CP=1;R=219;#2019-07-02 09:11:40-MU;P0=288;P1=-2079;P2=394;P3=-1121;P4=-4104;P6=176;P7=112;D=012323212123012121242323212323212121212303232363237;CP=2;R=218;#2019-07-02 09:11:41-MU;P0=104;P1=-2060;P2=346;P3=453;P4=-1109;P5=196;P6=-4112;D=0121313134343131345131313634343124343131313134343434343424213421315;CP=3;R=218;#2019-07-02 09:12:07-MC;LL=-985;LH=972;SL=-498;SH=504;D=75E7F96DF8;C=493;L=37;R=250;#2019-07-02 09:12:22-MS;P1=381;P2=-4005;P3=-1082;P4=-2071;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=232;O;m2; ; ;#2019-07-02 09:12:22-MS;P1=372;P2=-4023;P3=-1093;P4=-2066;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=232;O;m0; ; ;#2019-07-02 09:12:22-MS;P1=379;P2=-4019;P3=-1086;P4=-2070;D=12131314141414131413131313131313131414141413141313131313131314131313131313;CP=1;SP=2;R=232;O; ; ;#2019-07-02 09:12:22-MS;P0=375;P1=-1097;P2=-2067;P3=-4014;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m2; ; ;#2019-07-02 09:12:23-MS;P0=374;P1=-1084;P2=-2060;P3=-4019;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m1; ; ;#2019-07-02 09:12:23-MS;P0=379;P1=-1084;P2=-2060;P3=-4019;D=0301010202020201020101010101010101020102020102010102020202010201020202020102010101010101010101010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230; ; ;#2019-07-02 09:13:05-MC;LL=-972;LH=973;SL=-468;SH=534;D=75E7F96DF8;C=491;L=37;R=216;#2019-07-02 09:13:19-MS;P1=385;P2=-4015;P3=-1080;P4=-2066;D=12131314141414131413131313131313131413141413141314141414141314131313131313;CP=1;SP=2;R=230;O;m1; ; ;#2019-07-02 09:13:19-MS;P1=394;P2=-4007;P3=-1079;P4=-2058;D=12131314141414131413131313131313131413141413141314141414141314131313131313;CP=1;SP=2;R=230;O;m0; ; ;#2019-07-02 09:13:19-MS;P1=370;P2=-4019;P3=-1100;P4=-2062;D=12131314141414131413131313131313141414141413141313131313131314131313131313;CP=1;SP=2;R=230;O; ; ;#2019-07-02 09:13:19-MS;P0=374;P1=-2065;P2=-1097;P3=-4030;D=03020201010101020102020202020202020102010102010201010101010201020202020202;CP=0;SP=3;R=231;O;m2; ; ;#2019-07-02 09:13:21-MS;P0=390;P1=-2059;P2=-1077;P3=-4031;D=03020201010101020102020202020202020102010102010201010101010201020202020202;CP=0;SP=3;R=231;O;m1; ; ;#2019-07-02 09:13:22-MS;P0=397;P1=-2061;P2=-1070;P3=-4031;D=0302020101010102010202020202020202010201010201020101010101020102010101010201020202020202020202020202020202020102010102010201010101010201020202020202;CP=0;SP=3;R=231;m0; ; ;#2019-07-02 09:13:22-MU;P0=397;P1=-2061;P2=-1070;P3=-4031;P4=-32001;D=03020201010101020102020202020202020102010102010201010101010201020202020204;CP=0;R=231;#2019-07-02 09:13:34-MS;P2=-4086;P3=472;P4=-1028;P5=-2051;D=32343435343435353535343434343434353535353534343535343535353434353534353535;CP=3;SP=2;R=221;O;m0;5;5;#2019-07-02 09:13:36-MU;P0=470;P1=-1022;P2=-1871;P3=-4040;D=010102020202020201010202010202020301010201010202020201010101010101020102;CP=0;R=210;#2019-07-02 09:14:02-MC;LL=-978;LH=977;SL=-469;SH=538;D=AF3FCB6FC;C=493;L=34;R=217;#2019-07-02 09:14:16-MS;P1=362;P2=-4033;P3=-1092;P4=-2075;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=228;O;m2; ; ;#2019-07-02 09:14:16-MS;P1=372;P2=-4020;P3=-1092;P4=-2066;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=228;O;m1; ; ;#2019-07-02 09:14:16-MS;P1=368;P2=-4026;P3=-1102;P4=-2076;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=228;O;m0; ; ;#2019-07-02 09:14:16-MS;P0=369;P1=-1098;P2=-2070;P3=-4016;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m2; ; ;#2019-07-02 09:14:18-MS;P0=371;P1=-1095;P2=-2068;P3=-4032;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;O;m1; ; ;#2019-07-02 09:14:19-MS;P0=373;P1=-1087;P2=-2067;P3=-4032;D=0301010202020201020101010101010101020102020102010102020202010201020202020102010101010101010101010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=230;m0; ; ;#2019-07-02 09:14:19-MU;P0=373;P1=-1087;P2=-2067;P3=-4032;P4=-32001;D=03010102020202010201010101010101010201020201020101020202020102010101010104;CP=0;R=230;#2019-07-02 09:14:21-MU;P0=-96;P1=112;P2=-1376;P3=152;P4=-1041;P5=485;P6=1459;D=01234545454546454646454646464546464546464646454645454545464646464545464545454545454545464546;CP=5;R=211;#2019-07-02 09:14:59-MC;LL=-982;LH=972;SL=-484;SH=510;D=9FE5B7E;C=491;L=27;R=210;#2019-07-02 09:15:09-MU;P0=160;P1=-4192;P2=469;P3=-1058;P4=1451;D=01234323434323434343234343234343434323432323232343434343232343232323232323232343234;CP=2;R=210;#2019-07-02 09:15:13-MS;P1=374;P2=-4022;P3=-1091;P4=-2064;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=230;O;m2; ; ;#2019-07-02 09:15:13-MS;P1=368;P2=-4027;P3=-1103;P4=-2071;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=230;O;m1; ; ;#2019-07-02 09:15:13-MU;P1=444;P2=-4073;P3=-1061;P4=-1991;P6=-13576;P7=-8968;D=12131314141414131413131313131313131414141413141313141414141314131313131313121313141414141314131313131313131214141214141413131414141413141316141414141212121414121414141212141412121412141412141412121214141214141217121414141412121214141214141412121414121214;CP=1;R=230;O;#2019-07-02 09:15:14-MU;P0=448;P1=-4134;P2=-2000;P3=-8942;D=01020201020201030102020202020103010202020201010102020102020201010202010102020202020202010101020201020201030102020202010101020201020202010102020101020202020202020101010202010202010301020202020101010202010202020101020201010202020202020201010102020102020103;CP=0;R=251;O;#2019-07-02 09:15:15-MU;P0=446;P1=-2003;P2=-4065;P3=-8944;P4=-32001;D=03020101010102020201010201010102020101020201010101010101020204;CP=0;R=251;#2019-07-02 09:15:28-MU;P0=320;P1=-2077;P2=429;P3=-4152;P4=-1039;P5=200;D=01232424212424212121212424242424042421242121245;CP=2;R=218;#2019-07-02 09:15:28-MU;P0=310;P1=-1038;P2=451;P3=-2065;P5=-4080;P6=160;D=01210323232321212121212121032123232123212123230323212103232123232325212123212123036;CP=2;R=220;#2019-07-02 09:15:28-MU;P0=144;P1=433;P2=-1087;P3=-2059;P5=96;P6=-112;P7=244;D=121213121213131313121212121212125673121313121312127313130;CP=1;R=219;#2019-07-02 09:15:29-MU;P0=228;P1=-4128;P2=419;P3=-1062;P4=-2069;P7=-96;D=012323242323242424242323232323232324232424232423232407;CP=2;R=220;#2019-07-02 09:15:29-MU;P0=264;P1=-1065;P2=436;P3=-2068;P4=176;D=0121232123232123212123232323212123232123234;CP=2;R=219;#2019-07-02 09:15:54-MC;LL=-983;LH=976;SL=-468;SH=536;D=75E7F96DF8;C=493;L=37;R=226;#2019-07-02 09:15:55-MU;P0=-3792;P1=112;P2=-1046;P3=476;P4=1450;D=01232424232424242324242324242424232423232323242424242323242323232323232323242324;CP=3;R=245;#2019-07-02 09:16:10-MS;P1=380;P2=-4033;P3=-1088;P4=-2082;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=229;O;m2; ; ;#2019-07-02 09:16:10-MS;P1=373;P2=-4018;P3=-1090;P4=-2072;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=229;O;m0; ; ;#2019-07-02 09:16:10-MS;P1=399;P2=-4041;P3=-1080;P4=-2070;D=12131314141414131413131313131313131413141413141313141414141314131313131313;CP=1;SP=2;R=229;O; ; ;#2019-07-02 09:16:10-MS;P0=388;P1=-1090;P2=-2047;P3=-4006;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=231;O;m2; ; ;#2019-07-02 09:16:10-MS;P0=360;P1=-1102;P2=-2071;P3=-4013;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=231;O;m1; ; ;#2019-07-02 09:16:11-MS;P0=375;P1=-1090;P2=-2075;P3=-4013;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=231;m0; ; ;#2019-07-02 09:16:11-MS;P0=375;P1=-1090;P2=-2075;P3=-4013;D=03010102020202010201010101010101010201020201020101020202020102010101010101;CP=0;SP=3;R=231; ; ;#2019-07-02 09:16:39-MC;LL=-969;LH=984;SL=-463;SH=536;D=0AE69BEF7BCC8FC005734DF7BDE647E002B9A6FA;C=486;L=159;R=10;#2019-07-02 09:16:51-MC;LL=-997;LH=966;SL=-457;SH=530;D=75E7F96DF8;C=491;L=37;R=220;
   version    V 3.3.1-experimental SIGNALduino cc1101 (433 Mhz ) - compiled at Jun 16 2019 00:09:11
   versionmodul v3.3.3
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-07-01 18:36:41   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2019-07-01 18:37:07   ccpatable       C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2019-07-01 18:37:50   cmds             V R t X S P C r W s x e
     2019-07-01 18:38:08   config          MS=1;MU=1;MC=1;Mred=0
     2019-07-01 18:38:44   freeram         1495
     2019-07-01 18:36:24   ping            OK
     2019-07-01 18:54:04   state           opened
     2019-07-01 18:54:04   version         V 3.3.1-experimental SIGNALduino cc1101 (433 Mhz ) - compiled at Jun 16 2019 00:09:11
   additionalSets:
     flash      release
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     23
     25
     33
     35
     41
     51
     55
     65
     90
     91.1
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
Attributes:
   hardware   radinoCC1101
   room       Draußen->Südterasse
   updateChannelFW stable
   verbose    5


Seht ihr auf Anhieb, woran es evtl. liegen kann?

Welche Informationen können noch hilfreich sein?

Ich danke euch schonmal für die Gedult.

Grüße






Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 02 Juli 2019, 19:45:31
Hi,
Erstmal sieht der gut aus.
Aber wir haben keine Frequenz Angabe. Somfy sendet auf 433.420 MHz nicht wie Standard 433.920 MHz. Also über set <DEV> freq 433.42 ändern.
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 03 Juli 2019, 06:38:54
Moin
Ich haette auch gesagt, dass es gut aussieht. Die Beschreibung was aber geht, oder nicht, und was schon gemacht wurde, ist etwas mager. Bei Somfy bitte auch bedenken, dass der neue "Sender" angelernt werden muss, und es einen rolling code gibt, siehe 3 posts zuvor!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Tri am 05 Juli 2019, 17:29:04
Hallo!

Vielen Dank für die prompten Antworten. Ich bin der Kollege.

@RaspiLED: Der Hinweis war absolut richtig, danach hat FHEM auch andere, fremde Somfy-Geräte über autoconf angelegt. Mit der Frequenz war auf alle Fälle ein Fehler.

Das eigendliche Problem lag aber in meinem Verständnis von Somfy.  :-[ Ich dacht, Somfy ist Somfy. Meine Markise hat aber Somfy-IO. Das hatte ich übersehen. Unterlagen von meiner Markise hatte ich auch nicht gefunden, habe dann aber nochmal auf der Somfy-Homepage gesucht. Damit muss ich mir wohl oder übel ein Gateway für io-homecontrol besorgen, eine andere Möglichkeit wird es auf einfachem Weg wohl nicht geben. Die Frequenz hier ist: 868-870 Mhz, io-homecontrol® triband bi-directional.

Danke
Tri
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 05 Juli 2019, 18:07:11
Moin
Und herzlich willkommen. Ja um ein Gateway kommst Du nicht herum. Ich persoenlich nutze die Connexoon, und das Tahoma Modul. Es gibt auch andere Ansaetze hier im Forum, diese setzen aber auf das Flagschiff von Velux, was ja auch io-homecontrol ist.
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Tri am 09 Juli 2019, 23:18:47
Vielen Dank für die schnelle Hilfe! Ich habe etwas länger gebraucht, mich durch die entsprechenden Beiträge zu wühlen.

Das Thema ist hier etwas Offtopic, vom Kontext gehört es, meine ich trotzdem hierher.

Der Somfy Connexoon ist auf alle Fälle eine Lösung. Leider funktioniert der nur mit Somfy-Server. Und falls man dann neben der Markise noch Rollläden betreiben will, zahlt man für die Freischaltung 29 €. Falls dann noch Sicherheitstechnik dazu kommt, nochmal 29 €.

Ich liebäuge mit VELUX Integra KLF 200. Der soll 200 Geräte bedienen können, davon fünf Geräte über seine Eingänge. Dafür ist er teurer, hat aber keine versteckten Kosten und ist lokal im Netzwerk.

Endgültig entschieden habe ich mich noch nicht. So günstig wie ein Cul sind beide Lösungen halt nicht.

Viele Grüße
Tri

Nachtrag 31.07.2019
Heute ist der Velux KLF200 mit Firmware 2.0.0.71 für io-homecontrol angekommen, Somfy Markise und Außenrollos funktionieren damit super. Aus FHEM kann die Sollposition vorgegeben werden, es wird die Stellung zurück geliefert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: mayonezo am 01 Oktober 2019, 00:01:01
Hallo,

ist es möglich einen Arduino Leonardo als Signalduino zu betreiben? Ich konnte RF_Receiver.ino zwar kompilieren und flashen, aber in minicom kann ich dann nichts tippen. Muss ich noch etwas anpassen in der RF_Receiver.ino? Oder müsste noch viel mehr geändert werden? Ich habe noch nicht viel mit den Arduinos zu tun gehabt.

Ich hoffe die Frage ist hier am richtigen Ort platziert.  :-[

Viele Grüße
Mayonezo
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 08 Oktober 2019, 09:32:06
Hi,

Der Leonardo hat meines Wissens nach dem gleichen Chipn wie der pro Micro und auch wie der Radino.
Da unterscheiden sich dann nur die Pins.

Selber compiliren geht z.B. mit der Arduino IDE, wenn Du alle Bibliotheken in das Sketch Verzeichnis kopierst.
Ich könnte auch Mal eine kopieren, nur mit den Pins könnte es Anpassungsbedarf geben.


Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 08 Oktober 2019, 10:16:37
Hallo, mach dir die Arbeit und Vergleiche die Pins vom bsp Radino in der Ino Datei mit dem Leonardo. Passe diese an und kompiliere :)

Auf die schnelle ...
(https://uploads.tapatalk-cdn.com/20191008/3c21da7b7163d2dc1e117dc9bdb10176.jpg)

(https://uploads.tapatalk-cdn.com/20191008/d0efb51973a4b1933b7a98715b156209.jpg)

@Sidey, wollen wir den Leoardo mit aufnehmen analog dem Radino? So muss der User nur ,,umschalten" vor dem Kompilieren.

Grüße marco


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sash.sc am 19 Oktober 2019, 16:25:37
Werden, egal bei welcher Firmware; die Signale über RX/TX ausgegeben ??? So das diese auch auf einer seriellen Schnittstelle zu finden sind ?

Gruß
Sascha
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: xsichtasdf am 24 November 2019, 13:51:57
Hallo zusammen,
Ich Versuche gerade einen Signalduino für meine Somfy RTS Rollos zum laufen zu bekommen.

Der Signalduino mit C1101 konnte soweit auch geflashed und in FHEM eingerichtet werden, jedoch habe ich ein Problem die Frequenz einzustellen.
Sobald ich Versuche die Frequenz auf 433.42 einzustellen, verändert sich zwar die Frequenz gemäß des 'get ccconf' jedoch dann Mal auf 600, Mal 12000, Mal 20000 MHz...  ???

Hat jemand eine Idee wieso ich die Frequenz nicht setzen kann? Ein Reset via dem 'raw e' command hat auch nichts gebracht (Befehl wurde erfolgreich quittiert).

In der folgenden Liste hatte ich zuvor Set sduino cc1101_freq 433.42 eingegeben.

Anbei die Liste des sduino:

Save config
Tablet-UI
Alarm System
01_Konfiguration
AMAD
Alarm
Badezimmer
Büro
CUL_HM
Flur_Keller
Gästezimmer
Hausflur
Heizungs_Keller
Küche
LGTV
Schlafzimmer
Technik_Keller
Unsorted
Wohnzimmer
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   FD         10
   FUUID      5dda7346-f33f-590a-9f4d-e20df0a2ef9bc4f1
   IDsNoDispatch 2,72.1,82
   LASTDMSG   nothing
   LASTDMSGID nothing
   NAME       sduino
   NR         1580
   PARTIAL   
   STATE      opened
   TIME       1574597446.44067
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-RC10 SIGNALduino cc1101  - compiled at Dec 29 2018 01:43:10
   versionProtocols 1.06
   versionmodul v3.4.0
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92|93|95)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-11-24 13:44:23   ccconf          freq:633.795MHz bWidth:812KHz rAmpl:24dB sens:4dB  (DataRate:24.80Baud)
     2019-11-24 13:34:24   ccpatable       C3E = 8C 00 00 00 00 00 00 01
     2019-11-24 13:20:11   cmds             V R t X S P C r W x e
     2019-11-24 13:20:15   config          MS=1;MU=1;MC=1;Mred=1
     2019-11-24 13:20:22   freeram         946
     2019-11-24 13:46:47   ping            OK
     2019-11-24 13:20:54   raw             ccFactoryReset done
     2019-11-24 13:30:47   state           opened
     2019-11-24 13:30:47   version         V 3.3.1-RC10 SIGNALduino cc1101  - compiled at Dec 29 2018 01:43:10
   additionalSets:
     flash     
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     23
     25
     33
     33.1
     33.2
     35
     41
     51
     55
     65
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
Attributes:
   hardware   nanoCC1101
   room       01_Konfiguration


Für Hilfe vielen Dank!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 24 November 2019, 14:51:33
Wenn du somfy nimmst, musst du gar nichts einstellen.

Ändernde Frequenzen sind kein "typisches" Problem. Sind Lötstellen etc ok?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: xsichtasdf am 24 November 2019, 16:00:02
Hi, danke für dein Feedback.
Okay, habe auch versucht mehrere meiner Rollos zu pairen (gemäß "Somfy via Signalduino"-Anleitung), jedoch ohne Erfolg.
Nach dem auslösen des Konfigurationsmodus via Fernbedienung passiert beim anschließenden 'set rollo_x prog' einfach nichts.

Die Lötstellen sind imho I.O..
Gibt es irgendwelche Debug Methoden die ich anwenden kann? Finde die springenden Frequenz Werte sehr mysteriös...

Vielen Dank!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 24 November 2019, 17:09:06
Es stimmt ja nicht nur die Frequenz nicht:
freq:633.795MHz bWidth:812KHz rAmpl:24dB sens:4dB  (DataRate:24.80Baud)
Auch Bandbreite und rAmpl hast du sicher nicht so eingestellt.

Das deutet alles auf fehlerhafte Kommunikation zwichen Arduino und CC1101 oder schlechte Stromversorgung hin.
Wie ist der CC1101 angeschlossen? Level-Shifter oder Spannungsteiler mit Widerständen? Wenn Widerstände, welche Werte?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 November 2019, 17:33:28
Kann es sein, dass Du verschiedenen Firmware Versionen geflasht hast?

Das sieht mir so aus, als ob die Register nicht an der korrekten Stelle aus dem eeprom geladen werden.

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: xsichtasdf am 24 November 2019, 18:14:34
Hi ihr beiden,

@elektron-bbs:
Habe mich an folgenden Schaltplan gehalten
https://images.app.goo.gl/tx436V2HJjmt1i279  (https://images.app.goo.gl/tx436V2HJjmt1i279), somit 10 und 4,7 k.

Habe die Verbindungen gemäß des Plans soeben nochmal geprüft und sieht I.O. aus.

@Sidey: Den Signalduino habe ich über fhem gemäß Anleitung geflashed. Habe vorhin nochmal anhand der selben Anleitung eine neuere Version geflashed.
Verhalten war zwischen beiden Versionen unverändert.

Logfile des Flashvorgangs:


Save config
Tablet-UI
Alarm System
01_Konfiguration
AMAD
Alarm
Badezimmer
Büro
CUL_HM
Flur_Keller
Gästezimmer
Hausflur
Heizungs_Keller
Küche
LGTV
Schlafzimmer
Technik_Keller
Unsorted
Wohnzimmer
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
jump to the end


avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/opt/fhem/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex"
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex auto detected as Intel Hex
avrdude: writing flash (25298 bytes):

Writing | ################################################## | 100% 7.72s

avrdude: 25298 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex:
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex contains 25298 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.84s

avrdude: verifying ...
avrdude: 25298 bytes of flash verified

avrdude done.  Thank you.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 24 November 2019, 18:20:57
Mach mal ein factory reset bitte :
get raw e
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 24 November 2019, 20:12:52
und nach dem "get raw e", bitte ein
get ccreg 99
posten

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 24 November 2019, 20:52:17
Das Bild für den Anschluss ist nun schon seit gefühlten Ewigkeiten im Wiki. Ist es wirklich noch niemandem aufgefallen, das da m.E. noch ein Spannungsteiler zwischen Nano D3 und CC1101 GDO0 fehlt?
D3 ist doch der Ausgang vom Nano, der die Sendesignale ausgibt - braucht also auch eine Pegelanpassung.
Außerdem sind die Widerstandswerte im Bild zu hoch angesetzt. Es wird zwar im Text angegeben:
ZitatFür eine bessere Signalübertragung sollten besser 470 Ohm/1000 Ohm genommen werden, statt der 4.7k/10k Variante in der Darstellung rechts.
aber das überliest man schon mal. Siehe auch: https://forum.fhem.de/index.php/topic,52865.0.html

Außerdem wäre es vielleicht sinnvoll, mal die aktuellste Firmware zu flashen:
https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-exp/SIGNALDuino_ESP82663.3.1-exp.hex

Damit sieht man auch, ob der CC1101 richtig erkannt wird. Das sollte dann in etwa so aussehen:
V 3.3.1-experimental SIGNALduino cc1101 (chip CC1101) - compiled at Sep 22 2019 22:53:27
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: xsichtasdf am 25 November 2019, 16:30:50
Hi,

@Sidey: done! Keine Veränderung des Verhaltens. Frequenzen springen wie wild, Somfy kann nicht gepaired werden.

@Ralf9: ccregAll:

ccreg 00: 29 2E 3F 07 A6 91 FE 04 45 00 00 0F 00 1E 18 B8
ccreg 10: 18 22 02 22 F0 47 07 30 04 76 6C 03 40 91 0E 6B
ccreg 20: F0 56 10 A9 0A 20 0D 41 00 59 7F 3F 10 31 0B


@elektron-bbs: Done! Gab aber ein Fehler bei der Verifikation:
avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALDuino_ESP82663.3.1-exp.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALDuino_ESP82663.3.1-exp.hex:
avrdude: input file FHEM/firmware/SIGNALDuino_ESP82663.3.1-exp.hex auto detected as raw binary
avrdude: input file FHEM/firmware/SIGNALDuino_ESP82663.3.1-exp.hex contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.55s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7800
         0x0c != 0xff
avrdude: verification error; content mismatch

avrdude done.  Thank you.


Danke für eure Hilfe.


Update:
Ich habe eine neue Platine zusammengebaut, die zwar genauso geschaltet ist wie die andere, aber nun funktioniert es.  :o

Also Problem ist tatsächlich gelöst, wieso es mit dem Steckbrett nicht geklappt hat, werde ich vermutlich nie verstehen...
Danke für Euer Engagement bei der Suche nach dem Fehler! :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 25 November 2019, 21:53:08
Mhmm, du beschaltest einen Arduino Nano, flashst dann eine Firmware für einen ESP8266 und wunderst dich über Fehler?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 25 November 2019, 23:42:08
Hmm, Steckbrett? Die haben teilweise große Innenwiderstände. Das kann dann schon auf das Timing der Flanken gehen und damit die Kommunikation zwischen Nano und cc1101 stören.
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 09 Dezember 2019, 00:17:36
Hallo zusammen,
ich nutze seit Jahren erfolgreich einen 433MHz Signalduino mit Arduino Nano aus China und einem 433Mhz CC1101 Modul.
Ein 868Mhz Modul hatte ich ebenfalls erfolgreich im Testbetrieb mit Somfy Rolläden.

Jetzt habe ich ein spezielles Problem und dachte der Signalduino könnte mir dabei helfen.
Ich möchte ein neues 868Mhz Protokoll dekodieren und habe meinen 868Mhz Signalduino via FHEM konfiguriert und jetzt direkt am Windows PC via Terminalprogramm laufen.
Dabei soll mir der Signalduino dabei behilflich sein und mir die Bitfolgen / Zeiten mitprotokollieren.

Leider kommt keine einzige Botschaft auf dem Terminal an (nach umkonfigurieren auf 433Mhz schon).
Könnte es sein, dass der Signalduino auf irgenwelche Triggerbedingungen wartet, bevor er überhaupt etwas ausgibt?
(die RAW Kommandos kann ich absetzten und bekomme auch Sinnvolle Antworten, z.B. auf CG
CG
MS=1;MU=1;MC=1;Mred=0
;S%X;

(also alle Messagetypen aktiviert)

Ich habe die aktuellste Version geflasht:
V
V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Dec  4 2019 22:02:15
;S%X;


Vielleicht kann mir jemand helfen, mache ich etwas falsch oder kann meine Idee mit der aktuellen Imlementierung nicht funktionieren?

Viele Grüße
RaspII
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 09 Dezember 2019, 04:18:16
Zitat von: RaspII am 09 Dezember 2019, 00:17:36
Jetzt habe ich ein spezielles Problem und dachte der Signalduino könnte mir dabei helfen.
Ich möchte ein neues 868Mhz Protokoll dekodieren und habe meinen 868Mhz Signalduino via FHEM konfiguriert und jetzt direkt am Windows PC via Terminalprogramm laufen.
Dabei soll mir der Signalduino dabei behilflich sein und mir die Bitfolgen / Zeiten mitprotokollieren.

Hallo,
um welche Hardware / Sensor oder Device handelt es sich, was du decodieren möchtest.

Es kann durchaus sein, das der Empfänger nichts mitbekommt, da es bei der neuen Hardware um eine andere Modulation handelt.

Mfg Marco


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 09 Dezember 2019, 07:59:43
Hallo Marco,
es geht um das alte Kopp Free Control Protokoll.
Das neue habe ich bereits für CUL.. (kopp-fc) implementiert, jetzt möchte ich für einen User das ältere Protokoll implementieren, ohne dass ich die Hardware habe.
Die Modulationsart ist bei beiden Sendern GFSK, ich vermute das die alte Version eine leicht unterschiedliches Protokoll benutzt oder evt. sogar nur eine unterschiedliche Präambel oder Sync-Pattern.

Ich habe hierfür eine Anfrage bekommen, siehe https://forum.fhem.de/index.php/topic,47846.msg998197.html#msg998197 (https://forum.fhem.de/index.php/topic,47846.msg998197.html#msg998197) und möchte jetzt mit der Arbeit beginnen.

Gruß
RaspII
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 09 Dezember 2019, 09:49:22
Hallo Raspll,

ich habe mir mal einiges dazu angesehen und versucht herein zu denken.

Vorschlag, für die Implementierung eröffnest du bitte hier https://github.com/RFD-FHEM/RFFHEM/issues
einen Faden. Da lesen ein wenig mehr Entwickler und Wissende mit bzw. da ist es für uns einfacher dies nachzuvollziehen. Solltest du dennoch mein Account besitzen, dann machen wir hier weiter. ;)

Gib bitte deine Schritte / Vorgehensweise an und was mir sofort auffiel, lies bitte das Register mit ccreg 99 aus.

Mit diesem Stand sollten wir zum Erfolg kommen.

Liebe Grüße Marco


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 09 Dezember 2019, 11:03:53
Ok
Github Account habe ich, dann Versuch ich heute Abend mal Euer System zu verstehen und melde mich wieder
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 09 Dezember 2019, 17:15:28
Zitat von: RaspII am 09 Dezember 2019, 07:59:43
Das neue habe ich bereits für CUL.. (kopp-fc) implementiert, jetzt möchte ich für einen User das ältere Protokoll implementieren, ohne dass ich die Hardware habe.
Die Modulationsart ist bei beiden Sendern GFSK, ich vermute das die alte Version eine leicht unterschiedliches Protokoll benutzt oder evt. sogar nur eine unterschiedliche Präambel oder Sync-Pattern.

Wenn die Modulationsart wirklich GFSK ist, kannst du mit dem SIGNALduino so nichts empfangen. Der CC1101 wird dort für ASK/OOK konfiguriert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 09 Dezember 2019, 18:01:25
Die Frage wäre dann im man (ich) es mit moderaten Aufwand schaffen könnte das zu ändern und mich jemand dabei unterstützen kann (ich habe mir den Sketch mal angeschaut und erst mal nichts begriffen)

Letztendlich könnte ich das ganze such auf Basis meiner Kopp-fc Routine machen würde mir aber gerne die Routinen kopieren die bei SD die Bitzeiten ausmisst und kommuniziert. Ich bin ab va. 20:00 uhr zuhause und schau mich dann mal auf Github um
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 09 Dezember 2019, 21:44:10
Hallo RaspII,

Ich habe bei mir eine ältere Funkfernbedienung für Rolläden im Einsatz. Mit dem Signalduino bin ich recht weit gekommen (siehe https://forum.fhem.de/index.php/topic,85006.0.html sowie Wiki zu Unbekannte Funkprotokolle), habe aber letztendlich realisiert, dass die FB 2FSK nutzt und der Signalduino von Hause aus nur OOK kann. Über eine der Oberwellen konnte ich meine Aktoren so halbwegs steuern, aber nicht sicher. Der CC1101 kann auch 2FSK. Es gibt ein Development Kit des Herstellers mit dem man halbwegs einfach die passende Registerkonfiguration ermitteln kann.

Ich bin gespannt was bei Deinen Aktivitäten rauskommt, denn ich suche immer noch eine 2FSK-Lösung für meine Rollädenaktoren.

Ciao, plin
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 17 Dezember 2019, 13:27:00
@plin liest Du hier mit?
https://forum.fhem.de/index.php/topic,82379.msg1002565.html#msg1002565
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 17 Dezember 2019, 18:05:00
@plin
meinen aktuellen Status kannst Du hier sehen:
https://github.com/RFD-FHEM/RFFHEM/issues (https://github.com/RFD-FHEM/RFFHEM/issues)

Nachtrag: Die aktuellste Diskussion zu diesem Thema ist hier:
https://forum.fhem.de/index.php/topic,82379.300.html (https://forum.fhem.de/index.php/topic,82379.300.html)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 17 Dezember 2019, 22:13:21
Zitat von: Ralf9 am 17 Dezember 2019, 13:27:00
@plin liest Du hier mit?
https://forum.fhem.de/index.php/topic,82379.msg1002565.html#msg1002565
Danke für den Tipp, hab' mir ein Lesezeichen gesetzt ...

Mich interessiert immer noch die Frage wieviele der internen CC1101-Register abzuändern sind damit er GFSK oder 2FSK versteht und spricht. Ich bin damals mit meiner OOK-Oberwelle recht weit gekommen, habe also eigentlich eine recht gute Startposition. Eigentlich braucht der SIGNALduino nur einen kleinen FSK-Schubs...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspII am 17 Dezember 2019, 22:53:27
@plin
wenn Du mir sagst was Du genau einstellen willst, kann ich Dir evt. weiterhelfen.
Ein kleiner FSK Schubs wird aber nicht ausreichen, weil die Modulationsverfahren unterschiedlich sind, siehe:
https://forum.fhem.de/index.php/topic,82379.msg1002844.html#msg1002844 (https://forum.fhem.de/index.php/topic,82379.msg1002844.html#msg1002844)

Wenn wir mit dem Signalduino tatsächlich FSK demodulieren wollen, macht langfristig vermutlich nur ein anderes Verfahren Sinn, d.h. wir bräuchten erst mal ein Konzept.

Es könnte aber auch sein, dass die culfw hier eigentlich die erste Wahl ist, ich muss da nochmal nachdenken, das hängt davon ab ob man im CC1101 die Bitrate einstellen muss (im synchronen Mode) oder ob diese vom Baustein automatisch geliefert wird.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 18 Dezember 2019, 17:30:09
Ich wollte mir über die Feiertage das LaCrosse Gateway zusammenlöten und testen (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x). 

Alles andere steht im Wiki (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle).

Derzeit kann ich OOK senden und treffe mehr oder weniger gut den Punkt an dem die Empfänger eine Oberwelle für eine FM-Modulation halten. Trägerfreuenz, Hub und Baudrate sind halbwegs bekannt. Eigent.ich würde ich gerne beim SIGNALduino bleiben (der funktioniert ja schon halbwegs mit OOK).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 18 Dezember 2019, 18:57:21
Hallo zusammen

Ich hoffe das ich hier richtig bin.

Mein Signalduino läuft zur vollen Zufriedenheit.
Ich steuere darüber über FD Keelog meine Rolläden und empfange meine Außentemperatursensoren.

Leider erreichen mich auch diverse Sensoren die mir nicht gehören.
4 Habe ich bereits per Autocreate anlegenlassen die müllen meinen Log schon mal nicht mehr zu, die verbanne ich einfach.
Ich habe die Withlist auch schon auf die beiden Protokolle reduziert die ich nutze, bekomme aber immer noch hunderte von Einträgen in mein Log.

2019.12.18 18:12:13 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_231, please define it
2019.12.18 18:13:55 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_191, please define it
2019.12.18 18:19:15 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_175, please define it
2019.12.18 18:21:01 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_159, please define it
2019.12.18 18:23:21 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_254, please define it
2019.12.18 18:23:26 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_167, please define it
2019.12.18 18:28:47 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_103, please define it
2019.12.18 18:31:30 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_159, please define it
2019.12.18 18:32:04 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_244, please define it
2019.12.18 18:32:40 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_159, please define it
2019.12.18 18:40:55 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_156, please define it
2019.12.18 18:41:39 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_39, please define it
2019.12.18 18:42:13 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_39, please define it


Wie bekomme ich das weg?

Verbose auf 2 hat schon einmal nicht funktioniert.

Konnte auch im Forum keine wirkliche Antwort finden.

Gruß Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 18 Dezember 2019, 20:16:34
ich nehme verbose 0. Und blacklist_IDs.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 18 Dezember 2019, 21:25:47
Zitat von: RaspII am 17 Dezember 2019, 22:53:27
wenn Du mir sagst was Du genau einstellen willst, kann ich Dir evt. weiterhelfen.
Aktueller Ansatz:
Sender-Chip: TDK5110
Empfänger: TDA5210

Das Signal besteht aus 8 Bytes: 8 Bytes Vorspann (Random-Muster für dpro Tastendruck), 8 Bytes Nutzlast (Rollade, Funktion, Fernbedienung).

P.S. ich habe einen SDR-Stick, kann also das Signale von Fernbedienung und SIGNALduino in puncto Trägerfrequenz und Hub ver- bzw. abgleichen .
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 18 Dezember 2019, 21:37:23
Hallo Andies

Ich habe ja in der White List ( dann geht die Blacklist nicht) alle ID´s raus genommen die ich nicht benötige.
Leider kommen diese Meldungen wohl über die ID die meine Außensensoren nutzen und die kann ich ja nicht abschalten.

Ich versuche mal Verbose 0

Danke Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 18 Dezember 2019, 21:43:22
Trotz Verbose 0 kommen die Meldungen trotzdem.

Das war es also nicht.

Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 Dezember 2019, 00:44:15
Zitat von: Floh22964 am 18 Dezember 2019, 21:43:22
Trotz Verbose 0 kommen die Meldungen trotzdem.

Das war es also nicht.

Kay

Schick uns doch mal bitte ein List von deinem SIGNALduino.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sirko42 am 19 Dezember 2019, 10:57:42
Hallo,

ist es möglich, den Technoline TX29DHT-IT 868MHz Temp/Feuchte Außensensor mit dem Signalduino zu empfangen? Mein erster Versuch ist leider fehlgeschlagen. Es wurde nichts im Log angezeigt.
Der Signalduino empfängt aktuell eine CTW-601(WH1080) mit Protokoll 9 und einen alten TX4-868 Außensensor mit Protokoll 8. Leider scheint der TX29DHT-IT ein anderes LaCrosse Protokoll zu verwenden.

Gibt es einen Technoline Außensensor auf 868MHz, der über das Protokoll 8 dekodiert werden kann? Der TX4-868 ist ja leider nicht mehr erhältlich.

Hier noch Informationen zur aktuellen Konfiguration:
ccconf -> freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
version -> V 3.3.1-RC10 SIGNALduino cc1101 - compiled at Dec 29 2018 01:43:10

Aktuell ist die Whitelist für Protokoll 8 und 9 aktiviert, beim Empfangsversuch des TX29 war sie aber deaktiviert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 19 Dezember 2019, 11:20:35
Hallo @sirko42,

Zitat von: sirko42 am 19 Dezember 2019, 10:57:42
Hallo,

ist es möglich, den Technoline TX29DHT-IT 868MHz Temp/Feuchte Außensensor mit dem Signalduino zu empfangen? Mein erster Versuch ist leider fehlgeschlagen. Es wurde nichts im
Log angezeigt.

....

Aktuell ist die Whitelist für Protokoll 8 und 9 aktiviert, beim Empfangsversuch des TX29 war sie aber deaktiviert.

derzeit versuchen sich ein paar Leute daran, das über den SIGNALduino zu decodieren.
Dazu musst du dein Register vom CC1101 umkonfigurieren wenn du den SIGNALduino derzeit im Standardbetrieb nutzt.
Modulation:ASK/OOK

Die Sensoren welche du decodieren willst, wie der TX29DHT senden auf
Modulation:2-FSK

Da aber nicht nur die Modulation angepasst werden muss und vermutlich auch die Firmware, so ist es derzeit noch nicht möglich.

Die Nachfrage der anderen Modulationsart(en) steigt und so können wir nur testen bzw. alle bestmöglich zusammen es erarbeiten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 19 Dezember 2019, 11:29:23
Hallo @plin,

Zitat von: plin am 17 Dezember 2019, 22:13:21
Mich interessiert immer noch die Frage wieviele der internen CC1101-Register abzuändern sind damit er GFSK oder 2FSK versteht und spricht. Ich bin damals mit meiner OOK-Oberwelle recht weit gekommen, habe also eigentlich eine recht gute Startposition. Eigentlich braucht der SIGNALduino nur einen kleinen FSK-Schubs...

Beste Vorgehensweise:

- Smart RF STudio von TI besorgen (kannst du kostenlos herunterladen nach Registrierung)
- via SIGNALduino command ccreg 99 alle auslesen
- diese kannst du dann im Smart RF STudio eingeben
- deine Bedürfnisse verstellen in der Software und schon siehst du rechts im Fenster welches Register verstellt wird.

Hier kannst du Beispiele des Registers entnehmen für eine Modulation:2-FSK.  (https://github.com/RFD-FHEM/RFFHEM/issues/726)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: sirko42 am 19 Dezember 2019, 12:31:19
Hallo HomeAuto_User,

vielen Dank für die Info.
Da ich mit dem selben Signalduino parallel auch den Kombisensor CWT-601/WH1080 empfangen muß, kann ich vermutlich die Modulationsart des Signalduino nicht ändern, oder?
Der alte Außensensor TX4-868 von der Wetterstation WS868015 wird ja z.Zt. mit der Standardkonfiguration und Protokoll 8 (Lacrosse TX3) dekodiert. Deshalb hatte ich die Hoffnung, daß jemand einen Sensor aus dem aktuellen Angebot von Technoline/LaCrosse kennt, der ebenfalls mit dieser Konfiguration empfangen werden könnte.
Ich hatte zu Testzwecken auch schon einen ASH2200, natürlich mit anderem Protokoll, mit dem Signalduino empfangen. Aber auch diese Sensoren sind leider nicht mehr erhältlich. Einen Jeelink wollte ich nach Möglichkeit vermeiden, da der Raspi mit wenig Platz- und Energiebedarf betrieben werden soll.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 19 Dezember 2019, 16:09:26
Hallo Sidney

Gerade erst gesehen, hier das list



Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9K3FPTL-if00-port0
   DMSG       s13B05B4000
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9K3FPTL-if00-port0@57600
   FD         11
   FUUID      5df62068-f33f-adce-f713-b1bbe13c874f4795
   FVERSION   00_SIGNALduino.pm:v3.4.1-s10488/2019-12-06
   ITClock    250
   LASTDMSG   s13B05B4000
   LASTDMSGID 0.1
   MSGCNT     19480
   NAME       Signalduino
   NR         196
   NR_CMD_LAST_H 3
   PARTIAL   
   RAWMSG     MS;P0=-4608;P1=389;P2=-9882;P4=-2058;D=1214141410141410101014101014141414141014101014101014101414;CP=1;SP=2;R=20;O;m1;
   RSSI       -64
   STATE      opened
   TIME       1576767848.16631
   TYPE       SIGNALduino
   hasCC1101  1
   sendworking 0
   unknownmessages
   version    V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
   versionProtocols 1.10
   versionmodul v3.4.1-dev
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-12-18 12:56:45   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:ASK/OOK)
     2019-12-17 08:15:37   ccreg           C3E = 00 84 00 00 00 00 00 00
     2019-12-16 19:53:47   state           opened
     2019-12-16 19:53:47   version         V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
   XMIT_TIME:
     1576749600.30184
     1576749660.46373
     1576749720.63324
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     43
   msIdList:
     0.1
     87
   muIdList:
Attributes:
   DbLogExclude .*
   development 1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   room       Verwaltung -> Server
   updateChannelFW testing
   whitelist_IDs 0.1,43,87


Ichhabe das autocreate wieder eingeschaltet und er hat mit natürlich 20 Geräte angelegt die mir nicht gehören.

Momentan sind es noch diese die den Log vollmüllen

2019.12.19 12:01:52 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_63, please define it
2019.12.19 12:02:38 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_44, please define it
2019.12.19 12:03:12 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_76, please define it
2019.12.19 12:33:01 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_248, please define it
2019.12.19 12:48:22 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_103, please define it
2019.12.19 13:17:29 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_204, please define it
2019.12.19 14:23:40 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_158, please define it
2019.12.19 14:41:03 2: Signalduino: CUL_TCM97001 Unknown device CUL_TCM97001_236, please define it


Gruß Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 19 Dezember 2019, 16:27:14
Hallo Kay,
nimm bitte aus deiner whitelist die 0.1 testweise heraus.

Ich vermute, du hast einen Sensor, deswegen hast du die 0.1 aktiv. Leider sind die Sensoren in deiner Umgebung ebenso im der Definition deswegen wirst du die Meldung nicht los.

Möglichkeit, mit dem Attribut ignore arbeiten, autocreate höher drehen.

Verifiziere dies mal,
Liebe Grüße


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 19 Dezember 2019, 16:42:50
Hallo HomeAuto_User

Wie bekomme ich dann aber meine Beiden Sensoren wieder angezeigt?

Ich werde die 0.1 mal test weise abschalten.

Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 Dezember 2019, 18:07:48
Zitat von: Floh22964 am 19 Dezember 2019, 16:42:50
Wie bekomme ich dann aber meine Beiden Sensoren wieder angezeigt?

Ich werde die 0.1 mal test weise abschalten.
Wenn Du die 0.1 deaktivierst, dann wirst Du höchstwahrscheinlich deinen Außensensor nicht mehr empfangen.

Die Logmeldungen kommen aus dem Modul 14_CUL_TCM97001.pm.
Am besten Du schilderst im Forum Sonstiges dein Problem mit den Logmeldungen und bittest den Maintainer um eine Anpassung.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Floh22964 am 19 Dezember 2019, 20:35:32
Danke für Deine Hilfe, habe es bei sonstiges eingestellt.

Kay
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: plin am 20 Dezember 2019, 12:11:47
Zitat von: HomeAuto_User am 19 Dezember 2019, 11:29:23
Hallo @plin,

Beste Vorgehensweise:

- Smart RF STudio von TI besorgen (kannst du kostenlos herunterladen nach Registrierung)
- via SIGNALduino command ccreg 99 alle auslesen
- diese kannst du dann im Smart RF STudio eingeben
- deine Bedürfnisse verstellen in der Software und schon siehst du rechts im Fenster welches Register verstellt wird.

Hier kannst du Beispiele des Registers entnehmen für eine Modulation:2-FSK.  (https://github.com/RFD-FHEM/RFFHEM/issues/726)
Hi HomeAuto_User,
das RF Studio habe ich mir bereits vor einiger Zeit installiert und einige Kombinationen durchgespielt. Mittels Script schieße ich die CC1101-Register via SIGNALduino um, habe aber bisher noch nicht den Durchbruch erreicht. Bei keinem der Tests könnte die ich Fernbedienungssignale empfangen oder halbwegs passend aussehende Frequenzen (geschweige denn Signale) senden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dad401 am 23 Dezember 2019, 17:09:57
Ich kompiliere mir hier gerade Signalduino für meinen Mini 3.3V selbst. Unter Verwendung von MiniCore (https://github.com/MCUdude/MiniCore) bekomme ich folgenden Fehler:
Arduino: 1.8.10 (Windows 7), Board: "ATmega328, Yes (UART0), 328P / 328PA, BOD 2.7V, LTO disabled, 8 MHz external"

C:\Users\Marcus\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino: In function 'size_t writeCallback(const uint8_t*, uint8_t)':

SIGNALDuino:212:57: error: default argument given for parameter 2 of 'size_t writeCallback(const uint8_t*, uint8_t)' [-fpermissive]

size_t writeCallback(const uint8_t *buf, uint8_t len = 1)

                                                         ^

C:\Users\Marcus\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino:60:8: note: previous specification in 'size_t writeCallback(const uint8_t*, uint8_t)' here

size_t writeCallback(const uint8_t *buf, uint8_t len = 1);

        ^~~~~~~~~~~~~

Multiple libraries were found for "EEPROM.h"
Used: C:\Users\Marcus\AppData\Local\Arduino15\packages\MiniCore\hardware\avr\2.0.3\libraries\EEPROM
Multiple libraries were found for "IRremote.h"
Used: C:\Users\Marcus\Documents\Arduino\libraries\IRremote
exit status 1
default argument given for parameter 2 of 'size_t writeCallback(const uint8_t*, uint8_t)' [-fpermissive]

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.


Lösung (evtl. kann das jemand einchecken, wenn das korrekt ist):
In der Definition der Funktion "writeCallback" muss der Defaultparameter entfernt werden, da er bereits bei der Deklaration angegeben ist:
size_t writeCallback(const uint8_t *buf, uint8_t len)

Hier ist das gut erklärt (https://www.reddit.com/r/learnprogramming/comments/2f6wux/c_default_parameter_values_error_in_compilation/).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 23 Dezember 2019, 19:15:35
Danke für den Hinweis. Ich werde es anpassen.

Gesendet von meinem Moto Z (2) mit Tapatalk

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 24 Dezember 2019, 18:56:37
Frohe Weihnachten Euch allen


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Kawaci am 27 März 2020, 11:35:28
Hallo!
Ich habe sensignalesp mit Demos d1 mini mit cc1101!
Zum steuern meiner somfy ras Markise, die Steuerung läuft über fhem kein problem! Jetzt wollte ich den Hnadsender auch hinzufügen aber in autocreate wird kein gerät angelegt!

Hier ein list des sduino

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        192.168.178.33:23
   DMSG       Ys5644C1BA412733
   DevState   initialized
   DeviceName 192.168.178.33:23
   FD         36
   FUUID      5c4ffa50-f33f-f967-bdb1-f5f187dcbff9e4ec
   LASTDMSG   Ys5644C1BA412733
   LASTDMSGID 43
   MSGCNT     898
   NAME       sduino
   NR         41
   PARTIAL   
   RAWMSG     MC;LL=-1329;LH=1233;SL=-687;SH=597;D=5644C1BA412733;C=640;L=56;R=40;
   RSSI       -54
   STATE      opened
   TIME       1585304928
   TYPE       SIGNALduino
   hasCC1101  1
   sendworking 0
   unknownmessages 2020-03-27 10:49:49-MC;LL=-1282;LH=1234;SL=-651;SH=617;D=0004D;C=630;L=20;R=233;#2020-03-27 10:49:49-MC;LL=-1288;LH=1244;SL=-657;SH=620;D=2800B0;C=634;L=23;R=213;#2020-03-27 10:49:49-MU;P0=2473;P1=-2524;P2=4783;P3=-1293;P4=1245;P5=-632;P6=622;P7=-113;D=01010101010101010101012343456565656563456343456;CP=0;R=236;#2020-03-27 10:49:49-MC;LL=-1288;LH=1239;SL=-674;SH=573;D=0D7908C2000E8;C=628;L=49;R=236;#2020-03-27 10:49:50-MU;P0=606;P1=-654;P2=-1287;P3=1246;P4=-2524;P5=2471;P6=4780;P7=-119;D=01010101010231010234545454545454623231010101010;CP=0;R=236;#2020-03-27 10:49:50-MC;LL=-1298;LH=1252;SL=-655;SH=612;D=1AF21190004D;C=636;L=48;R=235;#2020-03-27 10:53:54-MC;LL=-1339;LH=1242;SL=-685;SH=591;D=AA8A806;C=642;L=28;R=240;#2020-03-27 10:53:55-MC;LL=-1347;LH=1211;SL=-696;SH=587;D=DD582B0;C=640;L=25;R=249;#2020-03-27 10:54:00-MC;LL=-1334;LH=1233;SL=-685;SH=582;D=EB03F53911;C=638;L=40;R=14;#2020-03-27 10:54:01-MU;P0=604;P1=-681;P2=-1328;P3=1237;P4=-17499;P5=2452;P6=-2564;P7=4748;D=2345656723232010132320132320132010101010132;CP=0;R=18;#2020-03-27 10:54:01-MC;LL=-1329;LH=1237;SL=-677;SH=610;D=D40D888;C=642;L=26;R=19;#2020-03-27 11:00:55-MC;LL=-1340;LH=1235;SL=-698;SH=562;D=5026A6A;C=639;L=28;R=220;#2020-03-27 11:00:55-MC;LL=-1335;LH=1209;SL=-673;SH=601;D=CBF321000;C=636;L=36;R=216;#2020-03-27 11:00:55-MC;LL=-1321;LH=1212;SL=-683;SH=584;D=5026A0;C=633;L=21;R=216;#2020-03-27 11:00:56-MC;LL=-1318;LH=1209;SL=-685;SH=584;D=4DBB2;C=632;L=20;R=216;#2020-03-27 11:00:56-MC;LL=-1328;LH=1209;SL=-675;SH=575;D=900048;C=631;L=21;R=217;#2020-03-27 11:00:56-MC;LL=-1324;LH=1212;SL=-692;SH=576;D=A04D4D4C;C=633;L=31;R=215;#2020-03-27 11:00:59-MU;P0=-288;P1=116;P2=568;P3=-700;P4=-1322;P5=1195;P6=-102;P7=170;D=42323542353245370162323232323532423532453;CP=2;R=214;#2020-03-27 11:01:00-MU;P0=244;P1=1202;P2=-686;P3=582;P4=-1331;P5=-2574;P6=2433;P7=4720;D=123234156565656565657414123232323234123400;CP=3;R=213;#2020-03-27 11:01:00-MC;LL=-1339;LH=1126;SL=-710;SH=538;D=5F99180;C=618;L=25;R=215;#2020-03-27 11:01:00-MC;LL=-1324;LH=1208;SL=-698;SH=568;D=A04D4D4C;C=632;L=30;R=215;#2020-03-27 11:04:47-MC;LL=-1287;LH=1239;SL=-671;SH=607;D=502525250D0;C=633;L=41;R=238;#2020-03-27 11:04:47-MC;LL=-1298;LH=1235;SL=-648;SH=617;D=C846200088;C=632;L=38;R=238;#2020-03-27 11:04:47-MC;LL=-1271;LH=1246;SL=-668;SH=606;D=F21190004C;C=631;L=39;R=238;#2020-03-27 11:04:50-MC;LL=-1302;LH=1238;SL=-676;SH=569;D=5E42318006E;C=630;L=43;R=238;
   version    V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:45:03
   versionProtocols 1.10
   versionmodul v3.4.1
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2020-03-27 00:11:50   ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:8dB  (DataRate:5603.79Baud)
     2020-03-22 18:28:39   ccpatable       C3E = 00 C8 00 00 00 00 00 00  => 7_dBm
     2020-03-22 18:28:07   cmds            V R t X F S P C r W x e
     2020-03-22 18:21:43   config          MS=1;MU=1;MC=1
     2020-03-22 18:27:44   freeram         36880
     2020-03-27 11:30:42   ping            OK
     2019-01-29 08:27:27   raw             Unsupported command -> 0x73 s
     2020-03-27 11:22:42   state           opened
     2020-03-27 11:22:42   version         V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:45:03
   getcmd:
   helper:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     23
     25
     33
     33.1
     33.2
     35
     41
     51
     53
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
Attributes:
   alias      sduino
   devStateIcon opened:WLAN_Status.1 disconnected:WLAN_Status.0
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      Gateway
   hardware   nanoCC1101
   longids    1
   room       Gateways
   verbose    5
   whitelist_IDs 0,0.1,0.2,0.3,0.4,1,3,3.1,4,6,7,8,9,10,11,12,13,13.1,13.2,14,15,16,17,17.1,18,19,21,22,23,24,25,26,27,28,29,30,31,32,33,33.1,33.2,34,35,36,37,38,39,40,41,42,43,44,44.1,45,46,47,48,49,50,51,52,53,55,56,57,58,59,60,61,62,64,65,66,67,68,69,70,71,72,73,74,74.1,76,79,80,81,83,84,85,86,87,88,89,90,91,91.1,92,93,94,95,96


Und hier einen Auszug aus dem Logfile wenn ich eine Taste am Handsender drücke!

2020.03.27 11:32:33 4: sduino: Somfy bitdata: 010100000010011010100110101001101101110110010111111001100100011000000000000110111000 (81)
2020.03.27 11:32:33 5: sduino: Dispatch, Ys5026A6A6DD97E646001B8, test ungleich: disabled
2020.03.27 11:32:33 5: sduino: Dispatch, Ys5026A6A6DD97E646001B8, -94.5 dB, dispatch
2020.03.27 11:32:33 5: sduino: dispatch Ys5026A6A6DD97E646001B8
2020.03.27 11:32:33 1: ERROR: >Somfy RTS checksum error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer
2020.03.27 11:32:33 4: sduino: Parse_MC, Found manchester Protocol id 52 clock 635 RSSI -94.5 -> Oregon Scientific PIR
2020.03.27 11:32:33 5: sduino: Parse_MC, extracted data 101011111101100101011001010110010010001001101000000110011011100111111111111001000111 (bin)
2020.03.27 11:32:33 5: sduino: Parse_MC, protocol does not match return from method: ( header not found)
2020.03.27 11:32:33 4: sduino: Read, msg: MC;LL=-1333;LH=1205;SL=-683;SH=589;D=5026A6A6DD97E64800268;C=634;L=81;R=215;
2020.03.27 11:32:33 4: sduino: Parse_MC, Found manchester Protocol id 43 clock 634 RSSI -94.5 -> Somfy RTS
2020.03.27 11:32:33 5: sduino: Parse_MC, extracted data 010100000010011010100110101001101101110110010111111001100100100000000000001001101000 (bin)
2020.03.27 11:32:33 4: sduino: Somfy bitdata: 010100000010011010100110101001101101110110010111111001100100100000000000001001101000 (81)
2020.03.27 11:32:33 5: sduino: Dispatch, Ys5026A6A6DD97E64800268, test ungleich: disabled
2020.03.27 11:32:33 5: sduino: Dispatch, Ys5026A6A6DD97E64800268, -94.5 dB, dispatch
2020.03.27 11:32:33 5: sduino: dispatch Ys5026A6A6DD97E64800268
2020.03.27 11:32:33 1: ERROR: >Somfy RTS checksum error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer
2020.03.27 11:32:33 4: sduino: Parse_MC, Found manchester Protocol id 52 clock 634 RSSI -94.5 -> Oregon Scientific PIR
2020.03.27 11:32:33 5: sduino: Parse_MC, extracted data 101011111101100101011001010110010010001001101000000110011011011111111111110110010111 (bin)
2020.03.27 11:32:33 5: sduino: Parse_MC, protocol does not match return


Ich hab eigentlich nur den somfy Rts auf dem signalesp laufen! Mehr brauch ich nicht!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 09:56:02
Gute morgen:

Ich habe heute morgen aus versehen auf
set cc1101_bWidth 58
geklickt  :'(
Danach wieder auf 325khz gestellt.
Seitdem arbeitet mein Singnalduino nicht mehr (opened aber kein senden und empfangen).
Ich vermute das es an der Bautrate liegt finde aber nirgends wo man die einstelle kann.


Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04VD89-if00-port0@57600
DMSG nothing
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04VD89-if00-port0@57600
FD 11
FUUID 5e902876-f33f-e88a-a189-8780189787e02bcf
LASTDMSG nothing
LASTDMSGID nothing
NAME SIGNALduino433
NR 33
PARTIAL
STATE opened
TIME 1586505846
TYPE SIGNALduino
cc1101_available 1
sendworking 0
version V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
versionProtocols 1.17
versionmodul v3.4.2



cc1101_config Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 350.24 Baud
cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
cc1101_patable C3E = 00 60 00 00 00 00 00 00 => 0_dBm
config MS=1;MU=1;MC=1;Mred=1
ping OK
state opened



hardware nanoCC1101
updateChannelFW stable
whitelist_IDs 17.1,51,58
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 10 April 2020, 10:15:55
Die Datenrate kannst Du leider nur durch setzten der Register einstellen.
Komisch ist, dass die verstellt wurde.
Mit welcher Version des Moduls trat dieses Verhalten denn auf?

Am einfachsten kannst Du den SIGNALduino wieder auf Werkseinstellungen durch set raw e setzen.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 10:24:22
Ich weis nicht ob diese verstellt wurde. Aber das ist meine letzte Erklärung.
Alle andere Parameter habe ich neu gesetzt.

Reset mit raw e habe ich schon probiert.
Neu geflasht, neu gestartet (Raspberry und FHEM) alles upgedatet. Device gelöscht und neu angelegt.
USB-ID im Linux geprüft.
Nix zu machen.

versionmodul v3.4.2
version V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 10:47:47
bitte setze mal das Attribut verbose vom SIGNALduino433 auf 4
und dann ein
get SIGNALduino433 raw C99
get SIGNALduino433 raw e
get SIGNALduino433 raw C99
get SIGNALduino433 ccconf


und poste dann diesen log

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 10:54:38

2020.04.10 10:52:40 3: SIGNALduino433: Attr, setting Verbose to: 4
2020.04.10 10:53:13 4: SIGNALduino433: KeepAlive, ok, retry = 0
2020.04.10 10:53:26 4: SIGNALduino433: Read, msg READredu: MU;P0=-1682;P1=679;P2=-3814;P3=375;P4=-2232;P5=1005;P7=-15584;D=01010123232343210103010101030123210101052125210321210303212525010525050121057;CP=1;R=244;
2020.04.10 10:53:26 4: SIGNALduino433: Read, msg READredu: MU;P0=-1921;P1=1015;P2=-1368;P3=339;P4=-8100;P5=-3915;P6=696;D=34356560606015356560656060606060106065656012603;CP=6;R=241;
2020.04.10 10:53:26 4: SIGNALduino433: Read, msg READredu: MU;P0=-2036;P1=-7320;P2=1068;P3=373;P5=-3983;P7=696;D=3135353030707575753035353535313530303035353530353570303575352;CP=3;R=246;
2020.04.10 10:53:27 4: SIGNALduino433: Read, msg READredu: MU;P0=1065;P1=-1712;P3=1444;P4=-1049;P6=679;P7=-3918;D=6767016161676767010701343434343434076761616167;CP=6;R=241;
2020.04.10 10:53:30 4: SIGNALduino433: HandleWriteQueue, called
2020.04.10 10:53:30 4: SIGNALduino433: SendFromQueue, called
2020.04.10 10:53:30 4: SIGNALduino433: Read, msg: C0Dn11=10B07153C43023B900070018146C070091
2020.04.10 10:53:31 4: SIGNALduino433: HandleWriteQueue, called
2020.04.10 10:53:31 4: SIGNALduino433: HandleWriteQueue, nothing to send, stopping timer
2020.04.10 10:53:36 4: SIGNALduino433: Read, msg READredu: MU;P0=-3859;P1=-1758;P2=1068;P4=714;P5=-8104;P6=378;D=45616060416140416040616020412141214120404161402141404041414141606040416141414140404;CP=4;R=232;
2020.04.10 10:53:36 4: SIGNALduino433: Read, msg READredu: MS;P0=-1611;P1=-3841;P4=1041;P5=-6978;P6=693;P7=382;D=657570716071717071616040404060616160607160606141604040606161613;CP=6;SP=5;R=231;
2020.04.10 10:53:36 4: SIGNALduino433: Read, msg READredu: MU;P0=-3973;P1=677;P2=-1700;P3=1470;P4=-23660;P5=366;P6=-6761;P7=-11528;D=3456575650125052525050525256525050121212121010101212;CP=5;R=232;
2020.04.10 10:53:37 4: SIGNALduino433: Read, msg READredu: MU;P0=350;P1=-1604;P2=727;P4=1090;P5=-3477;P6=-2364;P7=-16016;D=012145412525212525212121212125052121254121252521412141254545410607274;CP=2;R=230;
2020.04.10 10:53:37 4: SIGNALduino433: Read, msg READredu: MU;P0=-6268;P1=1072;P2=-3955;P3=719;P4=-1879;P5=376;P6=-8724;D=01234345434545252523234545634543454523252343454345432323;CP=5;R=231;
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 10 April 2020, 11:09:07
Zitat von: Ralf9 am 10 April 2020, 10:47:47
bitte setze mal das Attribut verbose vom SIGNALduino433 auf 4
und dann ein
get SIGNALduino433 raw C99
get SIGNALduino433 raw e
get SIGNALduino433 raw C99
get SIGNALduino433 ccconf


Bist du dir sicher, das das funktioniert? Ein
get SIGNALduino433 raw C99
bewirkt hier nichts. Besser wäre
get SIGNALduino433 ccreg 99

Auch
get SIGNALduino433 raw e
bewirkt hier nichts. Besser wäre
set SIGNALduino433 raw e
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 10 April 2020, 11:13:40
Hi,
bei den raw Befehlen ist get und set eigentlich egal, ausser das bei get ein Dialog die Antwort zeigt.
Mit verbose 4 oder 5 stehen die Infos hinterher sowieso im Log ;-)
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 11:17:08
Danke Leute!
Ich habe das ganze jetzt nochmal mit SET Raw gemacht und jetzt ist die Datenrate wieder bei:
Freq: 17.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
Warum die Frequenz allerdings bei 17.920Mhz steht weiß ich nicht. Hab die wieder auf 433.920 gesetzt.
Jedenfall funktioniert alles wieder! :)
War kurz vorm Herzinfarkt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 11:23:58
ZitatBist du dir sicher, das das funktioniert? Ein
wenn das "get sduino raw" mit dem aktuellen 00_Signalduino Modul nicht mehr funktioniert, dann habt Ihr da noch ein Bug drin.

Wie Arnd schon geschrieben hat, hat das get raw den Vorteil, daß die Antwort in einem Dialogfenster ausgegeben wird.

Gruß Ralf

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 11:33:58
Das freut mich wenn mein "verklicken" einen Fehler in der Firmware aufgedeckt haben sollte.
Dann war mein Stress am Vormittag doch nicht ganz umsonst. :D
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 12:29:36
Nein der Bug ist im aktuellen Fhem Modul.

Bitte mach mal ca 10-20 mal ein "get ccconf" und schaue dann ob die ausgegebe Frequenz und Datarate immer gleich ist

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 10 April 2020, 12:34:16
Hallo,

Zitat von: Ralf9 am 10 April 2020, 11:23:58
wenn das "get sduino raw" mit dem aktuellen 00_Signalduino Modul nicht mehr funktioniert, dann habt Ihr da noch ein Bug drin.

Wie Arnd schon geschrieben hat, hat das get raw den Vorteil, daß die Antwort in einem Dialogfenster ausgegeben wird.

Gruß Ralf

EINSPRUCH und Bedienfehler mit Sicherheit. Soeben frisch getestet.
Etwas verstellt und die Standardeinstellungen kamen zurück.

Im Modul
00_SIGNALduino.pm      21620 2020-04-07 21:20:33Z Sidey
funktioniert der Befehl

set [name] raw e
&
get [name] raw MS;P0=-9298;P1=495;P2=-1980;P3=-4239;D=1012121312131313121313121312121212121212131212131312131212;CP=1;SP=0;R=223;O;m2;


@Ralf, @dsoxygen, nein das ist kein Fehler im Modul.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 12:39:25
Zitat von: Ralf9 am 10 April 2020, 12:29:36
Nein der Bug ist im aktuellen Fhem Modul.

Bitte mach mal ca 10-20 mal ein "get ccconf" und schaue dann ob die ausgegebe Frequenz und Datarate immer gleich ist

Gruß Ralf

4 mal gemacht. Ab dem dritten mal stand 17.920Mhz.
X-male später kam wieder 433.920Mhz.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 12:42:11
ZitatEINSPRUCH und Bedienfehler mit Sicherheit. Soeben frisch getestet.
ich meinte nicht set sondern z.B
get raw e
get raw C99
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 10 April 2020, 12:42:22
Zitat von: dsoxygen am 10 April 2020, 12:39:25
4 mal gemacht. Ab dem dritten mal stand 17.9200Mhz.

@dsoxygen

Wenn du die Version
00_SIGNALduino.pm      21620 2020-04-07 21:20:33Z Sidey
besitzt, werden deine Readings
cc1101_config
cc1101_config_ext
nach einem FHEM RESTART neu gesetzt?

Das Rücksetzten der Register ist
set [name] raw e
nicht wie in der Commandref angezeigt bei get. Das ist falsch weil der "Link" in der Commandref sofort auf das erste "get" springt.

Das Verhalten wird wohl Anhand der Wiki als falsch definiert. Quelle: https://wiki.fhem.de/wiki/SIGNALduino
Fehlerbehandlung

Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:

    get raw e
als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

        get raw C<reg>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers. Example: C35 -> C35 = 0D
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 12:46:14
Zitat4 mal gemacht. Ab dem dritten mal stand 17.920Mhz.
X-male später kam wieder 433.920Mhz.

Der Fehler ist bekannt, ich schreibe dazu heute Abend mehr.
Jetzt gehe ich erst mal mit dem Rad raus das schöne Wetter genießen

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 12:50:27
Zitat von: HomeAuto_User am 10 April 2020, 12:42:22
@dsoxygen

Wenn du die Version
00_SIGNALduino.pm      21620 2020-04-07 21:20:33Z Sidey
besitzt, werden deine Readings
cc1101_config
cc1101_config_ext
nach einem FHEM RESTART neu gesetzt?

Das Rücksetzten der Register ist
set [name] raw e
nicht wie in der Commandref angezeigt bei get. Das ist falsch weil der "Link" in der Commandref sofort auf das erste "get" springt.

# $Id: 00_SIGNALduino.pm 21620 2020-04-07 21:20:33Z Sidey $
Wie bekomme ich raus ob die readings beim neustart neu gesetzt werden?
Und was hat das damit zu tun wenn ich die ccconf manuel abrufe und sich dabei die Freqenzanzeige ändert?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 10 April 2020, 12:59:14
Zitat von: dsoxygen am 10 April 2020, 12:50:27
# $Id: 00_SIGNALduino.pm 21620 2020-04-07 21:20:33Z Sidey $
Wie bekomme ich raus ob die readings beim neustart neu gesetzt werden?
Und was hat das damit zu tun wenn ich die ccconf manuel abrufe und sich dabei die Freqenzanzeige ändert?

In der Version
# $Id: 00_SIGNALduino.pm 21620 2020-04-07 21:20:33Z Sidey $

werden die aktuellen Einstellungen deiner Konfiguration bei jedem Neustart oder Reset gelesen.
Ob sich die Readings aktualisieren siehst du, indem du auf die Zeit schaust, FHEM neu startest und dann dir den Timestamp vom Reading ansiehst. (ggf. wird dieser auch rot).

Die Differenz bei den Tests ist noch deine Firmware.
Du nutzt soeben
# version V 3.3.1 SIGNALduino cc1101 (chip CC1101) #
wo es schon eine aktuelle gibt im dev.

Ob es dort Inkompatiblitäten zum Modul gibt, kann ich derzeit nicht auf die Schnelle testen. Da muss auf jedenfall ein Auge drauf gewurfen werden.

Fakt derzeit, es gibt im Wiki genannt Optionen welche nicht mit deiner Konstelation ausführbar sind.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 13:06:44
Zitat von: HomeAuto_User am 10 April 2020, 12:59:14
Ob sich die Readings aktualisieren siehst du, indem du auf die Zeit schaust, FHEM neu startest und dann dir den Timestamp vom Reading ansiehst. (ggf. wird dieser auch rot).

Ja.
Nach einem "shutdown restart" sind die readings:

cc1101_config
cc1101_config_ext
cc1101_patable
state

mit aktuellen Zeitstempel versehen also upgedated.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 10 April 2020, 13:08:15
Zitat von: dsoxygen am 10 April 2020, 13:06:44
Ja.
Nach einem "shutdown restart" sind die readings:

cc1101_config
cc1101_config_ext
cc1101_patable
state

mit aktuellen Zeitstempel versehen also upgedated.

Das ersetzt das manuelle Abrufen von ccconf und dort sollten die "Livewerte" von dir nun drin stehen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 13:15:03
Zitat von: HomeAuto_User am 10 April 2020, 13:08:15
Das ersetzt das manuelle Abrufen von ccconf und dort sollten die "Livewerte" von dir nun drin stehen.

Ja. Das tut es.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 April 2020, 20:01:00
Zitat4 mal gemacht. Ab dem dritten mal stand 17.920Mhz.
X-male später kam wieder 433.920Mhz.

Was für eine Hardware verwendest Du für den sduino, selbstgebaut oder gekauft?
Bei unsauber aufgebauter Hardware kann es ab und zu passieren, daß durch timingprobleme falsche Werte aus den cc1101 Registern gelesen werden.
Ich habe hier auch so eine unsauber aufgebaute Hardware mit der ich das fehlerhafte lesen von cc1101 Registern nachvollziehen konnte.
   
Bei meiner firmware konnte ich dieses timing Problem fixen.
Die aktuelle firmware ist V 3.3.2.1-rc9
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: dsoxygen am 10 April 2020, 20:05:02
Zitat von: Ralf9 am 10 April 2020, 20:01:00
Was für eine Hardware verwendest Du für den sduino, selbstgebaut oder gekauft?

Eigenbau. Anscheinend unsauber. *heul*
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 April 2020, 10:40:58
Zitat von: Kawaci am 27 März 2020, 11:35:28
Zum steuern meiner somfy ras Markise, die Steuerung läuft über fhem kein problem! Jetzt wollte ich den Hnadsender auch hinzufügen aber in autocreate wird kein gerät angelegt!
ZitatRSSI -94.5
Du hast anscheinend recht schlechte Empfangsverhältnisse, dadurch wird der Anfang der Nachricht nicht richtig erkannt.

Ich habe bei mir mal in der 00_SIGNALduino.pm
in der "sub SIGNALduino_SomfyRTS()"
dies
if ($mcbitnum == 57) {
$bitData = substr($bitData, 1, 56);

abgeändert nach
if ($mcbitnum == 57 || $mcbitnum == 81) {
$bitData = substr($bitData, 1, $mcbitnum - 1);


und dann mit einem Dummysduino die MC-Nachricht von Dir simuliert, dann passt es

2020.04.11 10:25:53.230 4 : sduinoD/msg get raw: MC;LL=-1333;LH=1205;SL=-683;SH=589;D=5026A6A6DD97E64800268;C=634;L=81;R=215;
2020.04.11 10:25:53.230 4 : sduinoD: Found manchester Protocol id 43 clock 634 RSSI -94.5 -> Somfy RTS
2020.04.11 10:25:53.230 4 : sduinoD: Somfy bitdata: 010100000010011010100110101001101101110110010111111001100100100000000000001001101000 (81)
2020.04.11 10:25:53.230 4 : sduinoD: Somfy bitdata: _10100000010011010100110101001101101110110010111111001100100100000000000001001101 (80). Bit am Anfang entfernt
2020.04.11 10:25:53.230 4 : sduinoD Dispatch: YsA04D4D4DBB2FCC90004D, -94.5 dB, dispatch
2020.04.11 10:25:53.263 4 : sduinoD: Somfy RTS preprocessing check: D enc: A04D4D4DBB2FCC90004D(20) dec: A0ED0000F694E3
2020.04.11 10:25:53.263 1 : SOMFY Unknown device E394F6 (A0 0000), please define it


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 09:46:39
Guten Morgen zusammen und frohe Ostern!

Ich bin recht neu mit der Materie, versuche aber jetzt bereits seit Stunden und Tagen einen Eigenbau-Signalduino ans laufen zu bekommen.

Als Komponenten habe ich lediglich einen ESP8266 (NodeMCU 1.0) und einen Neuftech TI-CC1101.
Die Verkabelung habe ich wie hier vorgenommen:

https://wiki.fhem.de/wiki/SIGNALduino

Die Beschriftung war bei meinem CC1101 etwas anders. Ich habe die Kabel wie folgt verbunden:

Bezeichnung       ESP Pin
SCK/CLK               D5/GPIO14
SI/MOSI               D7/GPIO13
SO/MISO               D6/GPIO12
CSN                        D8/GPIO15
GDO0               D2/GPIO4
GDO2                   D1/GPIO5
VCC                     3V
GND                    G

Mein Aufbau besteht also nur aus den 2 Komponenten und 8 Kabeln.
Ich habe nun einmal versucht die fertig kompilierte Hex-Datei (SIGNALDuino_ESP8266cc11013.3.1) zu flashen
und einmal das Ganze mit der Arduino IDE selbst kompiliert und den ESP8266 geflashed. Das hat soweit auch beides funktioniert.
Beim selbst kompilieren habe ich nur in der "compile_config.h" die Zeile "#define OTHER_BOARD_WITH_CC1101  1" aktiviert.

Beim Neustart des ESP8266 hat er ein WIFI aufgemacht und ich konnte meine WiFi-Daten eingeben.

Wenn ich in der Konsole nun schaue, gibt der ESP folgende Daten aus:

Starting config portal with SSID: NodeDuinoConfig
*WM: [1] AutoConnect
*WM: [2] Connecting as wifi client...
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set
*WM: [3] WIFI station disconnect
scandone
*WM: [1] Connecting to SAVED AP: FRITZ!Box 7590 WO
*WM: [3] Using Password: x
*WM: [3] WiFi station enable
*WM: [3] enableSTA PERSISTENT ON
*WM: [1] connectTimeout not set, ESP waitForConnectResult...
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with FRITZ!Box 7590 WO, channel 6
dhcp client start...
ip:192.168.178.51,mask:255.255.255.0,gw:192.168.178.1
*WM: [2] Connection result: WL_CONNECTED
*WM: [3] lastconxresult: WL_CONNECTED
*WM: [1] AutoConnect: SUCCESS
*WM: [1] STA IP Address: 192.168.178.51
*WM: [1] Starting Web Portal
*WM: [3] dns server started with ip:
*WM: [2] HTTP server started
scandone
*WM: [2] WiFi Scan completed in 1588 ms


Und danach...nichts mehr.
Wenn ich den Befehl "?" an das Gerät sende, sollte ich dann nicht einen weiteren Output bekommen? Es passiert von hier an einfach nichts mehr.
Habe es über den Arduino Monitor versucht. Oder benötige ich ein anderes Tool?
Gesendete Befehle von meiner Remote scheint er auch nicht aufzuschnappen.
Ich möchte übrigens die Befehle von meiner Dooya (bzw. nobily) Fernbedienung empfangen und angezeigt bekommen.

Hat jemand eventuell eine Idee, woran es liegen könnte?
Ich danke euch jetzt schon!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 12 April 2020, 09:58:55
Hallo und frohe Ostern,

wenn du dir deine Software selbst kompilieren kannst, so aktiviere den Debugmodus um erstmal zu schauen ob du eine Verbindung zum deinem CC1101 erhältst. Wenn alles später funktioniert, so kannst du dies wieder deaktivieren. (Bin soeben nicht am Rechner um dir die Zeile zu benennen)

Liebe Grüße

Gesendet von iPhone mit Tapatalk Pro

EDIT:

ZitatAls Komponenten habe ich lediglich einen ESP8266 (NodeMCU 1.0) und einen Neuftech TI-CC1101.
Das funktioniert, das habe ich schon mehrfach in Betrieb genommen. (Voraussetzung Verkabelung stimmt)

Thema Verkabelung, wenn der Aufbau auf einem Breadboard gesteckt wurde, dann bitte alles durchmessen / testen.
Es gibt Boards, da ist der Übergangswiderstand sehr hoch und nicht "eindeutig". (Nachbauten aus Fernost)

Debug für serielle Ausgabe
//Enable debug option here:
#define DEBUG


bei aktiv, sieht es dann ca. so aus

CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
CCVersion =0x14
CCPartnum =0x0
cc1101 found
Starting timerjob


Solltest du denn noch Probleme haben, so kann ich dir gern eine compiliere FW zur Verfügung stellen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 April 2020, 10:04:13
Ich habe zwar kein SignalEsp.

Hast schon mal versucht den Esp anzupingen, dann kannst Du Dich testweise auch per Telnet verbinden.

Das Neuftech TI-CC1101 hat keinen genauen Quarz, es kann sein, daß Du, wenn alles funktioniert mit set bWith die Bandbreite erhöhen musst

Gruß Ralf

und frohe Ostern
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 10:44:35
Danke für die Rückmeldungen.
Habe den Debug-Modus mal eingeschaltet.
Bekomme tatsächlich
CCVersion =0xff
CCPartnum =0xff
no cc1101 found


Derzeit habe ich kein Breadboard dazwischen, sondern nur direkte Kabelverbindung.
Werde es mal mit Breadboard und anderen Kabeln testen.

Muss ich denn
#define CMP_CC1101 oder #define OTHER_BOARD_WITH_CC1101  1
für den ESP wählen? Werde mich gleich zurückmelden!

Achja und @Ralf9:
IP hat das Gerät. Via telnet bekomme ich "Command too long" und der ESP startet neu
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 12 April 2020, 11:02:04
ZitatVia telnet bekomme ich "Command too long" und der ESP startet neu
Danke für die Info, bei früheren Firmware Versionen hat es auch über Telnet funktioniert.
Da ist anscheinend an der aktuellen Firmware was nicht ganz sauber programmiert.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 11:23:31
Zitat von: HomeAuto_User am 12 April 2020, 09:58:55
Hallo und frohe Ostern,

wenn du dir deine Software selbst kompilieren kannst, so aktiviere den Debugmodus um erstmal zu schauen ob du eine Verbindung zum deinem CC1101 erhältst. Wenn alles später funktioniert, so kannst du dies wieder deaktivieren. (Bin soeben nicht am Rechner um dir die Zeile zu benennen)

Liebe Grüße

Gesendet von iPhone mit Tapatalk Pro

EDIT:
Das funktioniert, das habe ich schon mehrfach in Betrieb genommen. (Voraussetzung Verkabelung stimmt)

Thema Verkabelung, wenn der Aufbau auf einem Breadboard gesteckt wurde, dann bitte alles durchmessen / testen.
Es gibt Boards, da ist der Übergangswiderstand sehr hoch und nicht "eindeutig". (Nachbauten aus Fernost)

Debug für serielle Ausgabe
//Enable debug option here:
#define DEBUG


bei aktiv, sieht es dann ca. so aus

CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
CCVersion =0x14
CCPartnum =0x0
cc1101 found
Starting timerjob


Solltest du denn noch Probleme haben, so kann ich dir gern eine compiliere FW zur Verfügung stellen.

Ich bin jetzt ein kleines Stückchen weiter.
Ich habe mit einem Multimeter alle Verbindungen geprüft und alle waren korrekt.
Dann habe ich den ESP8266 ausgetauscht und nun scheint er den CC1101 zu finden.
Trotzdem bekomme ich: 01: Setting RX failed

connected with FRITZ!Box 7590 WO, channel 1
dhcp client start...
ip:192.168.178.47,mask:255.255.255.0,gw:192.168.178.1
Reading values from EEPROM..done
dump
EEPROM=33 1d 0d 2e 2d 47 d3 91 3d 04 32 00 00 06 00 10
b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00 91
87 6b f8 b6 11 e9 2a 00 1f 41 00 ff ff ff ff ff
00 84 00 00 00 00 00 00
CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
01: Setting RX failed
CCVersion =0x14
CCPartnum =0x0
cc1101 found
mounting FS...
Starting config portal with SSID: NodeDuinoConfig
*WM: [1] AutoConnect
*WM: [1] AutoConnect: ESP Already Connected
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set
*WM: [1] AutoConnect: SUCCESS
*WM: [1] STA IP Address: 192.168.178.47
cc1101 _PKTCTRL0=50 vs initval PKTCTRL0=50
cc1101 _IOCFG2=13 vs initval IOCFG2=13
receiver enabled*WM: [1] Starting Web Portal
*WM: [3] dns server started with ip:
*WM: [2] HTTP server started
scandone
*WM: [2] WiFi Scan completed in 1583 ms
pm open,type:2 0


PS:
Ich bekomme bei telnet immernoch "Command to long", aber wenn ich etwas eingebe, dann kommt es zumindest beim ESP an (und dieser stürzt anschließend ab)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 12 April 2020, 11:24:15
Zitat von: Ralf9 am 12 April 2020, 11:02:04
Da ist anscheinend an der aktuellen Firmware was nicht ganz sauber programmiert.

::) ::) ::) ::)

Zitat von: zod am 12 April 2020, 10:44:35
Via telnet bekomme ich "Command too long" und der ESP startet neu

Was hast du genau gemacht und was für ein Command hast du gesendet?

Zitat von: zod am 12 April 2020, 10:44:35

Muss ich denn
#define CMP_CC1101 oder #define OTHER_BOARD_WITH_CC1101  1
für den ESP wählen? Werde mich gleich zurückmelden!

Mit den Einstellungen:
// Config flags for compiling correct options / boards Define only one!
//#define CMP_CC1101
//#define ARDUINO_ATMEGA328P_MINICUL 1
//#define ARDUINO_AVR_ICT_BOARDS_ICT_BOARDS_AVR_RADINOCC1101 1;
#define OTHER_BOARD_WITH_CC1101  1


//Enable debug option here:
#define DEBUG


habe ich soeben es getestet und sofort erscheint

Reading values from EEPROM..done
dump
EEPROM=33 1d 0d 2e 2d 47 d3 91 3d 04 32 00 00 06 00 10
b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00 91
87 6b f8 b6 11 e9 2a 00 1f 41 00 ff ff ff ff ff
00 84 00 00 00 00 00 00
CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
CCVersion =0x14
CCPartnum =0x0
cc1101 found
mounting FS...
Starting config portal with SSID: NodeDuinoConfig
*WM: [1] AutoConnect
*WM: [2] esp_wifi_set_country: US
*WM: [2] Connecting as wifi client...
*WM: [1] STA static IP:


Das sollte wohl deine Frage beantworten  :D

EDIT:
01: Setting RX failed

Setze den cc1101 mal zurück.
- entweder via serieller Verbindung
- oder wenn du in FHEM Verbindung hast zum ESP via set <name> raw e
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 11:29:17
Hm komisch nur, woher plötzlich das "01: Setting RX failed". Scheinbar war es beim ersten mal nicht dort.
Ich verwende Windows & putty für Telnet. Habe dort einfach die IP und Port 23 eingegeben und auf "Connect" gedrückt.
Anschließend kam der Fehler "Command to long"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 12 April 2020, 11:33:10
Zitat von: zod am 12 April 2020, 11:29:17
Hm komisch nur, woher plötzlich das "01: Setting RX failed". Scheinbar war es beim ersten mal nicht dort.
Ich verwende Windows & putty für Telnet. Habe dort einfach die IP und Port 23 eingegeben und auf "Connect" gedrückt.
Anschließend kam der Fehler "Command to long"

Das ist bekannt und selbst hier auch. @sidey kann dir erläutern wieso das zu stande kommt.
Drücke in putty mal e und du solltest das rücksetzen sehen.
ccFactoryReset done

Siehst du RAWMSG´s eintreffen?

EDIT: Welche Version nutzt du zum Compilieren?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 11:39:25
Habe noch mal in Windows telnet installiert. Hier kann ich scheinbar Befehle senden.

telnet <IP> und <Enter>
Dann "e" und <Enter>
Dann sehe ich in der Konsole "ccFactoryReset done",
aber auf dem ESP bekomme ich folgenden Fehler:

New client:
192.168.178.48
.........................................CCInit SRES Started,POR Done,EEPROM read .........................................done
Fatal exception 3(LoadStoreErrorCause):
epc1=0x4000e041, epc2=0x00000000, epc3=0x00000000, excvaddr=0x4024c321, depc=0x00000000

Exception (3):
epc1=0x4000e041 epc2=0x00000000 epc3=0x00000000 excvaddr=0x4024c321 depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3ffffce0 end: 3fffffc0 offset: 01a0
3ffffe80:  00000000 00000019 4024c309 00000000 
3ffffe90:  00000001 3fff15fc 00000000 000001ff 
3ffffea0:  00000000 00000019 401003fc 00004f9a 
3ffffeb0:  00000000 b88dfb0c 00610a00 4024c309 
3ffffec0:  00000000 00000019 3fff115c 40204970 
3ffffed0:  007a1200 b88e49ac 00000000 4024c309 
3ffffee0:  00000001 00000000 3fff115c 40204a0a 
3ffffef0:  00000019 00000000 3fff115c 40204ae5 
3fffff00:  402156a8 00000000 00001388 00000057 
3fffff10:  40204aa8 3ffef264 4024c309 402103a5 
3fffff20:  3ffef11c 3ffef11c 3ffef264 40210691 
3fffff30:  00000000 3ffef11c 3ffeeef0 4020235d 
3fffff40:  0000000f 7f0a4a19 00000000 4022181a 
3fffff50:  007a1200 00000000 3fff115c 40204b96 
3fffff60:  3ffef11c 3ffef264 0000000a 3ffef11c 
3fffff70:  3ffef11c 3ffef264 3ffeeef0 40203115 
3fffff80:  3fffdad0 00000000 3ffef718 3ffef758 
3fffff90:  3fffdad0 00000000 3ffef718 40203185 
3fffffa0:  3fffdad0 00000000 3ffef718 402126a8 
3fffffb0:  feefeffe feefeffe 3ffe8514 40101059 
<<<stack<<<

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1392, room 16
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld


Und anschließend noch einmal "Setting RX failed".
Raw messages sehe ich nicht (also in der Arduino IDE Konsole wo ich die sonstigen Messages sehe).
Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 12 April 2020, 11:44:38
Du hast ein Stackover und deswegen Commandtolong ...

Welche Version nutzt du??? Das Thema hatten wir schon behandelt (finde Link nicht mit Handy)

Diese?
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r3.4_plattformIO

Erklärung:
,,Command to Long kommt, wenn das übermittelte Kommando nicht in den Puffer passt."

Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 12:08:57
Ne, habe den Master genommen.
Werde es mal mit dieser Version probieren
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zod am 12 April 2020, 12:53:41
Zitat von: HomeAuto_User am 12 April 2020, 11:44:38
Du hast ein Stackover und deswegen Commandtolong ...

Welche Version nutzt du??? Das Thema hatten wir schon behandelt (finde Link nicht mit Handy)

Diese?
https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r3.4_plattformIO

Erklärung:
,,Command to Long kommt, wenn das übermittelte Kommando nicht in den Puffer passt."

Gesendet von iPhone mit Tapatalk Pro

So, habe mal den Branch dev-r3.4_plattformIO genommen. Jetzt stürzt der Arduino nicht mehr ab.
Auch den Fehler bekomme ich gerade nicht mehr.

Habe via telnet "e" gesendet und bekomme folgende Ausgabe:

.........................................CCInit SRES Started,POR Done,EEPROM read .........................................done
dump
EEPROM=33 1d 0d 2e 2d 47 d3 91 3d 04 32 00 00 06 00 10
b0 71 57 c4 30 23 b9 00 07 00 18 14 6c 07 00 91
87 6b f8 b6 11 e9 2a 00 1f 41 00 ff ff ff ff ff
00 84 00 00 00 00 00 00


Jetzt habe ich meinen Wandsender neben mir liegen und drücke auf/ab/stopp, sehe aber keine empfangenen Signale.

Edit: Ah stop. Ich sehe sie glaube ich im telnet.
Ich denke, dass ich von hier erst mal weiterkomme. Vielen lieben Dank!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 12 April 2020, 13:10:52
Wenn der cc1101 erkannt wurde, kannst du in FHEM auf verbose 4 stellen und solltest im Log RAMSGs sehen.


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 16:28:59
Hallo,

ich habe nach zwei Jahren Abstinenz wieder FHEM installiert und hatte meinen nanoC1101 (Eigenbau) auch schon am laufen, maßgeblich um meine SOMFY RTS Rollläden zu steuern.

Auf einmal habe ich SIGNALduino = CLOSED - ich habe den RPI, FHEM, alles mittlerweile komplett neu aufgesetzt und komme nicht weiter.

Rechtevergabe nach Forumsbeiträgen auch schon geändert - über "nanoCUL" kann ich connecten, aber bekomme z.B. keine Config angezeigt.

Flashen klappt wunderbar, ohne Probleme. Zur Sicherheit habe ich AVRDUDE auch nochmal neu installiert.

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/opt/fhem/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex"
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex auto detected as Intel Hex
avrdude: writing flash (25830 bytes):

Writing | ################################################## | 100% 13.22s

avrdude: 25830 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex:
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex contains 25830 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 11.45s

avrdude: verifying ...
avrdude: 25830 bytes of flash verified

avrdude done.  Thank you.


Als Fehlermeldung im Log sehe ich "Not an SIGNALduino Device" - exakt dieses Gerät hat mit exakt dieser Verkabelung bis vor ein paar Tagen aber funktioniert.



Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2020.04.18 16:15:16 1: usb create starting
2020.04.18 16:15:16 3: Probing ZWDongle device /dev/serial0
2020.04.18 16:15:16 1: ZWDongle: Can't open /dev/serial0: Permission denied
2020.04.18 16:15:17 3: Probing CUL device /dev/ttyAMA0
2020.04.18 16:15:17 1: CUL: Can't open /dev/ttyAMA0: Permission denied
2020.04.18 16:15:17 1: usb create end
2020.04.18 16:15:17 0: Featurelevel: 6
2020.04.18 16:15:17 0: Server started with 7 defined entities (fhem.pl:21709/2020-04-17 perl:5.028001 os:linux user:fhem pid:551)
2020.04.18 16:15:17 3: sduino: IdList, attr whitelist disabled or not defined (all IDs are enabled, except blacklisted and instable IDs):
2020.04.18 16:15:17 3: sduino: IdList, MS 0 0.1 0.2 0.3 0.4 0.5 1 3 3.1 4 6 7 13 13.2 14 15 17 20 23 25 33 33.1 33.2 35 41 49 51 53 54.1 55 65 68 74.1 87 88 90 91.1 93
2020.04.18 16:15:17 3: sduino: IdList, MU 8 9 13.1 16 17.1 19 21 22 24 26 27 28 29 30 31 32 34 36 37 38 39 40 42 44 44.1 45 46 48 49.1 49.2 50 54 56 59 60 61 62 64 66 67 69 70 71 72 73 74 76 79 80 81 83 84 85 86 89 91 92 94 95 97
2020.04.18 16:15:17 3: sduino: IdList, MC 10 11 12 18 43 47 52 57 58 96
2020.04.18 16:15:17 3: sduino: IdList, development protocol is active (to activate dispatch to not finshed logical module, enable desired protocol via whitelistIDs) = 2 72.1 82
2020.04.18 16:15:17 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.04.18 16:15:18 3: sduino: StartInit, get version, retry = 0
2020.04.18 16:15:28 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:15:28 3: sduino: StartInit, get version, retry = 1
2020.04.18 16:15:38 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:15:38 3: sduino: StartInit, get version, retry = 2
2020.04.18 16:15:48 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:15:48 3: sduino: StartInit, get version, retry = 3
2020.04.18 16:15:48 2: sduino: StartInit, retry count reached. Reset
2020.04.18 16:15:48 3: sduino: ResetDevice, nanoCC1101
2020.04.18 16:15:48 3: Opening sduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0
2020.04.18 16:15:48 3: Setting sduino serial parameters to 57600,8,N,1
2020.04.18 16:15:48 1: sduino: DoInit, /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0@57600
2020.04.18 16:15:48 3: sduino device opened
2020.04.18 16:15:49 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.04.18 16:15:50 3: sduino: StartInit, get version, retry = 0
2020.04.18 16:16:00 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:16:00 3: sduino: StartInit, get version, retry = 1
2020.04.18 16:16:10 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:16:10 3: sduino: StartInit, get version, retry = 2
2020.04.18 16:16:20 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:16:20 3: sduino: StartInit, get version, retry = 3
2020.04.18 16:16:20 2: sduino: StartInit, init retry count reached. Closed
2020.04.18 16:16:20 2: sduino: CloseDevice, closed
2020.04.18 16:24:22 1: sduino: found availableFirmware for ESP8266,ESP8266cc1101,ESP32,nano328,nanoCC1101,miniculCC1101,promini,radinoCC1101
2020.04.18 16:24:26 3: sduino: Set_flash, 3.3.1 try to fetch github assets for tag 3.3.1
2020.04.18 16:24:26 3: sduino: Set_flash, 3.3.1 try to fetch release https://api.github.com/repos/RFD-FHEM/SIGNALDuino/releases/tags/3.3.1
2020.04.18 16:24:28 3: sduino: ParseHttpResponse, url https://github-production-release-asset-2e65be.s3.amazonaws.com/27504581/35219280-160d-11ea-8171-74214f6f40f0?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200418%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200418T142427Z&X-Amz-Expires=300&X-Amz-Signature=2a5148fa66cfc46b429451c43b5b7c5f1905466b11a15001578cc85481f108a8&X-Amz-SignedHeaders=host&actor_id=0&repo_id=27504581&response-content-disposition=attachment%3B%20filename%3DSIGNALDuino_nanocc11013.3.1.hex&response-content-type=application%2Foctet-stream returned: 72668 bytes Data
2020.04.18 16:24:28 3: sduino: ParseHttpResponse, Downloaded SIGNALDuino_nanocc11013.3.1.hex firmware from github-production-release-asset-2e65be.s3.amazonaws.com
2020.04.18 16:24:28 3: sduino: Set_flash, filename FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex provided, trying to flash
2020.04.18 16:24:56 3: sduino: avrdude, Firmware update was successfull
2020.04.18 16:24:56 3: Opening sduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0
2020.04.18 16:24:56 3: Setting sduino serial parameters to 57600,8,N,1
2020.04.18 16:24:56 1: sduino: DoInit, /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0@57600
2020.04.18 16:24:56 3: sduino device opened
2020.04.18 16:24:58 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.04.18 16:24:58 3: sduino: StartInit, get version, retry = 0
2020.04.18 16:25:08 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:25:08 3: sduino: StartInit, get version, retry = 1
2020.04.18 16:25:18 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:25:18 3: sduino: StartInit, get version, retry = 2
2020.04.18 16:25:28 1: sduino: CheckVersionResp, Not an SI
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 18 April 2020, 17:11:14
Du musst mal die Angaben in Deinem Post in #-Tags schreiben, das kann ja kein Mensch lesen. Einfach Post "bearbeiten".
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 18 April 2020, 17:16:24
Oder den Output als Text-Datei anhängen, da bekommt man wunde Scrollfingergelenke  :'(

Was erwartest Du mit Neuflashen, dass hinterher, nachdem es schon ging sich an der Situation etwas ändert?

Zeig mal ein sudo ls -als /dev/serial/by-id
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 18 April 2020, 17:37:22
Zitatdefine sduino SIGNALduino /dev/serial/by-id/ usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0@57600: Define, wrong syntax: define <name> SIGNALduino {none | devicename[@baudrate] | devicename@directio | hostname:port}
Da passt was nicht.
serial/by-id/ usb
Bitte entferne mal das Leerzeichen zwischen "/by-id/" und "usb"

Gruß Ralf

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 21:05:30
Zitat von: andies am 18 April 2020, 17:11:14
Du musst mal die Angaben in Deinem Post in #-Tags schreiben, das kann ja kein Mensch lesen. Einfach Post "bearbeiten".

Weiß zwar nicht wie das geht, aber sorry...da ist mir weit mehr Text reinpassiert als geplant war! Ich hab's mal auf den letzten Abschnitt im Log geändert.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 21:08:06
Zitat von: juergs am 18 April 2020, 17:16:24
Oder den Output als Text-Datei anhängen, da bekommt man wunde Scrollfingergelenke  :'(

Was erwartest Du mit Neuflashen, dass hinterher, nachdem es schon ging sich an der Situation etwas ändert?

Zeig mal ein sudo ls -als /dev/serial/by-id

Naja, nachdem ich nicht weiß, warum das Gerät nicht erkannt wird, wollte ich alles ausschließen... (bin aber max. Wiedereinsteiger, kein Profi)


pi@pi:~ $ sudo ls -als /dev/serial/by-id
insgesamt 0
0 drwxr-xr-x 2 root root 60 Apr 18 16:12 .
0 drwxr-xr-x 4 root root 80 Apr 18 16:12 ..
0 lrwxrwxrwx 1 root root 13 Apr 18 16:12 usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0 -> ../../ttyU                                                SB0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 21:13:47
Zitat von: Ralf9 am 18 April 2020, 17:37:22
Da passt was nicht.
serial/by-id/ usb
Bitte entferne mal das Leerzeichen zwischen "/by-id/" und "usb"

Gruß Ralf

Hallo Ralf, korrekt, das ist mir beim Define passiert (war noch im Log, von dem ich keine ganze Tapete schicken wolle) - ich hab das Device danach gelöscht und ohne das Leerzeichen nochmal definiert.

Ich kann diesen Fehler nicht interpretieren, also was die Ursache ist:

020.04.18 16:15:48 3: Opening sduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0
2020.04.18 16:15:48 3: Setting sduino serial parameters to 57600,8,N,1
2020.04.18 16:15:48 1: sduino: DoInit, /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YX9BNN-if00-port0@57600
2020.04.18 16:15:48 3: sduino device opened
2020.04.18 16:15:49 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.04.18 16:15:50 3: sduino: StartInit, get version, retry = 0
2020.04.18 16:16:00 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:16:00 3: sduino: StartInit, get version, retry = 1
2020.04.18 16:16:10 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.04.18 16:16:10 3: sduino: StartInit, get version, retry = 2
2020.04.18 16:16:20 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 18 April 2020, 21:18:34
Das Modul versucht die Version vom Arduino abzufragen, aber es kommt keine Rückmeldung.

Wie sieht es mit der Stromversorgung aus?
Vielleicht rebootet der Arduino ständig.

Hast Du den Arduino am PC mal angeschlossen?
Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 18 April 2020, 21:20:00
Din Signalduino reagiert nicht auf das Kommando "V".

Das kann erst mal 3 Ursachen haben:
1. falsche Software-Version geflasht
2. falsche Bitrate.
3 oder das von Sidey gepostete...  :D

Versuche mal 38400 statt 57600 ... hinten an der Signalduino Definition nach dem "@"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 21:39:51
Hab ich soeben gemacht. Der "sduino" ist ca. 7 Sekunden lang "opened" und dann "Not a SIGNALduino device" und anschließend "closed".

Ich hab' den RASPI mit nem USB Netzgerät mit 15W am laufen (Raspi Rev. B), ging bisher ohne Probleme.

Was kann ich am PC wie feststellen bezüglich Stromversorgung? (also, was soll ich tun, wenn das Ding am PC hängt?)

Könnt ihr mit den Softwareständen was anfangen? (Anhang)

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 21:42:58
Zitat von: Sidey am 18 April 2020, 21:18:34
Das Modul versucht die Version vom Arduino abzufragen, aber es kommt keine Rückmeldung.

Wie sieht es mit der Stromversorgung aus?
Vielleicht rebootet der Arduino ständig.

Hast Du den Arduino am PC mal angeschlossen?
Grüße Sidey

Könnte ich dann flashen? Das läuft m.E. sauber durch, inkl. wild blinkender LEDs beim flashen. Der Vorgang dauert ca. 15-20 Sekunden.

Wie im anderen Post geschrieben: wenn ich das Teil an den PC hänge, was kann ich dann feststellen und wie?

Danke!!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 18 April 2020, 21:51:04
Am PC kannst Du über ein Terminal-Programm prüfen ober die Hardware mit samt FW überhaupt reagiert:

Terminal-Programm , Putty oder http://freeware.the-meiers.org/ (http://freeware.the-meiers.org/) CoolTerm nehmen Serielle Schnittstelle finden: https://helmpcb.com/software/serial-port-monitor (https://helmpcb.com/software/serial-port-monitor)

und schauen wenn Du manuell "V" eingibst (evtl. lokales Echo einstellen) dann sollte er reagieren ebenso mit "?" .

Vermutlich scheint Deine Hardware aber irgendwie defekt zu sein, wenn das am PC auch passiert ... könnte es auch das USB-Kabel sein, einfach mal wechseln ...  ;)

#define BAUDRATE               57600
Scheint doch die richtige Einstellung der Bitrate zu sein !
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 18 April 2020, 22:28:28
Zitat von: juergs am 18 April 2020, 21:51:04
Am PC kannst Du über ein Terminal-Programm prüfen ober die Hardware mit samt FW überhaupt reagiert:

Terminal-Programm , Putty oder http://freeware.the-meiers.org/ (http://freeware.the-meiers.org/) CoolTerm nehmen Serielle Schnittstelle finden: https://helmpcb.com/software/serial-port-monitor (https://helmpcb.com/software/serial-port-monitor)

und schauen wenn Du manuell "V" eingibst (evtl. lokales Echo einstellen) dann sollte er reagieren ebenso mit "?" .

Vermutlich scheint Deine Hardware aber irgendwie defekt zu sein, wenn das am PC auch passiert ... könnte es auch das USB-Kabel sein, einfach mal wechseln ...  ;)

#define BAUDRATE               57600
Scheint doch die richtige Einstellung der Bitrate zu sein !

COM3 wird erkannt, aber in Putty geht nur ein Fenster auf wenn ich eine Verbindung herstellen möchte und passiert nix (9600, 38400, 57600...)

2020-04-18 22:21:22   Opening serial device COM3
2020-04-18 22:21:22   Configuring baud rate 9600
2020-04-18 22:21:22   Configuring 8 data bits
2020-04-18 22:21:22   Configuring 1 data bits
2020-04-18 22:21:22   Configuring no parity
2020-04-18 22:21:22   Configuring no flow control

....die LED am Arduino brennt...kann mir schwer vorstellen, dass der abgeraucht sein soll?! Kabel habe ich auch getauscht.

Ihr seht mich ratlos.

Habe eben mal auf Verdacht nen neuen Nano bestellt...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 18 April 2020, 23:04:37
Wenn ich Putty mit "Serial" und 115200 Bd aufmache und V ins Terminalfenster eingebe dann erscheint:
ZitatV 4.1.0-dev200322 SIGNALduino cc1101 (R: A1 B-*) - compiled at Apr 18 2020 12:11:29

Das sollte bei Dir mit 57600 Bd auch möglich sein, sonst stimmt was nicht mit der FW oder Hardware ...


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 18 April 2020, 23:22:07
Zitat von: juergs am 18 April 2020, 23:04:37
V 4.1.0-dev200322 SIGNALduino cc1101 (R: A1 B-*) - compiled at Apr 18 2020 12:11:29

Ich weiss nicht was Du da drauf hast, aber es gibt keine SIGNALduino Firmware Version 4.1.0.  ::)
Die letzte ist 3.4.0 (https://github.com/RFD-FHEM/SIGNALDuino/releases/tag/3.4.0-dev%2B20200216)

Aber so ähnlich sieht die Ausgabe für einen SIGNALduino aus und er lauscht auf eine Baudrate von 57600.

Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 19 April 2020, 00:12:36
@Sidey, Du hast recht.
Bitrate hatte ich hier schon korrigiert: https://forum.fhem.de/index.php/topic,58396.msg1044178.html#msg1044178
Wollte das  als Beispiel  von meinem MapleSignalduino zeigen, den ich gerade verfügbar hatte.
Wenn der Output bei ihm käme, würde man es ja sehen  ;)

@assi05
Wurde die serielle Verbindung über putty (Einstellung "serial und 57600 Baud sollte eigentlich reichen.) Dan Geht ein Fenster auf, reinklicken und ein V (großes V) eingeben.
Was passiert dann?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 19 April 2020, 11:34:56
Guten Morgen!

@juergs: In dem Fenster ist ein grüner, fester Cursor; keine Eingabe möglich. Ich hab Deine PN gesehen, antworte gleich.

Vielleicht tut es nichts zur Sache, ABER: was mir die letzten Tage, solange es noch funktioniert hat aufgefallen ist: meine RTS Rollläden sind immer wieder sporadisch in den Programmiermodus gefahren, obwohl ich im Garten saß und nichts am Raspi / SIGNALduino / SOMFY gemacht habt. Spooky?!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 19 April 2020, 11:44:39
Zitat von: assi05 am 18 April 2020, 21:05:30
Weiß zwar nicht wie das geht, aber sorry...da ist mir weit mehr Text reinpassiert als geplant war! Ich hab's mal auf den letzten Abschnitt im Log geändert.
Da drauf klicken und dort den Code hineinschreiben.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 19 April 2020, 14:44:29
Danke an @JUERGS, für die tolle Hilfe während unserer (ich glaube fast 2-stündiger) :) Videokonferenz.

Wir konnten den Signalduino manuell neu flashen und er ist wieder ansprechbar. Leider funktioniert er noch nicht zusammen mit dem CC1101.

@Sidey, Jürgen sagte, ich soll Dich mal fragen was Deine Gedanken dazu sind:

- flashen über FHEM mit NanoCC1101 hat mir die 3.3.1 angeboten, automatisiert geflashed, aber das Gerät wurde nicht mehr erkannt und Status closed.
- manueller flash mit: https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1/SIGNALDuino_nano3283.3.1.hex

--> Gerät wieder ansprechbar, aber vermutlich funktioniert diese Version NICHT mit dem CC1101?

Die Idee ist im Moment, ob ich manuell mit einer CC1101 flashe - aber welches ist die richtige .hex? (ich bin eher Frischling, vielleicht bediene ich auch GitHub falsch?!)

https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r332_cc1101/RF_Receiver --> ist diese Version ok, und wenn ja: wie komme ich an die richtige .hex?

DANKE für eine kurze Antwort und nochmals DANKE an Jürgen für die tolle Hilfe!!

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 19 April 2020, 14:52:46
Ergänzend:

ZitatDann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B. SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101

Hatten die Funktion des Nanos mit der Version in [1] "SIGNALDuino_nano3283.3.1.hex"  verifiziert (Putty geht), hat aber nicht mit dem CC1101 geklappt, vermute, das ist die mit den 433-Modulen.

Mit der SIGNALDuino_nanocc11013.3.1.hex -Version [2] (release) wird es statt der Dev-Version (Irrtum: Versions-Meldung des fhem-Moduls, nicht der Hardware)  dann sehr wahrscheinlich gehen? Aber:

In seiner Log Datei steht:
Zitatavrdude: reading input file "FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex"

Die hatte er ja erfolgreich über fhem geflasht und ging nicht ?!   :-\


Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 19 April 2020, 16:46:37
Hallo Zusammen,

ich habe das bei mir mit dieser Version "SIGNALDuino_nanocc11013.3.1.hex" aus dem gihub.releases-Verzeichnis nachvollzogen:

Zitat? Use one of V R t X S P C r W s x e
;S%X;
.Mu;...;...;...;...;...;...;...;d@g`g`gggggg`g``gg`g```gg``g`g`g```gg``ggg`.0;C0;RF1;.
.Mu;...;...;...;...;D..!.!!!!!!.!..!!.!...!!..!.!.!...!!..!!!.;C0;RF3;.
.Mu;...;...;...;...;...;D.#!#!#!#!#!#!#!#!#!!#!#####!!!#!#####!#!A#!#!#!#!#!#!#!#!#!!#!#####!!!#!#####!#!A#!#!#!#!#!#!#!#!#!!#!#####!!!#!#####!#!A#!#!#!;C2;RFB;O;.
.Mu;...;...;...;...;...;...;...;...;d.................................2.......................................VVp;C0;RFC;.
.MC;LL=-1015;LH=934;SL=-540;SH=442;D=FA0D660F0588B566312;C=488;L=75;R=243;.
.MC;LL=-1007;LH=944;SL=-528;SH=453;D=DDF41AEC1E0B116ACD754;C=488;L=82;R=243;.
.MC;LL=-1018;LH=932;SL=-537;SH=452;D=377D06B70782C45AB33BD;C=489;L=84;R=243;.

@assi05
Dann würde ich sagen, dass etwas mit der CC1101-Hardware nicht in Ordnung ist, deshalb bleibt wohl die Initialisierung hängen, da ja die Version ohne CC1101 ja funktioniert ...


Grüße,
Jürgen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 April 2020, 16:50:38
Jepp, ich habe es auch gerade getestet. Die Version funktioniert.



2020.04.19 16:44:56.309 3: sduino: StartInit, get version, retry = 0
2020.04.19 16:44:55.800 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.04.19 16:44:54.296 3: sduino device opened
2020.04.19 16:44:54.295 1: sduino: DoInit, /dev/ttyUSB0@57600
2020.04.19 16:44:54.288 3: Setting sduino serial parameters to 57600,8,N,1
2020.04.19 16:44:54.282 3: Opening sduino device /dev/ttyUSB0
2020.04.19 16:44:54.270 3: sduino: avrdude, Firmware update was successfull
2020.04.19 16:44:37.917 3: sduino: Set_flash, filename FHEM/firmware/SIGNALDuino_nanocc11013.3.1.hex provided, trying to flash
2020.04.19 16:44:37.898 3: sduino: ParseHttpResponse, Downloaded SIGNALDuino_nanocc11013.3.1.hex firmware from github-production-release-asset-2e65be.s3.amazonaws.com
2020.04.19 16:44:37.886 3: sduino: ParseHttpResponse, url https://github-production-release-asset-2e65be.s3.amazonaws.com/27504581/35219280-160d-11ea-8171-74214f6f40f0?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200419%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200419T144437Z&X-Amz-Expires=300&X-Amz-Signature=71d53cbfc732dfe2908abd3ca54aa530106ac0e92bf4546602cb9558a2fc955f&X-Amz-SignedHeaders=host&actor_id=0&repo_id=27504581&response-content-disposition=attachment%3B%20filename%3DSIGNALDuino_nanocc11013.3.1.hex&response-content-type=application%2Foctet-stream returned: 72668 bytes Data
2020.04.19 16:44:36.012 3: sduino: Set_flash, 3.3.1 try to fetch release https://api.github.com/repos/RFD-FHEM/SIGNALDuino/releases/tags/3.3.1
2020.04.19 16:44:36.011 3: sduino: Set_flash, 3.3.1 try to fetch github assets for tag 3.3.1
2020.04.19 16:44:30.004 1: sduino: found availableFirmware for ESP8266,ESP8266cc1101,ESP32,nano328,nanoCC1101,miniculCC1101,promini,radinoCC1101



Was mich noch interessieren würde ist, was genau wurde bei "manuellem Flashen" gemacht.

Lässt sich das Ergebnis reproduzieren, wenn als Hardware nano328 ausgewählt wird? Kommt dann auch eine Version zurück?


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 19 April 2020, 16:55:11
Das Flashen wurde manuell via avrdude  (https://werbasteltmit.wordpress.com/2020/04/13/avrdude-kommandozeile/)in der Konsole mit der anderen Version gemacht, da sie in Fhem nicht zur Auswahl stand (ist wohl Absicht ;-) )
Mit der "falschen" Version kommt V und ? mit Info zurück. Logischerweise geht dann der Zugriff via C35 oder C99 nicht ... da der CC1101 nicht ansprechbar ist.
=> Steckbrettversion :-)

Ist es Absicht, dass der avrdude-Aufruf nicht in den Logs erscheint ? Das wäre hilfreich, das manuell nachzuvollziehen, der Output ist natürlich da ;-)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 April 2020, 17:12:15
Zitat von: juergs am 19 April 2020, 16:55:11
Ist es Absicht, dass der avrdude-Aufruf nicht in den Logs erscheint ? Das wäre hilfreich, das manuell nachzuvollziehen, der Output ist natürlich da ;-)

Nein ich glaube das war keine Absicht, früher wurde da was ausgegeben. Das habe ich wohl wegoptimiert :)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 19 April 2020, 17:21:58
Ach ja so noch als Info:

define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600

Also voller Pfad zum Device, sonst wundert man sich, dass der Signalduino disconnected bleibt!   :o :D ;)

RTFM: https://wiki.fhem.de/wiki/SIGNALduino (https://wiki.fhem.de/wiki/SIGNALduino)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 19 April 2020, 19:45:16
ZitatDann würde ich sagen, dass etwas mit der CC1101-Hardware nicht in Ordnung ist, deshalb bleibt wohl die Initialisierung hängen, da ja die Version ohne CC1101 ja funktioniert ...
Dies sollte eigentlich egal sein solange durch den defekten cc1101 die Spannung nicht zusammenbricht.

Ich habs bei mir mal mit meiner V 3.3.2.1-rc9 auf einem nano ohne cc1101 getestet
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_nanoCC1101_3321rc9.hex

Wenn ich bei der Arduino IDE den Seriellen Monitor (Putty sollte genauso gehen) öffne, erhalte ich folgendes:
Using sFIFO
Reading values from eeprom
CCInit no CC11xx found! ccVer=0 ccPartnum=0
Starting timerjob
receiver enabled


Ein "V" ergibt:
V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 20:18:01
da der cc1101 nicht erkannt wurde, fehlt bei der Versionsausgabe das "cc1101"

Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 19 April 2020, 22:04:16
Ich bin überwältigt von Eurer Unterstützung!!! :)

AAAAALSO:

Ich habe nochmal diverse CC1101 FWs geflashed, hat immer ohne Fehler funktioniert, aber: Gerät mit all den CC1101-Versionen nicht ansprechbar.

Letztlich habe ich bei Sidey folgende FW gefunden, mit der es funktioniert:

https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.4.0-dev%2B20200216/SIGNALDuino_nanocc11013.4.0-dev+20200216.hex

SOMFYs werden per Autocreate angelegt, ich kann auch programmieren - also Gerät ist grundsätzlich mal wieder nutzbar.

Was mich wundert, ist dass meine Frequenzänderung auf 433.42 offenbar nicht umgesetzt wird:

get sduino ccconf: Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 40 dB, sens: 8 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync

obwohl

attr sduino cc1101_frequency 433.42

Das Signal ist aber denke ich "breit" genug, dass es trotzdem funktioniert.

Ich muss jetzt mal hoch zu Mutti auf die Couch, aber ohne Eure Hilfe hätte das nicht geklappt! Danke nochmal! So langsam wachse ich wieder rein :) und werde die nächsten Tage weiter machen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 19 April 2020, 22:28:10
Das Attribut cc1101_frequency dient nur dazu den PA Level korrekt anzupassen :)
Zum Anpassen gibt es set cc1101_freq.

Freut mich dass es nun klappt.
Warum das aber mit der 3.3.1er Firmware bei dir nicht wollte verstehe ich gerade nicht. Hauptsache jetzt läuft es.
PS: Somfy stellt beim Senden die Frequenz um, du müsstest es somit nur für besseren Empfang anpassen.

Grüße Sidey

Titel: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: RaspiLED am 20 April 2020, 13:26:26
Hi,

Evtl, hat er einen besonderen CC1101 und die Bytefolge ist noch nicht in der Prüfroutine!?

Hast Du mal ein Foto vom cc1101???

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 20 April 2020, 13:47:54
Anbei - bitte nicht gleich draufhauen! Bin BWLer, kein Elektroniker ;)

Was komisch ist: ich hatte alles 2017 mit exakt dieser HW schon mal am laufen - und auch bis letzte Woche hat alles funktioniert. Dann auf einmal wurde meine HW nicht mehr erkannt in SIGNALduino.

--> Da gab's die 3.4.0 sicher noch nicht.

Morgen kommt ein neuer Signalduino mit der Post, ich prüfe dann mal mit alternativer FW, was passiert.

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 April 2020, 14:12:02
Dies ist vom Aufbau und der Kabellänge her recht grenzwertig.

Bitte mach mal ca 10-20 mal ein "get sduino ccconf" und schau ob die Werte immer passen.

Hast Du auch meine V 3.3.2.1-rc9 getestet?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 20 April 2020, 14:50:34
Hallo Ralf,

ja, Deine FW-Version hatte ich auch probiert, ohne Erfolg.

Habe eben bestimmt 20x get sduino ccconf gemacht, Ergebnis immer dasselbe ohne Probleme:

ccconf: Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 40 dB, sens: 8 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync

ist die niedrige DataRate ok? 5.6k Baud?

Gruß
Jochen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pc1246 am 20 April 2020, 15:12:33
Zitat von: assi05 am 20 April 2020, 14:50:34
Hallo Ralf,

ja, Deine FW-Version hatte ich auch probiert, ohne Erfolg.

Habe eben bestimmt 20x get sduino ccconf gemacht, Ergebnis immer dasselbe ohne Probleme:

ccconf: Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 40 dB, sens: 8 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync

ist die niedrige DataRate ok? 5.6k Baud?

Gruß
Jochen
Moin
Andies hatte Dich schon mal gebeten, Deine Posts zu formatieren! Auf Seite 77 ganz oben, hat er Dir sogar beschrieben, wie es geht.
Das ist echt irre anstrengend Deine posts zu lesen, da man sich immer alles auseinanderklamuesern muss!
Ich habe jetzt mal im Zitat das nachtraeglich angepasst. Das sollte Dir auch gelingen!
Gruss Christoph
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 20 April 2020, 15:36:55
Done...ich dachte,  es geht um große Tapeten Code..

Aber gut, Du hast Recht, sieht auch bei dem Einzeiler schöner aus.

Gruß!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 April 2020, 19:30:58
Zitatist die niedrige DataRate ok? 5.6k Baud?
Ja, das passt

ZitatBandwidth: 325 KHz
Da bei diesen blauen cc1101 die Frequenz nicht sehr genau ist, kann es bei einigen Temperatursensoren notwendig sein, daß Du die Bandwidth auf ca 400 oder 500 erhöhst.

Mit dem Maple Mini ist die fliegende Verkabelung viel übersichtlicher, da keine Widerstände (Levelshifter) notwendig sind (siehe Anlage)

Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: assi05 am 21 April 2020, 22:09:12
Zitat von: Ralf9 am 20 April 2020, 19:30:58
Da bei diesen blauen cc1101 die Frequenz nicht sehr genau ist, kann es bei einigen Temperatursensoren notwendig sein, daß Du die Bandwidth auf ca 400 oder 500 erhöhst.


Danke für den Hinweis! Gesagt, getan und auf einmal wird auch meine SD_Bell Tchibo Funkklingel erkannt :) Jetzt muss ich nur noch verstehen, wie ich mich am Handy/Alexa benachrichtigen lassen kann wenn's klingelt. Oder gar über ein Zucken meiner Somfy-Markise? Das Ding ist nur die Gartenklingel, also wenn wir im Garten sind. So etwas müsste doch denkbar sein, oder?

Schönen Abend!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 21 April 2020, 22:45:41
Zitat von: assi05 am 21 April 2020, 22:09:12
Jetzt muss ich nur noch verstehen, wie ich mich am Handy/Alexa benachrichtigen lassen kann wenn's klingelt.

Wenn Du das geschafft hast, dann lass mich daran teilhaben.
Wobei ich im Garten keine Alexa habe hmm.

Aufs Handy habe ich die Benachtichtungen über Telegram realisiert. Ist aber auch nicht immer so gut wenn das Handy lautlos gestellt ist.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 22 April 2020, 12:38:41
Hallo Zusammen,

habe seit Kurzem wieder den nanoSDUInoCC1101 im Einsatz.
Allerdings werde ich gerade mit SDBell-Türglocken Devices überschüttet:
ZitatPlease define FileLog_SD_BELL_FA7A03E first
Please define FileLog_SD_BELL_FA7A03E first
Please define FileLog_SD_BELL_FA7A041 first
Please define FileLog_SD_BELL_FA7A041 first
Please define FileLog_SD_BELL_FA7A042 first
Please define FileLog_SD_BELL_FA7A042 first
Please define FileLog_SD_BELL_FA7A043 first
Please define FileLog_SD_BELL_FA7A043 first
Please define FileLog_SD_BELL_FA7A047 first
Please define FileLog_SD_BELL_FA7A047 first
Please define FileLog_SD_BELL_FA7A048 first
Please define FileLog_SD_BELL_FA7A048 first
Please define FileLog_SD_BELL_FA7A04B first
Please define FileLog_SD_BELL_FA7A04B first
Please define FileLog_SD_BELL_FA7A04C first
Please define FileLog_SD_BELL_FA7A04C first
Please define FileLog_SD_BELL_FA7A04D first
Please define FileLog_SD_BELL_FA7A060 first
Please define FileLog_SD_BELL_FA7A060 first
Please define SD_BELL_FA7A03E first
Please define SD_BELL_FA7A03E first
Please define SD_BELL_FA7A041 first
Please define SD_BELL_FA7A041 first
Please define SD_BELL_FA7A042 first
Please define SD_BELL_FA7A042 first
Please define SD_BELL_FA7A043 first
Please define SD_BELL_FA7A043 first
Please define SD_BELL_FA7A047 first
Please define SD_BELL_FA7A047 first
Please define SD_BELL_FA7A048 first
Please define SD_BELL_FA7A048 first
Please define SD_BELL_FA7A04B first
Please define SD_BELL_FA7A04B first
Please define SD_BELL_FA7A04C first
Please define SD_BELL_FA7A04C first
Please define SD_BELL_FA7A060 first
Please define SD_BELL_FA7A060 first

... und das ist die Menge nur in einem kleinem Zeitraum von etwa 30 Min ...

Das sieht nach rollierendem Code aus,. Ich nehme mal an, dass hier im Nachbarbereich nicht so viele Türklingeln von Tschibo aktiv sind...

Ich habe mal den Device-Typ in der Whitelist  herausgenommen und fhem neu gestartet
und hoffe das ich dann  davon verschont bleibe.

;-)

Grüße,
Jürgen

/Nein, wirkt nicht...


/edit: Oh, es gibt mehrfache Einträge SD_BELL in der Whitelist (Sortierung?) ;-)

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 22 April 2020, 15:30:26
Hallo Jürgen,

kannst Du bitte ein paar von diesen raw Nachrichten posten?

Wenn Du beim sduino den verbose auf 4 hast, müsstest Du eigentlich im log sehen welche raw Nachrichten diese SDBell-Türglocken Devices erzeugen.
Im Log kannst Du auch die entsprechende Protokoll ID sehen. Diese Protokoll ID kannst Du dann aus der Whitelist rausnehmen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 22 April 2020, 15:46:43
Hallo,
ich habe auch eine fremde Glocke in der Nähe, im Laufe der Zeit haben sich die folgenden IDs angesammelt:
SD_BELL_02E
SD_BELL_4BE   
SD_BELL_6E4
SD_BELL_E96

Das könnte beim Identifizieren der Stellen helfen.

2020-02-27_15:22:02 SD_BELL_02E Protocol_ID: 79
2020-02-27_15:22:02 SD_BELL_02E DMSG: P79#02E
2020-02-27_15:22:02 SD_BELL_02E RAWMSG: MU;P0=-4965;P1=513;P2=-629;P3=1364;P4=364;P5=-294;P6=681;P7=-104;CP=4;D=12123212456217656562404242424242424562456565624042424242424245624565656240424242424242456245656562404242424242424562456565624042424242424245621;p;

2020-03-13_13:43:04 SD_BELL_4BE Protocol_ID: 79
2020-03-13_13:43:04 SD_BELL_4BE DMSG: P79#4BE
2020-03-13_13:43:04 SD_BELL_4BE RAWMSG: MU;P0=635;P1=-312;P2=-632;P3=325;P4=-4847;D=01023432310232310231010101010234323102323102310101010102343231023231023101010101023432310232310231010101010234323102323102310101010102343231023231023101010101023432310232310231010101010234323102323102310101010102343231023231023101010101023432310232310231;CP=3;O;


2020-01-10_20:17:35 SD_BELL_6E4 Protocol_ID: 79
2020-01-10_20:17:35 SD_BELL_6E4 DMSG: P79#6E4
2020-01-10_20:17:35 SD_BELL_6E4 RAWMSG: MU;P0=-300;P1=315;P2=-456;P3=763;P4=-872;P6=186;P7=-4084;CP=1;D=012323234141412341232341414141234141414671412323412323234141234141464123414123232341414121;e;i;


2020-01-30_13:18:47 SD_BELL_E96 Protocol_ID: 79
2020-01-30_13:18:47 SD_BELL_E96 RAWMSG: MU;P0=-204;P1=314;P2=-319;P3=640;P4=-647;P5=-4920;CP=1;D=01232341232341512323234123414123412323415123232341234141234123234151232323412341412341232341512323234123414123412323415123232341234141234123234151232323412341412341232341512323234123414123412323415123232341234141234123234151232323412341412341232341512323;O;


Wenns irrelevant ist, einfach ignorieren
Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: juergs am 22 April 2020, 15:56:34
Hallo Horst + Ralf,

vielen Dank für Eure Mühe.

Die Haustür-Glocken meiner Nachbarn sind mal eher uninteressant, leider müllen sie mein log zu. (Außer zum Ärgern ...  ::)

Hatte Übersehen, dass das Protokoll mehrere Einträge in der protocol_list hatte (ziemlich weiter unten) ...

In den Daten von Harst sehe ich die ID: 79 und nehme an es ist das Protokoll SD_BELL.

2020.04.19 17:19:22 5: sduino: Starting demodulation (StartStr: 212121 first found at 2 regex: (?:212121)((?:21|31){28,}) Pos 2) length_min_max (28..120) length=42
2020.04.19 17:19:22 5: sduino: dispatching hex: P42#E9E821FFFDC
2020.04.19 17:19:22 4: sduino: Decoded matched MU Protocol id 42 dmsg P42#E9E821FFFDC length 44 dispatch(1/4) RSSI = -67.5
2020.04.19 17:19:22 5: sduino Dispatch: P42#E9E821FFFDC, test ungleich: disabled
2020.04.19 17:19:22 5: sduino Dispatch: P42#E9E821FFFDC, -67.5 dB, dispatch
2020.04.19 17:19:22 5: sduino: dispatch P42#E9E821FFFDC
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse protocol 42 Pollin_551227 doubleCode=no rawData=E9E821FFFDC
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse Check P42 - E9E821FFFDC alone
2020.04.19 17:19:22 1: sduino: SD_BELL_Parse UNDEFINED BELL detected, Protocol 42 code E9E821F
2020.04.19 17:19:22 5: part is 2121212121312131312121212131213131313131213131313121212121212121212121212121212131212121 starts at position 92 and ends at 186
2020.04.19 17:19:22 5: sduino: 2. try demodulation at Pos 92
2020.04.19 17:19:22 5: sduino: dispatching hex: P42#FA7A087FFF7
2020.04.19 17:19:22 4: sduino: Decoded matched MU Protocol id 42 dmsg P42#FA7A087FFF7 length 44 dispatch(2/4) RSSI = -67.5
2020.04.19 17:19:22 5: sduino Dispatch: P42#FA7A087FFF7, test ungleich: disabled
2020.04.19 17:19:22 5: sduino Dispatch: P42#FA7A087FFF7, -67.5 dB, dispatch
2020.04.19 17:19:22 5: sduino: dispatch P42#FA7A087FFF7
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse protocol 42 Pollin_551227 doubleCode=no rawData=FA7A087FFF7
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse Check P42 - FA7A087FFF7 alone
2020.04.19 17:19:22 1: sduino: SD_BELL_Parse UNDEFINED BELL detected, Protocol 42 code FA7A087
2020.04.19 17:19:22 5: part is 2121212121312131312121212131213131313131213131313121212121 starts at position 188 and ends at 252
2020.04.19 17:19:22 5: sduino: 3. try demodulation at Pos 188
2020.04.19 17:19:22 5: sduino: dispatching hex: P42#FA7A0878
2020.04.19 17:19:22 4: sduino: Decoded matched MU Protocol id 42 dmsg P42#FA7A0878 length 32 dispatch(3/4) RSSI = -67.5
2020.04.19 17:19:22 5: sduino Dispatch: P42#FA7A0878, test ungleich: disabled
2020.04.19 17:19:22 5: sduino Dispatch: P42#FA7A0878, -67.5 dB, dispatch
2020.04.19 17:19:22 5: sduino: dispatch P42#FA7A0878
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse protocol 42 Pollin_551227 doubleCode=no rawData=FA7A0878
2020.04.19 17:19:22 4: sduino: SD_BELL_Parse Check P42 - FA7A0878 alone
2020.04.19 17:19:22 1: sduino: SD_BELL_Parse UNDEFINED BELL detected, Protocol 42 code FA7A087
2020.04.19 17:19:22 5: sduino: start pattern for MU Protocol id 44 -> BresserTemeo not found, aborting
2020.04.19 17:19:22 5: sduino: start pattern for MU Protocol id 44.1 -> BresserTemeo not found, aborting
2020.04.19 17:19:22 5: sduino: start pattern for MU Protocol id 45 -> Revolt not found, aborting
2020.04.19 17:19:22 5: sduino: start pattern for MU Protocol id 46 -> SKXxxx, GF0x0x not found, aborting


Zitat2020.04.19 17:19:22 1: sduino: SD_BELL_Parse UNDEFINED BELL detected, Protocol 42 code FA7A087

=>    
   
Zitat42
MU
SD_BELL   
wireless doorbell
Pollin 551227

Die Protokoll ID 42 wäre auszublenden gewesen, die anderen SD_BELL Devices hätten eine andere ID. 

=> Die Protokoll-ID steht auch in Attribut "Def"
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Hoobert am 27 April 2020, 13:05:50
Hallo zusammen,

ich habe jetzt einige Beiträge gelesen, aber die Antwort auf folgende Frage nicht gefunden. Wahrscheinlich kann das einer der Experten aber ohne große Probleme beantworten:
Mein SIGNALDuino soll primär SMOFY RTS senden UND empfangen, außerdem sollte er mehrere TFA 30.3208.02 empfangen. Das Problem hierbei ist, dass SOMFY mit 433,42 MHz arbeitet, die TFA aber mit 433,92 MHz. Momentan geht bei mir nur das eine oder das andere. Gibt es eine Möglichkeit Einstellungen zu wählen, die beides möglich machen oder gibt es hier Entwicklungen in der Firmware des SIGNALDuino die das evtl. in naher Zukunft möglich machen oder hilft nur ein zweiter SIGNALDuino?

Hier noch das List meines SIGNALDuino:
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0@57600
   DMSG       YsCAE3EE1A348A00
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0@57600
   FD         28
   FUUID      5e96a9b7-f33f-07a2-fa15-91b0cd2be5f71159
   IDsNoDispatch 2,72.1,82
   ITClock    250
   LASTDMSG   YsCAE3EE1A348A00
   LASTDMSGID 43
   MSGCNT     1193
   NAME       SDUINO
   NR         180
   NR_CMD_LAST_H 1
   PARTIAL   
   RAWMSG     MC;LL=-1411;LH=1266;SL=-750;SH=588;D=CAE3EE1A348A00;C=669;L=56;R=229;s9;b6;
   RSSI       -87.5
   STATE      opened
   TIME       1587981228
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   unknownmessages
   version    V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01
   versionProtocols 1.17
   versionmodul v3.4.3
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2020-04-25 16:51:58   cc1101_config   Freq: 433.420 MHz, Bandwidth: 464 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud
     2020-04-25 16:51:58   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2020-04-25 13:16:46   cc1101_patable  C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2018-04-11 18:24:39   ccconf          freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-04-10 19:02:45   ccpatable       C3E = 00 84 00 00 00 00 00 00  => 5_dBm
     2018-04-10 19:03:00   cmds            V R t X F S P C r W x e
     2018-04-10 19:03:09   config          MS=1;MU=1;MC=1
     2018-04-10 19:03:18   freeram         637
     2020-04-27 12:56:19   ping            OK
     2020-04-25 13:16:44   state           opened
     2018-04-10 19:03:48   uptime          0 00:54:48
     2020-03-03 18:04:48   version         V 3.3.1-RC4 SIGNALduino cc1101  - compiled at Mar 10 2018 23:20:23
   XMIT_TIME:
     1587980935
   additionalSets:
     flash      3.3.1
   helper:
     avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>./log/SIGNALduino-Flash.log
     avrdudelogs flashing Arduino SDUINO
hex file: FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE] || avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex 2>[LOGFILE]

SDUINO closed
--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 5.11.1, compiled on May 23 2012 at 11:08:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex"
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: writing flash (24984 bytes):

Writing | ################################################## | 100% 7.32s

avrdude: 24984 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex:
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALduino_nanoCC1101_3321rc9.hex contains 24984 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.39s

avrdude: verifying ...
avrdude: 24984 bytes of flash verified

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

SDUINO reopen started

   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     0.5
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     54.1
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
Attributes:
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    3


Vielen Dank und Gruß
Hoobert
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 27 April 2020, 22:27:42
Hi,

Du kannst den SIGNALduino auf eine Frequenz zwischen 433,92 und und 433,42 stellen. GGf. musst Du auch die Bandbreite ein wenig nach oben anpassen.
Welcher Wert für dich am besten funktioniert, bekommst Du leider nur durch ausprobieren heraus, da die Empfangsqualität leider abnimmt, je weiter Du dich von der Frequenz des Senders entfernst.


Grüße Sidey
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Hoobert am 28 April 2020, 14:22:57
Hallo Sidey,

vielen Dank für den Tipp. Ich habe mal folgende Einstellungen gewählt:
Freq: 433.675 MHz, Bandwidth: 650 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud

Ein erster Test hat ergeben, dass ich beides empfangen kann. Ich werde das mal längerfristig im Auge behalten, ob die Einstellungen auch die erhoffte Zuverlässigkeit erreichen.

Gruß
Hoobert
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: mayonezo am 04 Mai 2020, 23:13:48
Zitat von: HomeAuto_User am 08 Oktober 2019, 10:16:37
Hallo, mach dir die Arbeit und Vergleiche die Pins vom bsp Radino in der Ino Datei mit dem Leonardo. Passe diese an und kompiliere :)

Auf die schnelle ...
(https://uploads.tapatalk-cdn.com/20191008/3c21da7b7163d2dc1e117dc9bdb10176.jpg)

(https://uploads.tapatalk-cdn.com/20191008/d0efb51973a4b1933b7a98715b156209.jpg)

@Sidey, wollen wir den Leoardo mit aufnehmen analog dem Radino? So muss der User nur ,,umschalten" vor dem Kompilieren.

Grüße marco


Gesendet von iPhone mit Tapatalk Pro

So, ich habe nun Zeit gehabt und den Leonardo mit der Arduino IDE geflasht (V 3.3.1). Hat soweit alles geklappt, Signalduino wird von FHEM erkannt. Die Pins des Radino und des Leonardo zum Senden und Empfangen sind soweit ich das sehe gleich:

             Radino  ATmega32U4   Leonardo
Send          9            PB5                 9
Receive      7            PE6                 7

Leider weiß ich nicht recht wie ich das nun testen soll. Meine Funksteckdose (Elro) wollte ich über das IT Modul steuern, das klappt aber leider nicht. Ich bin mir aber nicht sicher, ob ich die richtigen Befehle sende (DEF 0F0F0FFF0F FF F0). Bisher steuere ich die direkt mit meinem Raspberry Pi erfolgreich mit dem Modul Shellswitch (DEF /home/pi/wiringPi/433Utils/RPi_utils/send 10101 4 1 0).

Verbose des Signalduino devices ist auf 4, aber da kommt nichts rein. Ich habe auch "attr autocreate autosave 1" gesetzt, da kommt auch nichts rein.

Wie kann ich das am besten debuggen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 04 Mai 2020, 23:44:28
Hi,

Verbose 4 sollte ausreichen.
Schau dir noch mal die Verbindung zum Empfänger an und ob auch wirklich der Empfänger am richtigen Pin hängt.
Ansonsten, das Logfile mal genau ansehen wenn der SIGNALduino initialisiert wird, ggf. auch einfach mal an der seriellen Konsole direkt schauen ob was empfangen wird.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 05 Mai 2020, 16:25:47
Zitat von: mayonezo am 04 Mai 2020, 23:13:48
So, ich habe nun Zeit gehabt und den Leonardo mit der Arduino IDE geflasht (V 3.3.1). Hat soweit alles geklappt, Signalduino wird von FHEM erkannt. Die Pins des Radino und des Leonardo zum Senden und Empfangen sind soweit ich das sehe gleich:

             Radino  ATmega32U4   Leonardo
Send          9            PB5                 9
Receive      7            PE6                 7

Mir erschließt sich jetzt nicht, welche Firmware du geflasht hast und welche Hardware du verwendest.
Für den Leonardo müsstest du die Firmware des Radino verwenden und den CC1101 dann aber auch so anschließen:

#ifdef ARDUINO_RADINOCC1101
#define PIN_LED               13
#define PIN_SEND              9   // gdo0Pin TX out
#define PIN_RECEIVE    7
#define PIN_MARK433   4
#define SS   8 


Für einen ATMEGA32U4 mit getrenntem Sender und Empfänger (kein CC1101) gibt es m.E. keine vorgefertigte Konfiguration.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: mayonezo am 05 Mai 2020, 19:15:50
Zitat von: elektron-bbs am 05 Mai 2020, 16:25:47
Mir erschließt sich jetzt nicht, welche Firmware du geflasht hast und welche Hardware du verwendest.
Für den Leonardo müsstest du die Firmware des Radino verwenden und den CC1101 dann aber auch so anschließen:

#ifdef ARDUINO_RADINOCC1101
#define PIN_LED               13
#define PIN_SEND              9   // gdo0Pin TX out
#define PIN_RECEIVE    7
#define PIN_MARK433   4
#define SS   8 


Für einen ATMEGA32U4 mit getrenntem Sender und Empfänger (kein CC1101) gibt es m.E. keine vorgefertigte Konfiguration.

Achso, also kann das gar nicht funktionieren? Als Sender- und Empfängermodul habe ich die FS1000A und XY-MK-5V. Ich habe das also ohne cc1101 verkabelt wie hier zu sehen, statt D2 und D11 dann 7 und 9 an meinem Leonardo: https://wiki.fhem.de/wiki/Datei:Fhemduino_schematic.png
An meinem Raspberry Pi läuft noch die Kombination aus FS1000A und RXB6 produktiv.

Ich habe die Firmware V 3.3.1 von hier kompiliert und geflasht: https://github.com/RFD-FHEM/SIGNALDuino
Dafür habe ich sämtliche Libraries in ein Verzeichnis mit der SIGNALDuino.ino Datei gepackt.

Wenn es keine vorgefertigte Konfiguration gibt, muss ich also erstmal so eine Konfiguration erstellen? Ich kenne mich da mit den Arduinos leider überhaupt nicht gut aus.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 05 Mai 2020, 21:50:35
Also der XY-MK-V5 ist die absolute Katastrophe. Wenn du damit was anderes als 433MHz-Lampen schalten willst, musst Du Dir einen besseren Empfänger besorgen. Hier
https://www.raspberrypi.org/forums/viewtopic.php?t=164177&start=50 (https://www.raspberrypi.org/forums/viewtopic.php?t=164177&start=50)
findest Du Bilder von Oszilloskop-Bildern die zeigen, wie verzerrt das Gerät empfängt.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: mayonezo am 06 Mai 2020, 00:27:31
Zitat von: andies am 05 Mai 2020, 21:50:35
Also der XY-MK-V5 ist die absolute Katastrophe. Wenn du damit was anderes als 433MHz-Lampen schalten willst, musst Du Dir einen besseren Empfänger besorgen. Hier
https://www.raspberrypi.org/forums/viewtopic.php?t=164177&start=50 (https://www.raspberrypi.org/forums/viewtopic.php?t=164177&start=50)
findest Du Bilder von Oszilloskop-Bildern die zeigen, wie verzerrt das Gerät empfängt.

Danke für die Bilder. Ich werde den RXB6 benutzen, sobald ich meinen Leonardo dazu gebracht habe überhaupt irgendwas zu empfangen und zu senden.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 02 Oktober 2020, 14:16:33
D1 Mini Pro ESP8266 ESP-8266EX  als SIGNALDUINO;

Hallo zusammen, ich stehe gerade auf dem Schlauch.
Habe die Hardware zusammen, kann sie einbinden aber der RX bleibt ruhig und der TX sendet nicht.
Im Arduino Monitor sehe ich beim senden
13:59:28.327 -> send cmd detected Adding raw
13:59:28.327 -> rearrange beginptr
13:59:28.327 -> Adding repeats: 6
13:59:28.327 -> Adding bucket
13:59:28.327 -> Adding bucket
13:59:28.327 -> Adding bucket
13:59:28.327 -> Adding bucket
13:59:28.362 -> locating data start:01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203; end:;
13:59:28.362 -> : Setting TX failed
13:59:28.362 -> repeat 0/0 cmd 0/0 reps 6
13:59:28.743 -> .
13:59:28.743 -> SR;

das 13:59:28.362 -> : Setting TX failed scheint doch etwas zu bedeuten.
Im Fhem Log selbst sehe ich beim Senden:
2020.10.02 14:14:26 3 : cc1101_ip3 IT_set: IT_10010110100110011010011010100101010101010101010101010 off
2020-10-02 14:14:26 IT IT_10010110100110011010011010100101010101010101010101010 off
2020.10.02 14:14:26 5 : cc1101_ip3: Write, sending via Set sendMsg P65#100101101001100110100110101001010101010101010100110101010#R6
2020.10.02 14:14:26 5 : cc1101_ip3: Set_sendMsg, msg=P65#100101101001100110100110101001010101010101010100110101010#R6
2020.10.02 14:14:26 5 : cc1101_ip3: Set_sendMsg, Preparing rawsend command for protocol=65, repeats=6, clock=230 bits=100101101001100110100110101001010101010101010100110101010
2020.10.02 14:14:26 5 : cc1101_ip3: AddSendQueue, cc1101_ip3: SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203; (1)
2020.10.02 14:14:26 4 : cc1101_ip3: Set_sendMsg, sending : SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 4 : cc1101_ip3: HandleWriteQueue, called
2020.10.02 14:14:27 4 : cc1101_ip3: SendFromQueue, called
2020.10.02 14:14:27 5 : cc1101_ip3: SimpleWrite, SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 4 : cc1101_ip3: SendFromQueue, msg=SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 4 : cc1101_ip3: Read, msg: SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 5 : cc1101_ip3: Parse, noMsg: SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 5 : cc1101_ip3: Read, msg: regexp=.* cmd=sendraw msg=SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 4 : cc1101_ip3: CheckSendrawResponse, sendraw answer: SR;R=6;P0=230;P1=-8740;P2=-1265;P3=-276;D=01020303020302020302030302020303020203020303020203020302030302030203020302030203020302030203020303020203020302030203;
2020.10.02 14:14:27 4 : cc1101_ip3: Read, msg:
2020.10.02 14:14:29 4 : cc1101_ip3: HandleWriteQueue, called
2020.10.02 14:14:29 4 : cc1101_ip3: HandleWriteQueue, nothing to send, stopping timer

Das Device selbst sieht in Fhem genauso aus wie 2 weitere SIGNALs.
Ein Test mit RCSwitch (ReceiveDemo_Advanced_cc1101) funktioniert.

Hat von euch schon einer den D1 mini Pro zum laufen bekommen oder eine IDEE?
Viele Grüße, Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 02 Oktober 2020, 14:37:43
Zitat von: halloaber am 02 Oktober 2020, 14:16:33
IDEE?
Diese D1 mini sind irgendwie nervig. Ich hatte eine ganze Charge, die aus unerfindlichen Gründen nie ging. Von mehreren Händlern, allerdings im gleichen Zeitfenster gekauft. Ich habe dann aufgegeben und mir original Wemos besorgt. Dann ging es auf einmal.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 02 Oktober 2020, 15:11:33
Hallo halloaber,
welche Firmware nutzt du bzw. von welchem Stand hast du sie kompiliert?
Kannst du bitte mal ein List vom Device zusätzlich machen.
Liebe Grüße
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 02 Oktober 2020, 15:20:47
Zitat von: HomeAuto_User am 02 Oktober 2020, 15:11:33
Hallo halloaber,
welche Firmware nutzt du bzw. von welchem Stand hast du sie kompiliert?
Kannst du bitte mal ein List vom Device zusätzlich machen.
Liebe Grüße

hier ist das List vom Dev. Die Firmware ist frisch aus dem GIT.
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        192.168.1.187:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.1.187:23
   FD         320
   FUUID      5f72f4f7-f33f-ae76-d6ac-a8d4786e064f18e8
   IDsNoDispatch 2,72.1,82
   ITClock    250
   LASTDMSG   nothing
   LASTDMSGID nothing
   NAME       cc1101_ip3
   NR         793
   PARTIAL   
   STATE      opened
   TIME       1601641404
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   unknownmessages
   version    V 3.4.0 SIGNALESP cc1101 (chip CC1101) - compiled at Oct  2 2020 14:17:36
   versionProtocols 1.20
   versionmodul v3.4.4_dev+14042020
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2020-10-02 15:18:51   cc1101_config   Freq: 433.920 MHz, Bandwidth: 541 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud
     2020-10-02 15:18:51   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2020-10-02 15:18:51   cc1101_patable  C3E = 00 10 00 00 00 00 00 00
     2020-09-29 11:51:07   cmds            V R t X S P C r W s
     2020-10-02 14:25:19   config          MS=1;MU=1;MC=1;Mred=1
     2020-10-01 18:04:13   freeram         43040
     2020-10-02 15:09:40   ping            OK
     2020-10-02 15:18:50   state           opened
     2020-10-02 09:24:11   uptime          0 00:08:10
   additionalSets:
   helper:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     0.5
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     54.1
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
     98
     99
     104
Attributes:
   addvaltrigger 1
   cc1101_frequency 433.920
   development 0
   hardware   ESP8266cc1101
   icon       it_wireless_dcf77
   room       _TRX
   verbose    1


Viele Grüße, Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 02 Oktober 2020, 22:11:08
Kann es sein, dass es an den PIN Definitionen vielleicht liegt?

GGf. sind die PINs nicht so belege, wie sie nun sein müssten.
Auch wäre interessant, mit welchen Compiler Flags Du compiliert hast.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 02 Oktober 2020, 22:20:28
Zitat von: Sidey am 02 Oktober 2020, 22:11:08
Kann es sein, dass es an den PIN Definitionen vielleicht liegt?

GGf. sind die PINs nicht so belege, wie sie nun sein müssten.
Auch wäre interessant, mit welchen Compiler Flags Du compiliert hast.
Hallo Sidey,
an der Pindef. liegt es nicht, alle Pins mehrfach probiert. D1 D2 und die SPI's
Da aber auch das RCSwitch in der original Version mit den Pins funktioniert, würde ich es ausschließen.
Zwischenzeitlich habe ich auch das fertige HEX von euch installiert - erfolg blieb gleich.

Comp:
esptool.py --port /dev/cu.usbserial-01F93371 write_flash -fm dio 0x00000 Downloads/SIGNALDuino_ESP8266cc11013.4.0.hex

vielleicht hilft das ja.
Viele Grüße, Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 03 Oktober 2020, 11:30:42
Könnte evtl auch ein Timing Problem durch einen unsauberen Hardwareaufbau sein.
Verwendest Du eine Platine, oder fliegende Verdrahtung oder ein Steckbrett?

Zitat2020-10-02 15:18:51   cc1101_config   Freq: 433.920 MHz, Bandwidth: 541 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud
Wenn Du ca 10-20 mal ein "get ccconf" machst, bekommst Du dann immer diese Werte als Antwort?

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 03 Oktober 2020, 11:50:50
Zitat von: Ralf9 am 03 Oktober 2020, 11:30:42
Könnte evtl auch ein Timing Problem durch einen unsauberen Hardwareaufbau sein.
Verwendest Du eine Platine, oder fliegende Verdrahtung oder ein Steckbrett?
Wenn Du ca 10-20 mal ein "get ccconf" machst, bekommst Du dann immer diese Werte als Antwort?

Gruß Ralf


Hallo Ralf,
der Aufbau ist gelötet. Jede Verbindung ca. 3cm lang.
Ich habe auch einen 2. Aufbau mit neuer Hardware auf dem Steckbrett probiert. Auch ohne Erfolg.
Der get Conf funktioniert ohne Probleme. Auch das setzten von Parametern, reset etc. alles ohne Probleme.
Nur halt kein Empfang und kein senden. (was aber mit dem gleichen Aufbau und der RCSwitch Lib funktioniert).

Ich bin ratlos, wo ich ansetzen kann.
Kann ich mir im Code Triggerpunkte setzen um es einzugrenzen?

Viele Grüße, Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 03 Oktober 2020, 12:07:08
Dann kann es doch aber eigentlich nur noch an der Pin-Belegung von RX und TX (GPIO4 und GPIO5) liegen.
Bei manchen Boards ist da wohl die Beschriftung vertauscht.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 03 Oktober 2020, 12:09:52
Zitat von: elektron-bbs am 03 Oktober 2020, 12:07:08
Dann kann es doch aber eigentlich nur noch an der Pin-Belegung von RX und TX (GPIO4 und GPIO5) liegen.
Bei manchen Boards ist da wohl die Beschriftung vertauscht.

Das widerspricht aber doch der Tatsache, dass es mit der RCSwitch Lib funktioniert. ist die gleiche Belegung.
SPI + D1, D2 (GPIO 4,5)

Viele Grüße, Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: halloaber am 03 Oktober 2020, 12:36:42
Zitat von: elektron-bbs am 03 Oktober 2020, 12:07:08
Dann kann es doch aber eigentlich nur noch an der Pin-Belegung von RX und TX (GPIO4 und GPIO5) liegen.
Bei manchen Boards ist da wohl die Beschriftung vertauscht.
Hallo !!

Das wars. D1 und D2 sind vertauscht.
Ich versteh nur nicht, warum RCSwicht empfangen hat. aber egal,
ES GEHT JETZT !!! :-)

Danke, Viele Grüße
Rainer
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FlyingPenguin am 29 Juni 2021, 12:39:27
Hallo,

Ich bekomme demnächst Markisen mit Somfy-Motoren und möchte diese per FHEM steuern. Der Königsweg dazu scheint mir via Signalduino zu sein. Im Wiki steht, dass es von In-Circuit passende (fertige) Module gibt. Leider scheinen diese nicht mehr lieferbar zu sein. Die aktuellen Module setzen nicht mehr auf den C1101, sondern den DW1000.

1. Ich gehe davon aus, dass diese nicht mit dem Signalduino-Modul funktionieren, korrekt?
2. Gibt es irgendwelche anderen Optionen mit fertigen Modulen zu arbeiten? Ich bin eher ein Softwerker als Hardwerker und würde mir gerne die Arbeit mit dem Lötkolben sparen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 30 Juni 2021, 21:27:25
kannst du gar nicht löten? oder nur wenig? willst du den signalduino nehmen oder auf den neuen maple mini umsteigen? (für den signalduino habe ich noch platinen übrig, da müssen wenige teile gelötet werden und dann steckst du die module ein, siehe https://forum.fhem.de/index.php/topic,109351.0.html ).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Juni 2021, 21:42:45
ZitatIch bekomme demnächst Markisen mit Somf y-Motoren und möchte diese per FHEM steuern
Wenn es Somfy RTS sind, da geht der SIGNALDuino,
wenn es aber Somfy io (verschlüsselt und bidirektional) sind, dann geht der SIGNALDuino nicht, da brauchst Du dann ein Gateway
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: FlyingPenguin am 03 Juli 2021, 17:41:24
Ich kann schon löten, mir wäre ein fertiges Modul einfach lieber, weil da weniger schief gehen kann.

Der Hinweis auf somfy io ist sehr gut, das hatte ich gar nicht auf dem Schirm. Ich weiß (noch) nicht welcher Motor genau verbaut ist. Von daher warte ich mal erst diese Entscheidung ab.

EDIT: Inzwischen weiß ich, dass Somfy io-Motoren verbaut sind. Ich werde mich also sowieso mit einem Gateway auseinander setzen müssen.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: jump am 11 Juli 2021, 11:48:01
Hallo,

ich habe meinen Raspi mit FHEM aufgesetzt, um meine Pergola-Antriebe (SOMFY) mit dem SignalDuino zu steuern.

Die SOMFY-Antriebe für die seitlichen Screens konnte ich problemlos integrieren.
Den Antrieb für die Verstellung der Lamellen das Dachs jedoch nicht.
In der Pergola ist für das Dach nochmal extra ein Kasten mit Elektronik verbaut. Der Antrieb selber scheint mit 24V zu laufen.
Nichtsdestotrotz kann ich alle Antriebe, auch den für's Dach, mit meiner vorhandenen Somfy-RTS-Fernbedienung steuern.
Daher hätte ich erwartet, dass ich eben auch das Dach per FHEM und SignalDuino anlernen kann.

Könnte es an einer Einstellung des in FHEM definierten Geräts (Shutter) liegen?
Hat jemand eine Idee?

Vielen Dank!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Blauhorn am 26 September 2021, 16:32:17
Guten Abend die Gemeinschaft,

könnte mir mal jemand bitte auf die Sprünge helfen, bei folgendem Problem:

ich habe kürzlich meinen nanoCUL 433 zu einem Signalduino umfunktioniert. Das hat genau 3 Tage gut geklappt, alle Geräte da, sogar noch ein paar mehr.
Dann wollte ich ein stures Gerät aber unbedingt auch rankriegen, und habe daher um den Signalempfang etwas zu verbessern, die cc1101_bWidth Stück für Stück erhöht, solange bis ich bei 812k angekommen war.
Das vermisste Signal habe ich immer noch nicht gesehen, dafür hat sich wahrscheinlich der Nano verabschiedet. Kann das sein?
Nach reset kommt Status "open", danach "No Signalduino found", dies ein paar mal hin und her und schlussendlich "closed".
Tot.
Ich habe den ein paar mal neu geflasht, auf verschiedenen Systemen, der Nano scheint in Takt zu sein, aber Fhem bringt immer nur das gleiche Stereotyp.
Kann ich den noch irgendwie retten, bzw. wo kann ich denn da nach dem Start ein Fehelr-Log ansehen?


Beste Grüße
vom Blauhorn
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 26 September 2021, 20:32:23
Das hört sich nach einem hardware-Fehler an. Ist der neu gekauft? Dann: https://forum.fhem.de/index.php/topic,122159.0.html (https://forum.fhem.de/index.php/topic,122159.0.html)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Blauhorn am 26 September 2021, 22:13:02
Das Gerät war als nanoCUL seit 2014 im Einsatz, bis Freitag fehlerfrei. Ich habe mal jetzt neu bestellt und werde dann berichten.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Blauhorn am 28 September 2021, 23:01:13
So, der neue nanoCUL kam heute und ließ sich problemlos einbinden.
Nun aber:
Mit dem Alten war ich froh, dass ich eine Funklingel fast ohne Zutun integrieren konnte. Ich habe bei dem neuen exact die gleiche Firmware-Version und in der Klingel nur das IODev geändert.
Die anderen Geräte, so einige Taster und Thermometer werden richtig erkannt.
Welche Sendeeinstellungen kommen in Frage, weiß hier jemand Rat?
Internals:
   CFGFN     
   DEF        32 BE5D93
   FUUID      614b5613-f33f-2f64-da04-c0fe28935cfef63e
   FVERSION   14_SD_BELL.pm:v1.0.0-s24840/2021-08-09
   IODev      sduino433
   NAME       Carogong
   NR         13252
   STATE      ring
   TYPE       SD_BELL
   bitMSG     
   lastMSG   
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1632850914.31433
           VALUE      ring
   READINGS:
     2021-09-28 19:27:12   IODev           sduino433
     2021-09-28 19:41:54   state           ring
Attributes:
   IODev      sduino433
   model      FreeTec_PE-6946
   room       Garage



Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@57600
   DMSG       sC9F0EDA000
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@57600
   FD         52
   FUUID      61534eb0-f33f-2f64-459c-fdc94c0799a7dd91
   IDsNoDispatch 2,72.1,82
   ITClock    250
   LASTDMSG   sC9F0EDA000
   LASTDMSGID 0
   MSGCNT     733
   NAME       sduino433
   NR         49892
   NR_CMD_LAST_H 19
   PARTIAL   
   RAWMSG     MS;P1=478;P2=-9548;P3=-4530;P4=-1972;D=1213131414131414131313131314141414131313141313141313141314;CP=1;SP=2;R=246;O;m2;
   RSSI       -79
   STATE      opened
   TIME       1632862641.91994
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   version    V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15
   versionProtocols 1.21
   versionmodul v3.4.4
   DoubleMsgIDs:
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1632849732.84913
           VALUE      opened
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2021-09-28 21:44:27   cc1101_config   Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud
     2021-09-28 21:44:27   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2021-09-28 19:22:15   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2021-09-28 21:43:45   cmds             V R t X S P C r W s x e
     2021-09-28 21:42:56   config          MS=1;MU=1;MC=1;Mred=1
     2021-09-28 21:44:03   freeram         919
     2021-09-28 19:22:12   state           opened
   XMIT_TIME:
     1632850179.50169
     1632850257.40225
     1632850321.388
     1632850408.29669
     1632850564.50345
     1632850580.5486
     1632850601.66878
     1632850609.4678
     1632850624.89905
     1632850638.04159
     1632850743.61392
     1632850769.19101
     1632850775.70246
     1632850777.71621
     1632850781.0857
     1632850783.27525
     1632850787.56256
     1632850839.80005
     1632850914.56644
   additionalSets:
     flash      3.4.0,3.3.1
   helper:
     avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex 2>./log/SIGNALduino-Flash.log
     avrdudelogs flashing Arduino sduino433
hex file: FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex
port: /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex 2>[LOGFILE] || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex 2>[LOGFILE]

sduino433 closed
--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.3
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"

         Using Port                    : /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex"
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex auto detected as Intel Hex
avrdude: writing flash (25626 bytes):

Writing | ################################################## | 100% 3.85s

avrdude: 25626 bytes of flash written
avrdude: verifying flash memory against FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex:
avrdude: load data flash data from input file FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex:
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex auto detected as Intel Hex
avrdude: input file FHEM/firmware/SIGNALDuino_nanocc11013.4.0.hex contains 25626 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.96s

avrdude: verifying ...
avrdude: 25626 bytes of flash verified

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino433 reopen started

   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     0.5
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     54.1
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
     98
     99
     104
     105
Attributes:
   hardware   nanoCC1101
   room       System
   verbose    4
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 06 Oktober 2021, 10:46:58
Hallo Blauhorn,

Zitat von: Blauhorn am 28 September 2021, 23:01:13
...
Nun aber:
Mit dem Alten war ich froh, dass ich eine Funklingel fast ohne Zutun integrieren konnte. Ich habe bei dem neuen exact die gleiche Firmware-Version und in der Klingel nur das IODev geändert.
Die anderen Geräte, so einige Taster und Thermometer werden richtig erkannt.
Welche Sendeeinstellungen kommen in Frage, weiß hier jemand Rat?
...

Was genau ist dein Problem aktuell?
Ich lese einmal heraus
1) eine Fragestellung ob jemand dir die Sendeeinstellungen sagen kann
oder
2) ein Rat wieso die Klingel nicht klingelt?

Kannst du die Klingel denn empfangen korrekt in deinem Device?

Sollte sie nicht klingeln bei einem anderem Empfänger kann es zum einen die neue Hardware sein.
Da können die  Parameter / Frequenz etwas abweichen zum Vprgänger.
Es kann eine minimale Änderung des Standortes sein weil ggf eine andere Antenne dran ist.

Du kannst auch gern die Sendewiederholungen (Repeats) erhöhen und dann sehen ob das Signal an deinem Device beim klingeln ankommt.

LG
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Blauhorn am 10 Oktober 2021, 15:17:50
Hallo HomeAuto_User,

danke für die Antwort, und da habe ich mich wohl etwas unkonkret ausgedrückt.
Also ja, die Klingel klingelt mit der neuen Hardware nicht mehr. Ich wusste nicht, dass die cc1101s alle auch so unterschiedlich senden.
Der zugehörige Klingeltaster wird allerdings erkannt.
Dafür wurde jetzt aber auch der TedsenSKX2XX vom Garagentor erkannt und angelegt, dort "hört" das zugehörige Tor jedoch nur alle 5-8 mal, wenn ich über Fhem den Button 2 auslöse.
Mysteriös oder ich hab die ganze Mechanik dahinter noch nicht verstanden.
Ich werde jetzt die Repeats mal schrittweise erhöhen und auch den Standort variieren. Mal sehen, was passiert.
Gruß
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: McShire am 10 Oktober 2021, 22:40:45
Hallo Blauhorn,
lade doch mal FreqTest oder FreqTestPing in den CUL, dann wird die Frequenz im Register auf den Frequenzgang des CC1101 eingestellt.
Vielleicht liegt der neue CUL etwas anders als der alte CUL.

Beim alten CUL ist es vielleicht auch, dass der CUL nach dem Umstecken nicht mehr erkannt wird. Hat dieser einen FTDI-Chip oder einen CH340.
Bei einem CH340 sieh mal hier nach: https://www.smarthome-agentur.de/blog/tutorial-mehrere-nanocul-ohne-eindeutige-id-verwenden-ch340-chip/

Viele Grüße
Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Blauhorn am 12 Oktober 2021, 07:37:08
Hallo Werner,

Danke für die Antwort.  Sowohl alter als auch neuer cul haben einen FTDI. Die USB-Erkennung haut ja auch hin. Ich versuche erstmal eine Verbesserung durch Erhöhung der repeats und dann werden die Testsketches zu Rate gezogen.

Gruß
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 19 November 2021, 22:56:55
Hallo zusammen,

habe einen Signalduino mit CC1101 und einem Arduino ProMini 3,3V 8MHz gebaut und mit der entsprechenden selbstcompilierten FW programmiert.
Ziel ist es Simu HZ Rolläden (sollen kompatibel zu Somfy RTS sein) zu steuern, jedoch leider bekomme ich den sduino nicht am Rolladen angelernt.

Was funktioniert ist die Steuerung von Intertechno Steckdosen, somit bin ich der Meinung, daß die HW eigentlich OK sein sollte.
Die Steckdosen wurden über autocreate mit einer Fernbedienung angelegt.
Habe schon zwei unterschiedliche CC1101 Modul versucht, konnte jedoch keinen Unterschied feststellen.

Habt ihr irgendwelche Tipps was ich noch alles tun kann?
Bin mometan ziemlich ratlos.

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 November 2021, 09:02:12
Du müsstest mal genauer beschreiben, was du getan hast, was die Logs sagen und dann auch das List zeigen (bitte in Tags, das ist der #-knopf oben).
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 20 November 2021, 09:52:02
Also hier mal die Lists:

Signalduino:

Internals:
   Clients    :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
   DEF        /dev/tty_signalduino@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/tty_signalduino@57600
   FD         17
   FUUID      61956959-f33f-62d8-fa27-2ffa1db4761ce0eb
   ITClock    250
   LASTDMSG   nothing
   LASTDMSGID nothing
   NAME       mySignalduino
   NR         290
   NR_CMD_LAST_H 3
   PARTIAL   
   STATE      opened
   TIME       1637394404.51302
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   unknownmessages 2021-11-20 09:01:43-MU;P0=-13448;P1=2451;P2=-2526;P3=4716;P4=-1272;P5=1266;P6=-651;P7=627;D=1212121212121234545676767676745676745676745676745676745676745676767476765454567674547656767456767470;CP=7;R=248;#2021-11-20 09:01:43-MU;P0=144;P1=2445;P2=-2534;P3=4752;P4=-1287;P5=1262;P6=-641;P7=636;D=1212121212121234545676767676745676745676745676745676745676745676767476760;CP=7;R=249;#2021-11-20 09:01:43-MU;P0=-15280;P1=2450;P2=-2527;P3=4752;P4=-1282;P5=1270;P6=-643;P7=631;D=12121212121212345456767676767456767456767456767456767456767456767674767650;CP=7;R=254;#2021-11-20 09:01:43-MU;P0=636;P1=1301;P2=-2568;P3=2404;P4=4752;P5=-1276;P7=-643;D=1232324515170707070705170705170705170705170705170705170707050707151517070515071707;CP=0;R=233;#2021-11-20 09:01:50-MU;P0=-1286;P1=1268;P2=-635;P3=638;P4=-26692;P5=2436;P6=-2539;P7=4752;D=01232301232301232301232301232301232323032321010123230103212323012323034565656565656567010123232323230123230123230123230123230123230123232303232101012323010321232301232303456565656565656701012323232323012323012323012323012323012323012323230323210101232301;CP=3;R=249;O;#2021-11-20 09:01:50-MU;P0=1271;P1=-646;P2=635;P3=1872;P4=-2557;P5=2414;P6=4768;P7=-1283;D=345454546707012121212127012127012127012127012127012127012121272121;CP=2;R=242;#2021-11-20 09:01:50-MU;P0=-26712;P1=2433;P2=-2548;P3=4744;P4=-1286;P5=1267;P6=-645;P7=626;D=0121212121212123454567676767674567674567674567674567674567674567676747676545456767454765676;CP=7;R=235;#2021-11-20 09:01:54-MU;P0=4756;P1=-1291;P2=1264;P3=-657;P4=619;P5=-26692;P6=2450;P7=-2530;D=12123434343434123434123434123434123434123434123434341434321212343412143234341234341456767676767676701212343434343412343412343412343412343412343412343434143432121234341214323434123434145676767676767670121234343434341234341234341234341234341234341234343414;CP=4;R=248;O;#2021-11-20 09:01:54-MU;P0=-639;P1=1266;P2=-1285;P3=696;P4=-26668;P5=2438;P6=-2539;P7=4752;D=01212121030321230103032103032345656565656565672121030303030321030321030321030321030321030321230103032103032343;CP=3;R=249;#2021-11-20 09:01:54-MU;P0=1648;P1=-1284;P2=2441;P3=-2534;P4=4768;P5=1269;P6=-642;P7=632;D=01232323232323415156767676767156767156767156767156767156767156767671767651515676715176567671;CP=7;R=246;#2021-11-20 09:16:55-MU;P0=626;P1=-26724;P2=2453;P3=-2525;P4=4748;P5=-1278;P6=1275;P7=-641;D=2323456567070707070567070567070567070567070567070567070705070765656707056507670705670705012323232323232345656707070707056707056707056707056707056707056707070507076565670705650767070567070501;CP=0;R=248;#2021-11-20 09:16:55-MU;P0=635;P1=-1288;P2=1262;P3=-639;P4=-26648;P5=2440;P6=-2546;P7=4740;D=012303010456767121230303030301230301230301230301230301230301230303010303212123030121032303012303010456712123030303030123030123030123030123030123030123030301030321212303012;CP=0;R=248;#2021-11-20 09:16:55-MU;P0=-1282;P1=1265;P2=-655;P3=629;P4=-26712;P5=2438;P6=-2536;P7=4752;D=010123230103230345656565656565670101232323232301232301232301232301232301232301232323032321010123230103;CP=3;R=245;#2021-11-20 09:16:58-MU;P0=624;P1=-2620;P2=2344;P3=4712;P4=-1275;P5=1275;P6=-640;D=01213454560606060604560604560604560604560604560604560606040606545456060454065606045606040;CP=0;R=249;#2021-11-20 09:16:58-MU;P0=-2524;P1=2448;P2=4784;P3=-1272;P4=1270;P5=-631;P6=634;P7=-24976;D=01023434565656565634565634565634565634565634565634565656365654343456563436545656345656367;CP=6;R=247;#2021-11-20 09:16:59-MU;P0=-628;P1=632;P2=-1272;P3=1289;P4=-26704;P5=1712;D=0101010101230101230101230101230101230101230101012101032323010123210301012301012145;CP=1;R=248;#2021-11-20 09:16:59-MU;P0=-2532;P1=2448;P2=4768;P3=-1268;P4=1280;P5=-629;P6=632;D=0102343456565656563456563456563456563456563456563456565636565434345656343654565634565636;CP=6;R=248;#2021-11-20 09:17:03-MU;P0=2437;P1=-2543;P2=4748;P3=-1284;P4=1261;P5=-646;P6=634;P7=-26688;D=12343456565656563456563456563456563456563456563456565636565434345656343654565634565636701010101010101234345656565656345656345656345656345656345656345656563656543434565634365456563456563670101010101010123434565656565634565634565634565634565634565634565656;CP=6;R=248;O;#2021-11-20 09:17:03-MU;P0=-1288;P1=637;P2=-644;P3=1252;P4=-26712;P5=2435;P6=-2547;P7=4728;D=012321210321210145656565656565670303212121212103212103212103212103212103212103212121012;CP=1;R=247;#2021-11-20 09:17:03-MU;P0=631;P1=-640;P2=-1293;P3=1272;D=0102310102310102310102310102310101020101323231010232013101023101;CP=0;R=238;#2021-11-20 09:17:07-MU;P0=344;P1=-9872;P2=4728;P3=-1271;P4=1279;P5=-635;P6=628;P7=-26680;D=2343456565656563456563456563456563456563456563456565636565434345656343654565634565636701;CP=6;R=248;#2021-11-20 09:17:07-MU;P0=635;P1=-2552;P2=2424;P3=4752;P4=-1285;P5=1273;P6=-643;D=012134545606060606045606045606045606045606045606045606060406065454560604540656060456060;CP=0;R=249;#2021-11-20 09:17:07-MU;P0=-660;P1=601;P2=-1289;P3=1253;P4=-26696;D=010101230101230101230101230101230101230101012101032323010123210301012301012143;CP=1;R=249;#2021-11-20 09:17:07-MU;P0=610;P1=-636;P2=-1283;P3=1278;P4=-26672;P5=2452;P6=-2529;D=01010231010231010231010231010231010231010102010132323101023201310102310102045656565656;CP=0;R=248;#2021-11-20 09:17:08-MU;P0=-647;P1=629;P2=-1274;P3=1275;P4=-6808;P5=136;P6=-2064;D=010123010123010123010123010101210103232301012321456;CP=1;R=247;
   version    V 3.4.0 SIGNALduino cc1101 (chip CC1101) DBG - compiled at Nov 19 2021 13:23:22
   versionProtocols 1.38
   versionmodul 3.5.2+20211103
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     31:KOPP_FC ^kr\w{18,}
     32:PCA301  ^\S+\s+24
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2021-11-20 08:58:54   cc1101_config   Freq: 433.420 MHz, Bandwidth: 650 kHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5.60 kBaud
     2021-11-20 08:58:54   cc1101_config_ext Modulation: ASK/OOK
     2021-11-20 08:58:55   cc1101_patable  C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
     2021-11-17 22:34:21   cmds            V R t X S P C r W s
     2021-11-17 22:33:58   config          MS=1;MU=1;MC=1;Mred=1
     2021-11-18 16:11:10   freeram         554
     2021-11-20 09:24:54   ping            OK
     2021-11-20 08:58:53   state           opened
     2021-11-17 22:33:42   uptime          0 00:50:32
   XMIT_TIME:
     1637395168.91748
     1637395170.92838
     1637395287.9346
   additionalSets:
   helper:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   mnIdList:
     100
     101
     102
     103
     108
     112
     115
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     0.5
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     54.1
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
     106
     113
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     78
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
     98
     99
     104
     105
     110
     111
     114
Attributes:
   DbLogExclude .*
   cc1101_frequency 433.42
   hardware   nanoCC1101
   icon       cul_usb
   room       Schnittstellen->Gateways,Status,test
   updateChannelFW stable
   verbose    5
   whitelist_IDs 0,0.1,0.2,0.3,0.4,0.5,1,3,3.1,4,6,7,8,9,10,11,12,13,13.1,13.2,14,15,16,17,17.1,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,33.1,33.2,34,35,36,37,38,39,40,41,42,43,44,44.1,45,46,47,48,49,49.1,49.2,50,51,52,53,54,54.1,55,56,57,58,59,60,61,62,64,65,66,67,68,69,70,71,72,73,74,74.1,76,78,79,80,81,83,84,85,86,87,88,89,90,91,91.1,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,108,110,111,112,113,114,115


Somfy:

Internals:
   ADDRESS    881002
   DEF        881002
   FUUID      61956f6d-f33f-62d8-e980-225aa31d1e2fcda4
   IODev      mySignalduino
   NAME       AZ_rolladen
   NR         291
   STATE      open
   TYPE       SOMFY
   move       prog
   CODE:
     1          881002
   READINGS:
     2021-11-20 08:46:44   IODev           mySignalduino
     2021-11-20 09:01:27   enc_key         AC
     2021-11-20 09:01:27   exact           0
     2021-11-20 09:01:27   position        0
     2021-11-20 09:01:27   rolling_code    0001
     2021-11-20 09:01:27   state           open
Attributes:
   DbLogExclude .*
   IODev      mySignalduino
   icon       shutter_5
   loglevel   6
   model      somfyshutter
   room       Innen->OG Buero,Schnittstellen->SignalDuino,Status,test
   verbose    5


Log nach Reset:

2021.11.20 09:29:11.875 3: mySignalduino: ResetDevice, nanoCC1101
2021.11.20 09:29:11.880 3: Opening mySignalduino device /dev/tty_signalduino
2021.11.20 09:29:11.882 3: Setting mySignalduino serial parameters to 57600,8,N,1
2021.11.20 09:29:11.886 1: mySignalduino: DoInit, /dev/tty_signalduino@57600
2021.11.20 09:29:11.886 3: mySignalduino device opened
2021.11.20 09:29:13.386 3: mySignalduino: SimpleWrite_XQ, disable receiver (XQ)
2021.11.20 09:29:13.386 5: mySignalduino: SimpleWrite, XQ
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: Reading values from EEPROM..done
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: Reading values from EEPROM..done
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: dump
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: dump
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: EEPROM=33 1d 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00 10
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: EEPROM=33 1d 0d 2e 2d 07 d3 91 3d 04 32 00 00 06 00 10
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: ab 85 17 c4 30 23 b9 00 07 00 18 14 6c 07 00 90
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: ab 85 17 c4 30 23 b9 00 07 00 18 14 6c 07 00 90
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: 87 6b f8 b6 11 e9 2a 00 1f 41 00 ff ff ff ff ff
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: 87 6b f8 b6 11 e9 2a 00 1f 41 00 ff ff ff ff ff
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: 00 c0 00 00 00 00 00 00
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: 00 c0 00 00 00 00 00 00
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: CCVersion =0x4
2021.11.20 09:29:13.408 5: mySignalduino: Parse, noMsg: CCVersion =0x4
2021.11.20 09:29:13.408 4: mySignalduino: Read, msg: CCPartnum =0x0
2021.11.20 09:29:13.409 5: mySignalduino: Parse, noMsg: CCPartnum =0x0
2021.11.20 09:29:13.409 4: mySignalduino: Read, msg: cc1101 found
2021.11.20 09:29:13.409 5: mySignalduino: Parse, noMsg: cc1101 found
2021.11.20 09:29:13.409 4: mySignalduino: Read, msg: Starting timerjob
2021.11.20 09:29:13.409 5: mySignalduino: Parse, noMsg: Starting timerjob
2021.11.20 09:29:13.468 4: mySignalduino: Read, msg: cc1101 _PKTCTRL0=50 vs initval PKTCTRL0=50
2021.11.20 09:29:13.468 5: mySignalduino: Parse, noMsg: cc1101 _PKTCTRL0=50 vs initval PKTCTRL0=50
2021.11.20 09:29:13.468 4: mySignalduino: Read, msg: cc1101 _IOCFG2=13 vs initval IOCFG2=13
2021.11.20 09:29:13.468 5: mySignalduino: Parse, noMsg: cc1101 _IOCFG2=13 vs initval IOCFG2=13
2021.11.20 09:29:13.886 3: mySignalduino: StartInit, get version, retry = 0
2021.11.20 09:29:13.886 5: mySignalduino: SimpleWrite, V
2021.11.20 09:29:13.913 4: mySignalduino: Read, msg: receiver enabledV 3.4.0 SIGNALduino cc1101 (chip CC1101) DBG - compiled at Nov 19 2021 13:23:22
2021.11.20 09:29:13.914 5: mySignalduino: Parse, noMsg: receiver enabledV 3.4.0 SIGNALduino cc1101 (chip CC1101) DBG - compiled at Nov 19 2021 13:23:22
2021.11.20 09:29:13.914 5: mySignalduino: Read, msg: regexp=V\s.*SIGNAL(?:duino|ESP|STM).*(?:\s\d\d:\d\d:\d\d) cmd=version msg=receiver enabledV 3.4.0 SIGNALduino cc1101 (chip CC1101) DBG - compiled at Nov 19 2021 13:23:22
2021.11.20 09:29:13.914 5: mySignalduino: CheckVersionResp, called with receiver enabledV 3.4.0 SIGNALduino cc1101 (chip CC1101) DBG - compiled at Nov 19 2021 13:23:22
2021.11.20 09:29:13.917 2: mySignalduino: CheckVersionResp, initialized 3.5.2+20211103
2021.11.20 09:29:13.917 5: mySignalduino: SimpleWrite, XE
2021.11.20 09:29:13.927 3: mySignalduino: CheckVersionResp, enable receiver (XE)
2021.11.20 09:29:13.927 5: mySignalduino: CheckVersionResp, cc1101 available
2021.11.20 09:29:13.927 5: mySignalduino: Get_delayed, ccconf delayed
2021.11.20 09:29:13.927 5: mySignalduino: Get_delayed, ccpatable delayed
2021.11.20 09:29:14.678 5: mySignalduino: Get_delayed, ccconf executed
2021.11.20 09:29:14.678 5: mySignalduino: Get_Command ccconf executed
2021.11.20 09:29:14.678 5: mySignalduino: AddSendQueue, mySignalduino: C0DnF (1)
2021.11.20 09:29:14.678 5: mySignalduino: Get_delayed, ccpatable delayed
2021.11.20 09:29:14.678 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:29:14.678 4: mySignalduino: SendFromQueue, called
2021.11.20 09:29:14.678 5: mySignalduino: SimpleWrite, C0DnF
2021.11.20 09:29:14.697 4: mySignalduino: Read, msg: C0Dn11=10AB8517C43023B900070018146C070090
2021.11.20 09:29:14.697 5: mySignalduino: Parse, noMsg: C0Dn11=10AB8517C43023B900070018146C070090
2021.11.20 09:29:14.697 5: mySignalduino: Read, msg: regexp=C0Dn11=[A-F0-9a-f]+ cmd=ccconf msg=C0Dn11=10AB8517C43023B900070018146C070090
2021.11.20 09:29:14.989 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:29:14.989 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer
2021.11.20 09:29:15.430 5: mySignalduino: Get_delayed, ccpatable executed
2021.11.20 09:29:15.430 5: mySignalduino: Get_Command ccpatable executed
2021.11.20 09:29:15.430 5: mySignalduino: AddSendQueue, mySignalduino: C3E (1)
2021.11.20 09:29:15.431 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:29:15.431 4: mySignalduino: SendFromQueue, called
2021.11.20 09:29:15.431 5: mySignalduino: SimpleWrite, C3E
2021.11.20 09:29:15.449 4: mySignalduino: Read, msg: C3E = 00 C0 00 00 00 00 00 00
2021.11.20 09:29:15.449 5: mySignalduino: Parse, noMsg: C3E = 00 C0 00 00 00 00 00 00
2021.11.20 09:29:15.449 5: mySignalduino: Read, msg: regexp=^C3E\s=\s.* cmd=ccpatable msg=C3E = 00 C0 00 00 00 00 00 00
2021.11.20 09:29:15.449 3: mySignalduino: CheckCcpatableResponse, patable: C0
2021.11.20 09:29:15.449 5: mySignalduino: CheckCcpatableResponse, patable: 10_dBm

jump to the top


Log nach Anlernversuch, wobei der Rolladen das Anlernen nicht "quittiert".

2021.11.20 09:30:49.089 4: mySignalduino: Read, msg: MC;LL=-1278;LH=1232;SL=-629;SH=606;D=33AFFDE00830;C=624;L=45;R=240;
2021.11.20 09:30:49.089 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 624 RSSI = -82 -> Oregon Scientific PIR
2021.11.20 09:30:49.089 5: mySignalduino: Parse_MC, extracted data 110011000101000000000010000111111111011111001111 (bin)
2021.11.20 09:30:49.089 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 09:30:57.535 4: SOMFY_set: AZ_rolladen -> entering with mode :send: cmd :prog:  arg1 ::  pos :0:
2021.11.20 09:30:57.535 4: SOMFY_set: handled command prog --> move :prog:  newState :open:
2021.11.20 09:30:57.535 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2021.11.20 09:30:57.539 4: SOMFY_sendCommand: AZ_rolladen -> cmd :prog:
2021.11.20 09:30:57.539 4: SOMFY_send AZ_rolladen prog: sAD800002881002
2021.11.20 09:30:57.539 5: SOMFY_send AZ_rolladen enc key : AD  rolling code : 0002
2021.11.20 09:30:57.539 5: mySignalduino: Write, sending via Set sendMsg P43#AD2323212333BB#R6
2021.11.20 09:30:57.539 5: mySignalduino: Set_sendMsg, msg=P43#AD2323212333BB#R6
2021.11.20 09:30:57.539 5: mySignalduino: Set_sendMsg, Preparing manchester protocol=43, repeats=0, clock=645 data=AD2323212333BB
2021.11.20 09:30:57.539 5: mySignalduino: AddSendQueue, mySignalduino: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A; (1)
2021.11.20 09:30:57.539 4: mySignalduino: Set_sendMsg, sending : SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A;
2021.11.20 09:30:57.540 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:30:57.540 4: mySignalduino: SendFromQueue, called
2021.11.20 09:30:57.540 5: mySignalduino: SimpleWrite, SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A;
2021.11.20 09:30:57.550 4: mySignalduino: SendFromQueue, msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A;
2021.11.20 09:30:57.550 4: mySignalduino: Read, msg: send cmd detected 2
2021.11.20 09:30:57.550 5: mySignalduino: Parse, noMsg: send cmd detected 2
2021.11.20 09:30:57.550 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=send cmd detected 2
2021.11.20 09:30:57.621 4: mySignalduino: Read, msg: rearrange beginptr
2021.11.20 09:30:57.621 5: mySignalduino: Parse, noMsg: rearrange beginptr
2021.11.20 09:30:57.622 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=rearrange beginptr
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: SC;Adding repeats: 6
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: SC;Adding repeats: 6
2021.11.20 09:30:57.622 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=SC;Adding repeats: 6
2021.11.20 09:30:57.622 4: mySignalduino: CheckSendrawResponse, sendraw answer: SC;Adding repeats: 6
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: R=6;Adding raw
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: R=6;Adding raw
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: Adding bucket
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: Adding bucket
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: Adding bucket
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: Adding bucket
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: Adding bucket
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: Adding bucket
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: locating data start:10101010101010113; end:;
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: locating data start:10101010101010113; end:;
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: Adding manchester
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: Adding manchester
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: adding sendclock
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: adding sendclock
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: locating data start:AD2323212333BB; end:;
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: locating data start:AD2323212333BB; end:;
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: write new ccregs #5
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: write new ccregs #5
2021.11.20 09:30:57.622 4: mySignalduino: Read, msg: 10AB85550A
2021.11.20 09:30:57.622 5: mySignalduino: Parse, noMsg: 10AB85550A
2021.11.20 09:30:57.623 4: mySignalduino: Read, msg: repeat 0/5 cmd 0/2 reps 6
2021.11.20 09:30:57.623 5: mySignalduino: Parse, noMsg: repeat 0/5 cmd 0/2 reps 6
2021.11.20 09:30:57.623 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:57.623 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:57.637 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:57.638 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:57.701 4: mySignalduino: Read, msg: .
2021.11.20 09:30:57.701 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:57.717 4: mySignalduino: Read, msg: repeat 1/5 cmd 0/2 reps 6
2021.11.20 09:30:57.718 5: mySignalduino: Parse, noMsg: repeat 1/5 cmd 0/2 reps 6
2021.11.20 09:30:57.718 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:57.718 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:57.749 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:57.749 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:57.829 4: mySignalduino: Read, msg: .
2021.11.20 09:30:57.829 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:57.829 4: mySignalduino: Read, msg: repeat 2/5 cmd 0/2 reps 6
2021.11.20 09:30:57.829 5: mySignalduino: Parse, noMsg: repeat 2/5 cmd 0/2 reps 6
2021.11.20 09:30:57.829 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:57.829 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:57.878 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:57.878 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:57.941 4: mySignalduino: Read, msg: .
2021.11.20 09:30:57.941 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:57.942 4: mySignalduino: Read, msg: repeat 3/5 cmd 0/2 reps 6
2021.11.20 09:30:57.942 5: mySignalduino: Parse, noMsg: repeat 3/5 cmd 0/2 reps 6
2021.11.20 09:30:57.957 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:57.957 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:57.989 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:57.989 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:58.053 4: mySignalduino: Read, msg: .
2021.11.20 09:30:58.053 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:58.069 4: mySignalduino: Read, msg: repeat 4/5 cmd 0/2 reps 6
2021.11.20 09:30:58.069 5: mySignalduino: Parse, noMsg: repeat 4/5 cmd 0/2 reps 6
2021.11.20 09:30:58.069 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:58.069 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:58.101 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:58.101 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:58.181 4: mySignalduino: Read, msg: .
2021.11.20 09:30:58.181 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:58.181 4: mySignalduino: Read, msg: repeat 5/5 cmd 0/2 reps 6
2021.11.20 09:30:58.181 5: mySignalduino: Parse, noMsg: repeat 5/5 cmd 0/2 reps 6
2021.11.20 09:30:58.181 4: mySignalduino: Read, msg: . cmd 1/2 reps 1
2021.11.20 09:30:58.181 5: mySignalduino: Parse, noMsg: . cmd 1/2 reps 1
2021.11.20 09:30:58.213 4: mySignalduino: Read, msg: . cmd 2/2 reps 1
2021.11.20 09:30:58.213 5: mySignalduino: Parse, noMsg: . cmd 2/2 reps 1
2021.11.20 09:30:58.308 4: mySignalduino: Read, msg: .
2021.11.20 09:30:58.308 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:30:58.308 4: mySignalduino: Read, msg: ccreg write back
2021.11.20 09:30:58.308 5: mySignalduino: Parse, noMsg: ccreg write back
2021.11.20 09:30:58.308 4: mySignalduino: Read, msg: SC;
2021.11.20 09:30:58.308 5: mySignalduino: Parse, noMsg: SC;
2021.11.20 09:30:58.308 4: mySignalduino: Read, msg: F
2021.11.20 09:30:58.309 5: mySignalduino: Parse, noMsg: F
2021.11.20 09:30:58.309 4: mySignalduino: Read, msg: SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A;
2021.11.20 09:30:58.309 5: mySignalduino: Parse, noMsg: SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=AD2323212333BB;F=10AB85550A;
2021.11.20 09:30:58.309 4: mySignalduino: Read, msg:
2021.11.20 09:30:59.550 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:30:59.550 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer


Log schalten einer Intertechno Steckdose (an/aus) was funktioniert.

2021.11.20 09:32:37.497 3: mySignalduino IT_set: IT_F0000F0FFF on
2021.11.20 09:32:37.503 5: mySignalduino: Write, sending via Set sendMsg P3#isF0000F0FFF0F#R6
2021.11.20 09:32:37.503 5: mySignalduino: Set_sendMsg, msg=P3#isF0000F0FFF0F#R6
2021.11.20 09:32:37.503 5: mySignalduino: Set_sendMsg, IT V1 convertet tristate to bits=010000000001000101010001
2021.11.20 09:32:37.503 5: mySignalduino: Set_sendMsg, Preparing rawsend command for protocol=3, repeats=6, clock=250 bits=010000000001000101010001
2021.11.20 09:32:37.504 5: mySignalduino: AddSendQueue, mySignalduino: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304040423; (1)
2021.11.20 09:32:37.504 4: mySignalduino: Set_sendMsg, sending : SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304040423;
2021.11.20 09:32:37.505 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:32:37.505 4: mySignalduino: SendFromQueue, called
2021.11.20 09:32:37.505 5: mySignalduino: SimpleWrite, SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304040423;
2021.11.20 09:32:37.516 4: mySignalduino: SendFromQueue, msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304040423;
2021.11.20 09:32:37.516 4: mySignalduino: Read, msg: send cmd detected 2
2021.11.20 09:32:37.516 5: mySignalduino: Parse, noMsg: send cmd detected 2
2021.11.20 09:32:37.516 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=send cmd detected 2
2021.11.20 09:32:37.516 4: mySignalduino: Read, msg: Adding raw
2021.11.20 09:32:37.516 5: mySignalduino: Parse, noMsg: Adding raw
2021.11.20 09:32:37.516 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=Adding raw
2021.11.20 09:32:37.570 4: mySignalduino: Read, msg: rearrange beginptr
2021.11.20 09:32:37.570 5: mySignalduino: Parse, noMsg: rearrange beginptr
2021.11.20 09:32:37.570 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=rearrange beginptr
2021.11.20 09:32:37.570 4: mySignalduino: Read, msg: SR;Adding repeats: 6
2021.11.20 09:32:37.570 5: mySignalduino: Parse, noMsg: SR;Adding repeats: 6
2021.11.20 09:32:37.570 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=SR;Adding repeats: 6
2021.11.20 09:32:37.570 4: mySignalduino: CheckSendrawResponse, sendraw answer: SR;Adding repeats: 6
2021.11.20 09:32:37.570 4: mySignalduino: Read, msg: R=6;Adding bucket
2021.11.20 09:32:37.570 5: mySignalduino: Parse, noMsg: R=6;Adding bucket
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: P0=250;Adding bucket
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: P0=250;Adding bucket
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: P1=-7750;Adding bucket
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: P1=-7750;Adding bucket
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: P2=750;Adding bucket
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: P2=750;Adding bucket
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: P3=-250;Adding bucket
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: P3=-250;Adding bucket
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: P4=-750;locating data start:01042304040404040404040423040404230423042304040423; end:;
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: P4=-750;locating data start:01042304040404040404040423040404230423042304040423; end:;
2021.11.20 09:32:37.571 4: mySignalduino: Read, msg: repeat 0/0 cmd 0/0 reps 6
2021.11.20 09:32:37.571 5: mySignalduino: Parse, noMsg: repeat 0/0 cmd 0/0 reps 6
2021.11.20 09:32:37.746 4: mySignalduino: Read, msg: .
2021.11.20 09:32:37.746 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:32:37.746 4: mySignalduino: Read, msg: SR;
2021.11.20 09:32:37.746 5: mySignalduino: Parse, noMsg: SR;
2021.11.20 09:32:37.746 4: mySignalduino: Read, msg: F
2021.11.20 09:32:37.746 5: mySignalduino: Parse, noMsg: F
2021.11.20 09:32:37.762 4: mySignalduino: Read, msg: D=01042304040404040404040423040404230423042304040423;
2021.11.20 09:32:37.762 5: mySignalduino: Parse, noMsg: D=01042304040404040404040423040404230423042304040423;
2021.11.20 09:32:37.762 4: mySignalduino: Read, msg:
2021.11.20 09:32:39.048 3: mySignalduino IT_set: IT_F0000F0FFF off
2021.11.20 09:32:39.054 5: mySignalduino: Write, sending via Set sendMsg P3#isF0000F0FFFF0#R6
2021.11.20 09:32:39.054 5: mySignalduino: Set_sendMsg, msg=P3#isF0000F0FFFF0#R6
2021.11.20 09:32:39.054 5: mySignalduino: Set_sendMsg, IT V1 convertet tristate to bits=010000000001000101010100
2021.11.20 09:32:39.054 5: mySignalduino: Set_sendMsg, Preparing rawsend command for protocol=3, repeats=6, clock=250 bits=010000000001000101010100
2021.11.20 09:32:39.054 5: mySignalduino: AddSendQueue, mySignalduino: SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304230404; (1)
2021.11.20 09:32:39.054 4: mySignalduino: Set_sendMsg, sending : SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304230404;
2021.11.20 09:32:39.516 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:32:39.516 4: mySignalduino: SendFromQueue, called
2021.11.20 09:32:39.516 5: mySignalduino: SimpleWrite, SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304230404;
2021.11.20 09:32:39.526 4: mySignalduino: SendFromQueue, msg=SR;R=6;P0=250;P1=-7750;P2=750;P3=-250;P4=-750;D=01042304040404040404040423040404230423042304230404;
2021.11.20 09:32:39.527 4: mySignalduino: Read, msg: send cmd detected 2
2021.11.20 09:32:39.527 5: mySignalduino: Parse, noMsg: send cmd detected 2
2021.11.20 09:32:39.527 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=send cmd detected 2
2021.11.20 09:32:39.579 4: mySignalduino: Read, msg: Adding raw
2021.11.20 09:32:39.579 5: mySignalduino: Parse, noMsg: Adding raw
2021.11.20 09:32:39.579 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=Adding raw
2021.11.20 09:32:39.579 4: mySignalduino: Read, msg: rearrange beginptr
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: rearrange beginptr
2021.11.20 09:32:39.580 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=rearrange beginptr
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: SR;Adding repeats: 6
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: SR;Adding repeats: 6
2021.11.20 09:32:39.580 5: mySignalduino: Read, msg: regexp=.* cmd=sendraw msg=SR;Adding repeats: 6
2021.11.20 09:32:39.580 4: mySignalduino: CheckSendrawResponse, sendraw answer: SR;Adding repeats: 6
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: R=6;Adding bucket
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: R=6;Adding bucket
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: P0=250;Adding bucket
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: P0=250;Adding bucket
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: P1=-7750;Adding bucket
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: P1=-7750;Adding bucket
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: P2=750;Adding bucket
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: P2=750;Adding bucket
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: P3=-250;Adding bucket
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: P3=-250;Adding bucket
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: P4=-750;locating data start:01042304040404040404040423040404230423042304230404; end:;
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: P4=-750;locating data start:01042304040404040404040423040404230423042304230404; end:;
2021.11.20 09:32:39.580 4: mySignalduino: Read, msg: repeat 0/0 cmd 0/0 reps 6
2021.11.20 09:32:39.580 5: mySignalduino: Parse, noMsg: repeat 0/0 cmd 0/0 reps 6
2021.11.20 09:32:39.755 4: mySignalduino: Read, msg: .
2021.11.20 09:32:39.755 5: mySignalduino: Parse, noMsg: .
2021.11.20 09:32:39.755 4: mySignalduino: Read, msg: SR;
2021.11.20 09:32:39.755 5: mySignalduino: Parse, noMsg: SR;
2021.11.20 09:32:39.755 4: mySignalduino: Read, msg: F
2021.11.20 09:32:39.755 5: mySignalduino: Parse, noMsg: F
2021.11.20 09:32:39.771 4: mySignalduino: Read, msg: D=01042304040404040404040423040404230423042304230404;
2021.11.20 09:32:39.771 5: mySignalduino: Parse, noMsg: D=01042304040404040404040423040404230423042304230404;
2021.11.20 09:32:39.771 4: mySignalduino: Read, msg:
2021.11.20 09:32:41.527 4: mySignalduino: HandleWriteQueue, called
2021.11.20 09:32:41.527 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer


Das Somfy device habe ich nach Wiki angelegt https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino
Was mir bezüglich Somfy nicht klar ist, ob beim Anlernen der enc_key und rolling_code eine Rolle spielt, da dieser sich ja jedes mal ändert, oder ob diese zum Anlernen einen bestimmten Wert haben muß.

Im Signalduino habe ich ein Debug Image geflasht welches ich wegen den 8MHz selbst compiliert (VsCode + PlatformIO) habe.
Könnten die 8MHz ein Problem sein?
FHEM läuft auf einem NUC I3 in Proxmox als LXC unter Ubuntu Server.

Eines meiner beiden CC1101 ist das Blaue vom Wiki https://wiki.fhem.de/wiki/Selbstbau_CUL
Einen Unterschied bei den Modulen ist die Version: einmal 0x04 und das andere 0x14
Mehr fällt mir momentan nicht ein.

Was mich noch etwas wundert ist beim Starten von Fhem:

2021.11.20 08:46:40.712 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/00_SIGNALduino.pm belongs to source repository "fhem". Ignoring identical file name from source repository signalduino
2021.11.20 08:46:40.712 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/14_SD_UT.pm belongs to source repository "fhem". Ignoring identical file name from source repository signalduino
2021.11.20 08:46:40.712 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/14_SD_WS.pm belongs to source repository "fhem". Ignoring identical file name from source repository signalduino

Bedeutet dies, daß ich die original FHEM Module verwende und nicht die aus dem Signalduino git?

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 November 2021, 10:09:30
Das müssen sich nun die Fachleute anschauen. Wenn der Rolladen nicht quittiert, wurde nicht angelernt. Der enc_key ist richtig eingestellt (eigentlich stellt man mW die Adress ein), der muss nur anders sein als der deiner Fernbedienung. Die zählen alleine hoch, wenn denn angelernt. Der Logeintrag beim Start ist merkwürdig, gibt es denn mehrere Versionen der Datei in deinem System? Das würde ich erstmal klären.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 20 November 2021, 11:01:52
Zitat von: andies am 20 November 2021, 10:09:30
Das müssen sich nun die Fachleute anschauen. Wenn der Rolladen nicht quittiert, wurde nicht angelernt. Der enc_key ist richtig eingestellt (eigentlich stellt man mW die Adress ein), der muss nur anders sein als der deiner Fernbedienung. Die zählen alleine hoch, wenn denn angelernt. Der Logeintrag beim Start ist merkwürdig, gibt es denn mehrere Versionen der Datei in deinem System? Das würde ich erstmal klären.

Zur Startmeldung: https://forum.fhem.de/index.php?topic=108017.0

Zum Anlernen, ja so habe ich es auch verstanden das nur die Adresse (frei definiert) angegeben werden muß.
Die Frage ist, ob enc_key und rolling_code bei einem erneuten Anlernversuch ein Problem darstellen, bzw mir fällt gerade ein irgendwo gelesen zu haben, daß ein erneutes Anlernen den Sender wieder ablernt/löscht.
Gibt es einen Unterschied bei den gesendeten Daten beim an und ablernen?
Ich glaube hier brauchen wir einen Somfy Experten.

Edit:
Was gibt eigentlich CC1101_dataRate an? Dies kann ja nicht die Senderate des Funksignals sein.
Wenn ich es richtig verstanden habe wird über die SPI konfiguriert und über zwei GPIOs gesendet und gelesen.
Hat es damit etwas zu tun?

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: McShire am 20 November 2021, 15:56:24
Hallo Stephan,
Ich habe seit einem Monat ein Roto Dachfenster mit Solar-Rolladen. Handsender SIMU, ist das gleiche Protokoll wie Somfy RTS, ist alles Simu.
FHEM läuft bei mir auf dem Raspi3B (spielt aber eigentlich keine Rolle) und mein Signalduino ist die Standard-Selbstbau-Hardware (Nano, CC1101) geflashed mit der Signalduino Firmware (das ist wichtig).
Das Erstellen des devices und das Anlernen des Rolladens exakt nach dem o.a. FHEM-Wiki Eintrag durchgeführt, läuft alles ohne Probleme.
Hat beim ersten Mal nicht funktioniert, weil der Rolladen nicht im Anlernmodus war. Bitte genau beachten, dass der Rolladen kurz nach unten ruckt und zurück ruckt und dann das Anlernen quittiert.
Das war bei mir beim ersten Versuch nicht der Fall, hatte wohl den den Mikrotaster am Handsender zu lange oder zu kurz gedrückt.
Geh doch einfach mal auf die Standards zurück. Ach ja, vor dem Anlernen habe ich noch ein Update für den Signalduino und für FHEM gemacht.
Vielleicht geht ja dann mit Standards alles.
Viel Erfolg und viele Grüße
Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 20 November 2021, 18:20:21
Hallo Werner,

Danke für die Rückmeldung.
Dass das Ganze funktionieren muß habe ich auch schon mehrfach gelesen.

Das der Rolladen in den Anlernmodus geht bin ich mir sicher, denn er ruckt und zuckt wie von Dir bzw der Simu Doku beschrieben, jedoch er quitiert das Anlernen nicht.
Fhem habe ich bereits auch schon aktualisiert.

Zitat von: McShire am 20 November 2021, 15:56:24
... Geh doch einfach mal auf die Standards zurück....
Was meinst Du damit genau?

Die Firmware muß ich selbst compilieren, da es kein fertiges Image für den promini 3,3V 8MHz gibt.
Ich verwende den promini mit 3,3V da der CC1101 auch nur 3,3V kann und der atmega328 bei 3,3V laut Datenblatt maximal 8MHz kann.
Die Pegelanpassung mit dem Spannungsteiler funktioniert zwar meistens, ist jedoch nicht so das gelbe vom Ei.

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 20 November 2021, 18:58:31
Da du die Steckdosen anlernen kannst, glaube ich nicht an ein Hardware-Problem. Man müsste prüfen, ob die Frequenz umgeschaltet wird, das wäre irgendwie wichtig - denn das braucht somfy.

Du könntest eins probieren: Stell mal die somfy-Frequenz ein, bewege deine rolläden und mache vorher autocreate. Dann müsste eigentlich ein Rolladen-device angelegt werden. Das darfst du dann aber eben nicht schalten, weil sonst die Fernbedienung aus dem Takt gerät und die hinüber ist (ich habe dann immer das angelegt device gelöscht). Aber entscheidend ist: Der Signalduino würde so zeigen, dass er empfängt.

Wenn es ein Software-Problem ist, dann brauchen wir Hilfe von Ralf9.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 20 November 2021, 21:45:42
Also, ich hab nun mal den Handsender direkt neben dem sduino betätigt, und folgendes im Log gefunden, wobei er mir gestern bereits zwei Handsender automatisch angelegt hatte.


2021.11.20 21:38:44.532 4: mySignalduino: Read, msg: MC;LL=-1274;LH=1215;SL=-644;SH=598;D=52444625D66FAAE2000C8;C=621;L=81;R=57;
2021.11.20 21:38:44.533 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 621 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.533 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101110001000000000000011001000 (bin)
2021.11.20 21:38:44.533 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101110001000000000000011001000 (81)
2021.11.20 21:38:44.533 5: mySignalduino: Dispatch, Ys52444625D66FAAE2000C8, test ungleich: disabled
2021.11.20 21:38:44.533 5: mySignalduino: Dispatch, Ys52444625D66FAAE2000C8, -45.5 dB, dispatch
2021.11.20 21:38:44.534 5: mySignalduino: dispatch Ys52444625D66FAAE2000C8
2021.11.20 21:38:44.650 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAE2000C8:
2021.11.20 21:38:44.654 3: mySignalduino: Unknown code Ys52444625D66FAAE2000C8, help me!
2021.11.20 21:38:44.654 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 621 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.654 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010001110111111111111100110111 (bin)
2021.11.20 21:38:44.654 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.676 4: mySignalduino: Read, msg: MC;LL=-1267;LH=1244;SL=-624;SH=611;D=52444625D66FAAE400130;C=624;L=81;R=57;
2021.11.20 21:38:44.677 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 624 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.677 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101110010000000000000100110000 (bin)
2021.11.20 21:38:44.677 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101110010000000000000100110000 (81)
2021.11.20 21:38:44.677 5: mySignalduino: Dispatch, Ys52444625D66FAAE400130, test ungleich: disabled
2021.11.20 21:38:44.677 5: mySignalduino: Dispatch, Ys52444625D66FAAE400130, -45.5 dB, dispatch
2021.11.20 21:38:44.677 5: mySignalduino: dispatch Ys52444625D66FAAE400130
2021.11.20 21:38:44.792 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAE400130:
2021.11.20 21:38:44.796 3: mySignalduino: Unknown code Ys52444625D66FAAE400130, help me!
2021.11.20 21:38:44.797 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 624 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.797 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010001101111111111111011001111 (bin)
2021.11.20 21:38:44.797 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.815 4: mySignalduino: Read, msg: MC;LL=-1259;LH=1229;SL=-630;SH=602;D=52444625D66FAAC6001B8;C=619;L=81;R=57;
2021.11.20 21:38:44.816 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 619 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.816 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (bin)
2021.11.20 21:38:44.816 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (81)
2021.11.20 21:38:44.816 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, test ungleich: disabled
2021.11.20 21:38:44.816 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, -45.5 dB, dispatch
2021.11.20 21:38:44.816 5: mySignalduino: dispatch Ys52444625D66FAAC6001B8
2021.11.20 21:38:44.922 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAC6001B8:
2021.11.20 21:38:44.927 3: mySignalduino: Unknown code Ys52444625D66FAAC6001B8, help me!
2021.11.20 21:38:44.927 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 619 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.927 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010011100111111111111001000111 (bin)
2021.11.20 21:38:44.927 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.930 4: mySignalduino: Read, msg: MC;LL=-1274;LH=1222;SL=-659;SH=588;D=52444625D66FAAC6001B8;C=623;L=81;R=57;
2021.11.20 21:38:44.930 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 623 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (bin)
2021.11.20 21:38:44.930 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (81)
2021.11.20 21:38:44.930 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, test gleich
2021.11.20 21:38:44.930 4: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, Dropped due to short time or equal msg
2021.11.20 21:38:44.930 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 623 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010011100111111111111001000111 (bin)
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.511 4: mySignalduino: Read, msg: MC;LL=-1271;LH=1221;SL=-649;SH=591;D=52DA583C4FF63362000C8;C=621;L=81;R=52;
2021.11.20 21:38:49.511 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 621 RSSI = -48 -> Somfy RTS
2021.11.20 21:38:49.512 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110110001000000000000011001000 (bin)
2021.11.20 21:38:49.512 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110110001000000000000011001000 (81)
2021.11.20 21:38:49.512 5: mySignalduino: Dispatch, Ys52DA583C4FF63362000C8, test ungleich: disabled
2021.11.20 21:38:49.512 5: mySignalduino: Dispatch, Ys52DA583C4FF63362000C8, -48 dB, dispatch
2021.11.20 21:38:49.512 5: mySignalduino: dispatch Ys52DA583C4FF63362000C8
2021.11.20 21:38:49.622 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF63362000C8:
2021.11.20 21:38:49.625 3: mySignalduino: Unknown code Ys52DA583C4FF63362000C8, help me!
2021.11.20 21:38:49.625 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 621 RSSI = -48 -> Oregon Scientific PIR
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001001110111111111111100110111 (bin)
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.626 4: mySignalduino: Read, msg: MC;LL=-1287;LH=1213;SL=-659;SH=585;D=52DA583C4FF6336400130;C=623;L=81;R=52;
2021.11.20 21:38:49.626 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 623 RSSI = -48 -> Somfy RTS
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110110010000000000000100110000 (bin)
2021.11.20 21:38:49.626 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110110010000000000000100110000 (81)
2021.11.20 21:38:49.626 5: mySignalduino: Dispatch, Ys52DA583C4FF6336400130, test ungleich: disabled
2021.11.20 21:38:49.626 5: mySignalduino: Dispatch, Ys52DA583C4FF6336400130, -48 dB, dispatch
2021.11.20 21:38:49.626 5: mySignalduino: dispatch Ys52DA583C4FF6336400130
2021.11.20 21:38:49.747 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF6336400130:
2021.11.20 21:38:49.751 3: mySignalduino: Unknown code Ys52DA583C4FF6336400130, help me!
2021.11.20 21:38:49.751 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 623 RSSI = -48 -> Oregon Scientific PIR
2021.11.20 21:38:49.751 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001001101111111111111011001111 (bin)
2021.11.20 21:38:49.751 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.795 4: mySignalduino: Read, msg: MC;LL=-1263;LH=1229;SL=-623;SH=604;D=52DA583C4FF63346001B8;C=619;L=81;R=46;
2021.11.20 21:38:49.795 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 619 RSSI = -51 -> Somfy RTS
2021.11.20 21:38:49.795 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (bin)
2021.11.20 21:38:49.795 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (81)
2021.11.20 21:38:49.796 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, test ungleich: disabled
2021.11.20 21:38:49.796 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, -51 dB, dispatch
2021.11.20 21:38:49.796 5: mySignalduino: dispatch Ys52DA583C4FF63346001B8
2021.11.20 21:38:49.905 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF63346001B8:
2021.11.20 21:38:49.908 3: mySignalduino: Unknown code Ys52DA583C4FF63346001B8, help me!
2021.11.20 21:38:49.908 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 619 RSSI = -51 -> Oregon Scientific PIR
2021.11.20 21:38:49.908 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001011100111111111111001000111 (bin)
2021.11.20 21:38:49.908 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.908 4: mySignalduino: Read, msg: MC;LL=-1265;LH=1234;SL=-654;SH=599;D=52DA583C4FF63346001B8;C=625;L=81;R=46;
2021.11.20 21:38:49.909 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 625 RSSI = -51 -> Somfy RTS
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (bin)
2021.11.20 21:38:49.909 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (81)
2021.11.20 21:38:49.909 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, test gleich
2021.11.20 21:38:49.909 4: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, Dropped due to short time or equal msg
2021.11.20 21:38:49.909 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 625 RSSI = -51 -> Oregon Scientific PIR
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001011100111111111111001000111 (bin)
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:39:01.856 4: mySignalduino: KeepAlive, ok, retry = 0
2021.11.20 21:40:01.856 4: mySignalduino: KeepAlive, not ok, retry = 1 -> get ping
2021.11.20 21:40:01.856 5: mySignalduino: AddSendQueue, mySignalduino: P (1)
2021.11.20 21:40:01.856 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:40:01.857 4: mySignalduino: SendFromQueue, called
2021.11.20 21:40:01.857 5: mySignalduino: SimpleWrite, P
2021.11.20 21:40:01.869 4: mySignalduino: Read, msg: OK
2021.11.20 21:40:01.869 5: mySignalduino: Parse, noMsg: OK
2021.11.20 21:40:01.869 5: mySignalduino: Read, msg: regexp=^OK$ cmd=ping msg=OK
2021.11.20 21:40:02.167 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:40:02.167 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer


Habe nun mal den CC1101 nicht mehr vom 3,3V Wandler des promini versorgt sondern aus einem NCP1117.


EDIT
Irgendwie verstehe ich überhaupt nichts mehr.
Habe neben dem sduino den Handender 2x betätigt, bin wieder zum PC und habe das Log aktualisiert und hier gepostet.
Nun fällt mir gerade auf, daß er mir zwei Devices angelegt hat, jedoch mit einer Verzögerung von ca. 2 Minuten.
Hier nochmals das komplette log.


2021.11.20 21:38:01.855 4: mySignalduino: KeepAlive, ok, retry = 0
2021.11.20 21:38:44.532 4: mySignalduino: Read, msg: MC;LL=-1274;LH=1215;SL=-644;SH=598;D=52444625D66FAAE2000C8;C=621;L=81;R=57;
2021.11.20 21:38:44.533 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 621 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.533 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101110001000000000000011001000 (bin)
2021.11.20 21:38:44.533 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101110001000000000000011001000 (81)
2021.11.20 21:38:44.533 5: mySignalduino: Dispatch, Ys52444625D66FAAE2000C8, test ungleich: disabled
2021.11.20 21:38:44.533 5: mySignalduino: Dispatch, Ys52444625D66FAAE2000C8, -45.5 dB, dispatch
2021.11.20 21:38:44.534 5: mySignalduino: dispatch Ys52444625D66FAAE2000C8
2021.11.20 21:38:44.650 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAE2000C8:
2021.11.20 21:38:44.654 3: mySignalduino: Unknown code Ys52444625D66FAAE2000C8, help me!
2021.11.20 21:38:44.654 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 621 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.654 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010001110111111111111100110111 (bin)
2021.11.20 21:38:44.654 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.676 4: mySignalduino: Read, msg: MC;LL=-1267;LH=1244;SL=-624;SH=611;D=52444625D66FAAE400130;C=624;L=81;R=57;
2021.11.20 21:38:44.677 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 624 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.677 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101110010000000000000100110000 (bin)
2021.11.20 21:38:44.677 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101110010000000000000100110000 (81)
2021.11.20 21:38:44.677 5: mySignalduino: Dispatch, Ys52444625D66FAAE400130, test ungleich: disabled
2021.11.20 21:38:44.677 5: mySignalduino: Dispatch, Ys52444625D66FAAE400130, -45.5 dB, dispatch
2021.11.20 21:38:44.677 5: mySignalduino: dispatch Ys52444625D66FAAE400130
2021.11.20 21:38:44.792 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAE400130:
2021.11.20 21:38:44.796 3: mySignalduino: Unknown code Ys52444625D66FAAE400130, help me!
2021.11.20 21:38:44.797 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 624 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.797 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010001101111111111111011001111 (bin)
2021.11.20 21:38:44.797 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.815 4: mySignalduino: Read, msg: MC;LL=-1259;LH=1229;SL=-630;SH=602;D=52444625D66FAAC6001B8;C=619;L=81;R=57;
2021.11.20 21:38:44.816 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 619 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.816 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (bin)
2021.11.20 21:38:44.816 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (81)
2021.11.20 21:38:44.816 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, test ungleich: disabled
2021.11.20 21:38:44.816 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, -45.5 dB, dispatch
2021.11.20 21:38:44.816 5: mySignalduino: dispatch Ys52444625D66FAAC6001B8
2021.11.20 21:38:44.922 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52444625D66FAAC6001B8:
2021.11.20 21:38:44.927 3: mySignalduino: Unknown code Ys52444625D66FAAC6001B8, help me!
2021.11.20 21:38:44.927 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 619 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.927 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010011100111111111111001000111 (bin)
2021.11.20 21:38:44.927 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:44.930 4: mySignalduino: Read, msg: MC;LL=-1274;LH=1222;SL=-659;SH=588;D=52444625D66FAAC6001B8;C=623;L=81;R=57;
2021.11.20 21:38:44.930 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 623 RSSI = -45.5 -> Somfy RTS
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, extracted data 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (bin)
2021.11.20 21:38:44.930 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100100100010001000110001001011101011001101111101010101100011000000000000110111000 (81)
2021.11.20 21:38:44.930 5: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, test gleich
2021.11.20 21:38:44.930 4: mySignalduino: Dispatch, Ys52444625D66FAAC6001B8, Dropped due to short time or equal msg
2021.11.20 21:38:44.930 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 623 RSSI = -45.5 -> Oregon Scientific PIR
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, extracted data 101011011011101110111001110110100010100110010000010101010011100111111111111001000111 (bin)
2021.11.20 21:38:44.930 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.511 4: mySignalduino: Read, msg: MC;LL=-1271;LH=1221;SL=-649;SH=591;D=52DA583C4FF63362000C8;C=621;L=81;R=52;
2021.11.20 21:38:49.511 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 621 RSSI = -48 -> Somfy RTS
2021.11.20 21:38:49.512 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110110001000000000000011001000 (bin)
2021.11.20 21:38:49.512 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110110001000000000000011001000 (81)
2021.11.20 21:38:49.512 5: mySignalduino: Dispatch, Ys52DA583C4FF63362000C8, test ungleich: disabled
2021.11.20 21:38:49.512 5: mySignalduino: Dispatch, Ys52DA583C4FF63362000C8, -48 dB, dispatch
2021.11.20 21:38:49.512 5: mySignalduino: dispatch Ys52DA583C4FF63362000C8
2021.11.20 21:38:49.622 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF63362000C8:
2021.11.20 21:38:49.625 3: mySignalduino: Unknown code Ys52DA583C4FF63362000C8, help me!
2021.11.20 21:38:49.625 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 621 RSSI = -48 -> Oregon Scientific PIR
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001001110111111111111100110111 (bin)
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.626 4: mySignalduino: Read, msg: MC;LL=-1287;LH=1213;SL=-659;SH=585;D=52DA583C4FF6336400130;C=623;L=81;R=52;
2021.11.20 21:38:49.626 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 623 RSSI = -48 -> Somfy RTS
2021.11.20 21:38:49.626 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110110010000000000000100110000 (bin)
2021.11.20 21:38:49.626 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110110010000000000000100110000 (81)
2021.11.20 21:38:49.626 5: mySignalduino: Dispatch, Ys52DA583C4FF6336400130, test ungleich: disabled
2021.11.20 21:38:49.626 5: mySignalduino: Dispatch, Ys52DA583C4FF6336400130, -48 dB, dispatch
2021.11.20 21:38:49.626 5: mySignalduino: dispatch Ys52DA583C4FF6336400130
2021.11.20 21:38:49.747 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF6336400130:
2021.11.20 21:38:49.751 3: mySignalduino: Unknown code Ys52DA583C4FF6336400130, help me!
2021.11.20 21:38:49.751 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 623 RSSI = -48 -> Oregon Scientific PIR
2021.11.20 21:38:49.751 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001001101111111111111011001111 (bin)
2021.11.20 21:38:49.751 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.795 4: mySignalduino: Read, msg: MC;LL=-1263;LH=1229;SL=-623;SH=604;D=52DA583C4FF63346001B8;C=619;L=81;R=46;
2021.11.20 21:38:49.795 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 619 RSSI = -51 -> Somfy RTS
2021.11.20 21:38:49.795 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (bin)
2021.11.20 21:38:49.795 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (81)
2021.11.20 21:38:49.796 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, test ungleich: disabled
2021.11.20 21:38:49.796 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, -51 dB, dispatch
2021.11.20 21:38:49.796 5: mySignalduino: dispatch Ys52DA583C4FF63346001B8
2021.11.20 21:38:49.905 1: mySignalduino: SOMFY_Parse : Somfy RTS message format error (length must be 14 or 20)! :52DA583C4FF63346001B8:
2021.11.20 21:38:49.908 3: mySignalduino: Unknown code Ys52DA583C4FF63346001B8, help me!
2021.11.20 21:38:49.908 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 619 RSSI = -51 -> Oregon Scientific PIR
2021.11.20 21:38:49.908 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001011100111111111111001000111 (bin)
2021.11.20 21:38:49.908 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:38:49.908 4: mySignalduino: Read, msg: MC;LL=-1265;LH=1234;SL=-654;SH=599;D=52DA583C4FF63346001B8;C=625;L=81;R=46;
2021.11.20 21:38:49.909 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 625 RSSI = -51 -> Somfy RTS
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, extracted data 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (bin)
2021.11.20 21:38:49.909 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100101101101001011000001111000100111111110110001100110100011000000000000110111000 (81)
2021.11.20 21:38:49.909 5: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, test gleich
2021.11.20 21:38:49.909 4: mySignalduino: Dispatch, Ys52DA583C4FF63346001B8, Dropped due to short time or equal msg
2021.11.20 21:38:49.909 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 625 RSSI = -51 -> Oregon Scientific PIR
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, extracted data 101011010010010110100111110000111011000000001001110011001011100111111111111001000111 (bin)
2021.11.20 21:38:49.909 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:39:01.856 4: mySignalduino: KeepAlive, ok, retry = 0
2021.11.20 21:40:01.856 4: mySignalduino: KeepAlive, not ok, retry = 1 -> get ping
2021.11.20 21:40:01.856 5: mySignalduino: AddSendQueue, mySignalduino: P (1)
2021.11.20 21:40:01.856 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:40:01.857 4: mySignalduino: SendFromQueue, called
2021.11.20 21:40:01.857 5: mySignalduino: SimpleWrite, P
2021.11.20 21:40:01.869 4: mySignalduino: Read, msg: OK
2021.11.20 21:40:01.869 5: mySignalduino: Parse, noMsg: OK
2021.11.20 21:40:01.869 5: mySignalduino: Read, msg: regexp=^OK$ cmd=ping msg=OK
2021.11.20 21:40:02.167 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:40:02.167 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer
2021.11.20 21:40:55.660 3: CUL_HM set HM_4A7D85_Sw statusRequest noArg
2021.11.20 21:41:01.857 4: mySignalduino: KeepAlive, ok, retry = 0
2021.11.20 21:41:16.673 3: CUL_HM set HM_4A7D85_Sw statusRequest noArg
2021.11.20 21:42:01.857 4: mySignalduino: KeepAlive, not ok, retry = 1 -> get ping
2021.11.20 21:42:01.857 5: mySignalduino: AddSendQueue, mySignalduino: P (1)
2021.11.20 21:42:01.857 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:42:01.858 4: mySignalduino: SendFromQueue, called
2021.11.20 21:42:01.858 5: mySignalduino: SimpleWrite, P
2021.11.20 21:42:01.868 4: mySignalduino: Read, msg: OK
2021.11.20 21:42:01.868 5: mySignalduino: Parse, noMsg: OK
2021.11.20 21:42:01.868 5: mySignalduino: Read, msg: regexp=^OK$ cmd=ping msg=OK
2021.11.20 21:42:02.168 4: mySignalduino: HandleWriteQueue, called
2021.11.20 21:42:02.168 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer
2021.11.20 21:42:34.196 4: mySignalduino: Read, msg: MC;LL=-1276;LH=1277;SL=-629;SH=632;D=502222221D45;C=635;L=48;R=244;
2021.11.20 21:42:34.197 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 635 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:34.197 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010 (bin)
2021.11.20 21:42:34.197 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:34.323 5: mySignalduino: Read, RAW rmsg: Mu;��;�ω;���;���;���;���;��;���;dEEgggggEggEggEggEggEggEgggGgg;C7;RF4;
2021.11.20 21:42:34.323 4: mySignalduino: Read, msg READredu: MU;P0=-9696;P1=-2511;P2=2466;P3=4784;P4=-1271;P5=1285;P6=-619;P7=624;D=1212121212121345456767676767456767456767456767456767456767456767674767670;CP=7;R=244;
2021.11.20 21:42:34.324 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 8 -> TX3 Protocol matches, trying to demodulate
2021.11.20 21:42:34.325 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){43,})) did not match
2021.11.20 21:42:34.325 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 9 -> weather matches, trying to demodulate
2021.11.20 21:42:34.325 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:74|54){60,}(?:7|5)?)) did not match
2021.11.20 21:42:34.325 5: mySignalduino: Parse_MU, start pattern for MU protocol id 13.1 -> FLAMINGO FA22RF / FA21RF / LM-101LD not found, aborting
2021.11.20 21:42:34.325 5: mySignalduino: Parse_MU, start pattern for MU protocol id 21 -> Einhell Garagedoor not found, aborting
2021.11.20 21:42:34.325 5: mySignalduino: Parse_MU, start pattern for MU protocol id 24 -> Visivo remote not found, aborting
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, start pattern for MU protocol id 26 -> xavax not found, aborting
2021.11.20 21:42:34.326 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 28 -> IC Ledspot matches, trying to demodulate
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, 0. try, regex ((?:21)((?:76|74){8,})) did not match
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, start pattern for MU protocol id 29 -> HT12e not found, aborting
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, start pattern for MU protocol id 30 -> diverse not found, aborting
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, start pattern for MU protocol id 31 -> LTECH not found, aborting
2021.11.20 21:42:34.326 5: mySignalduino: Parse_MU, start pattern for MU protocol id 32 -> wireless doorbell not found, aborting
2021.11.20 21:42:34.327 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2021.11.20 21:42:34.327 5: mySignalduino: Parse_MU, 0. try, regex ((?:7)((?:45|47){19,}(?:4)?)) did not match
2021.11.20 21:42:34.327 5: mySignalduino: Parse_MU, start pattern for MU protocol id 36 -> remote not found, aborting
2021.11.20 21:42:34.327 5: mySignalduino: Parse_MU, for MU protocol id 39, applying filterfunc SIGNALduino_compPattern
2021.11.20 21:42:34.327 5: mySignalduino: Parse_MU, start pattern for MU protocol id 39 -> X10 Protocol not found, aborting
2021.11.20 21:42:34.327 5: mySignalduino: Parse_MU, start pattern for MU protocol id 40 -> Romotec  not found, aborting
2021.11.20 21:42:34.328 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 42 -> wireless doorbell matches, trying to demodulate
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, 0. try, regex ((?:767676)((?:76|56){28,})) did not match
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44 -> BresserTemeo not found, aborting
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44.1 -> BresserTemeo not found, aborting
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 45 -> Revolt not found, aborting
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 46 -> SKXxxx, GF0x0x not found, aborting
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.1 -> GT-9000 not found, aborting
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.2 -> GT-9000 not found, aborting
2021.11.20 21:42:34.328 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2021.11.20 21:42:34.328 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:74|54){47,}(?:7|5)?)) did not match
2021.11.20 21:42:34.329 5: mySignalduino: Parse_MU, start pattern for MU protocol id 56 -> AC114-xxB not found, aborting
2021.11.20 21:42:34.329 5: mySignalduino: Parse_MU, start pattern for MU protocol id 59 -> AK-HD-4 not found, aborting
2021.11.20 21:42:34.329 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2021.11.20 21:42:34.329 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){30,})) did not match
2021.11.20 21:42:34.329 5: mySignalduino: Parse_MU, start pattern for MU protocol id 62 -> Clarus_Switch not found, aborting
2021.11.20 21:42:34.329 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2021.11.20 21:42:34.329 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:74|54){48,})) did not match
2021.11.20 21:42:34.330 5: mySignalduino: Parse_MU, start pattern for MU protocol id 66 -> WS7035 not found, aborting
2021.11.20 21:42:34.330 5: mySignalduino: Parse_MU, start pattern for MU protocol id 69 -> Hoermann not found, aborting
2021.11.20 21:42:34.330 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2021.11.20 21:42:34.330 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){50,})) did not match
2021.11.20 21:42:34.330 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 71 -> PEARL matches, trying to demodulate
2021.11.20 21:42:34.330 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|54){48,})) did not match
2021.11.20 21:42:34.330 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 72 -> Siro shutter matches, trying to demodulate
2021.11.20 21:42:34.330 5: mySignalduino: Parse_MU, 0. try, regex ((?:34)((?:76|76){39,})) did not match
2021.11.20 21:42:34.331 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){59,})) did not match
2021.11.20 21:42:34.331 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){50,})) did not match
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, start pattern for MU protocol id 76 -> LED XM21 not found, aborting
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, start pattern for MU protocol id 79 -> wireless doorbell not found, aborting
2021.11.20 21:42:34.331 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:76|76){104,})) did not match
2021.11.20 21:42:34.331 5: mySignalduino: Parse_MU, start pattern for MU protocol id 81 -> SA-434-1 not found, aborting
2021.11.20 21:42:34.332 5: mySignalduino: Parse_MU, start pattern for MU protocol id 83 -> RH787T not found, aborting
2021.11.20 21:42:34.332 5: mySignalduino: Parse_MU, start pattern for MU protocol id 86 -> BOSCH | CAME | Novy | Neff | Refsta Topdraft not found, aborting
2021.11.20 21:42:34.332 5: mySignalduino: Parse_MU, start pattern for MU protocol id 91 -> Atlantic security not found, aborting
2021.11.20 21:42:34.332 5: mySignalduino: Parse_MU, start pattern for MU protocol id 94 -> Atech not found, aborting
2021.11.20 21:42:34.332 5: mySignalduino: Parse_MU, start pattern for MU protocol id 97 -> Momento not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 98 -> GEA-028DB not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 99 -> Navaris 44344.04 not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 104 -> TR60C-1 not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 105 -> BF-301 not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 110 -> ADE_WS_1907 not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 111 -> TS-FT002 not found, aborting
2021.11.20 21:42:34.333 5: mySignalduino: Parse_MU, start pattern for MU protocol id 114 -> TR401 not found, aborting
2021.11.20 21:42:34.494 4: mySignalduino: Read, msg: MC;LL=-1268;LH=1283;SL=-646;SH=628;D=502222221D45888;C=637;L=57;R=244;
2021.11.20 21:42:34.495 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 637 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:34.495 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:34.495 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:34.495 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:34.495 5: mySignalduino: Dispatch, YsA04444443A8B11, test ungleich: disabled
2021.11.20 21:42:34.495 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 21:42:34.495 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 21:42:34.594 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 21:42:34.594 1: SOMFY Unknown device 9AB17E (A0 0000), please define it
2021.11.20 21:42:34.596 2: autocreate: define SOMFY_9AB17E SOMFY 9AB17E A0 0000
2021.11.20 21:42:34.603 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:34.604 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:34.604 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:34.781 4: mySignalduino: Read, msg: MC;LL=-1284;LH=1265;SL=-652;SH=618;D=222221D45888;C=636;L=45;R=244;
2021.11.20 21:42:34.782 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:34.782 5: mySignalduino: Parse_MC, extracted data 110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:34.782 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:34.797 4: mySignalduino: Read, msg: MC;LL=-1284;LH=1265;SL=-652;SH=618;D=502222221D45888;C=636;L=57;R=244;
2021.11.20 21:42:34.798 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 636 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:34.798 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:34.798 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:34.798 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:34.798 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 21:42:34.798 4: mySignalduino: Dispatch, YsA04444443A8B11, Dropped due to short time or equal msg
2021.11.20 21:42:34.798 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:34.798 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:34.798 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:38.316 4: mySignalduino: Read, msg: MC;LL=-1271;LH=1287;SL=-644;SH=620;D=4444443A8B11;C=636;L=48;R=244;
2021.11.20 21:42:38.316 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:38.316 5: mySignalduino: Parse_MC, extracted data 101110111011101110111011110001010111010011101110 (bin)
2021.11.20 21:42:38.316 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:38.521 4: mySignalduino: Read, msg: MC;LL=-1272;LH=1280;SL=-605;SH=643;D=888751622;C=633;L=35;R=244;
2021.11.20 21:42:38.521 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 633 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:38.521 5: mySignalduino: Parse_MC, extracted data 011101110111100010101110100111011101 (bin)
2021.11.20 21:42:38.521 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:38.600 4: mySignalduino: Read, msg: MC;LL=-1269;LH=1272;SL=-634;SH=629;D=751622;C=633;L=23;R=244;
2021.11.20 21:42:38.882 4: mySignalduino: Read, msg: MC;LL=-1283;LH=1278;SL=-641;SH=626;D=40888888751622;C=637;L=55;R=244;
2021.11.20 21:42:38.882 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 637 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:38.882 5: mySignalduino: Parse_MC, extracted data 01000000100010001000100010001000011101010001011000100010 (bin)
2021.11.20 21:42:38.882 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 01000000100010001000100010001000011101010001011000100010 (55)
2021.11.20 21:42:38.882 5: mySignalduino: Dispatch, Ys40888888751622, test ungleich: disabled
2021.11.20 21:42:38.882 5: mySignalduino: Dispatch, Ys40888888751622, -80 dB, dispatch
2021.11.20 21:42:38.882 5: mySignalduino: dispatch Ys40888888751622
2021.11.20 21:42:38.981 4: mySignalduino: Somfy RTS preprocessing check: 8 enc: 40888888751622 dec: 40C80000FD6334
2021.11.20 21:42:38.981 1: SOMFY Unknown device 3463FD (40 0000), please define it
2021.11.20 21:42:38.983 2: autocreate: define SOMFY_3463FD SOMFY 3463FD 40 0000
2021.11.20 21:42:38.990 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:38.990 5: mySignalduino: Parse_MC, extracted data 10111111011101110111011101110111100010101110100111011101 (bin)
2021.11.20 21:42:38.991 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:38.991 4: mySignalduino: Read, msg: MC;LL=-1283;LH=1278;SL=-641;SH=626;D=502222221D45888;C=637;L=57;R=244;
2021.11.20 21:42:38.991 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 637 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:38.991 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:38.992 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:38.992 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:38.992 5: mySignalduino: Dispatch, YsA04444443A8B11, test ungleich: disabled
2021.11.20 21:42:38.992 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 21:42:38.992 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 21:42:39.101 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 21:42:39.102 1: PERL WARNING: Use of uninitialized value $newstate in concatenation (.) or string at ./FHEM/10_SOMFY.pm line 605.
2021.11.20 21:42:39.111 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:39.111 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:39.111 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:42.576 4: mySignalduino: Read, msg: MC;LL=-1261;LH=1275;SL=-634;SH=647;D=502222221D45888;C=636;L=57;R=244;
2021.11.20 21:42:42.576 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 636 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:42.576 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:42.576 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:42.576 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:42.576 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 21:42:42.576 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 21:42:42.576 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 21:42:42.577 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 21:42:42.578 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:42.578 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:42.579 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:42.864 4: mySignalduino: Read, msg: MC;LL=-1286;LH=1284;SL=-647;SH=620;D=502222221D45888;C=639;L=57;R=244;
2021.11.20 21:42:42.864 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 639 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:42.864 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:42.864 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:42.864 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:42.864 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 21:42:42.864 4: mySignalduino: Dispatch, YsA04444443A8B11, Dropped due to short time or equal msg
2021.11.20 21:42:42.864 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 639 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:42.864 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:42.865 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:42.938 4: mySignalduino: Read, msg: MC;LL=-1265;LH=1282;SL=-628;SH=645;D=04444443A8;C=636;L=37;R=244;
2021.11.20 21:42:42.938 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:42.938 5: mySignalduino: Parse_MC, extracted data 1111101110111011101110111011110001010111 (bin)
2021.11.20 21:42:42.938 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:46.518 4: mySignalduino: Read, msg: MC;LL=-1275;LH=1275;SL=-623;SH=640;D=111110EA2C44;C=635;L=46;R=244;
2021.11.20 21:42:46.519 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 635 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:46.519 5: mySignalduino: Parse_MC, extracted data 111011101110111011101111000101011101001110111011 (bin)
2021.11.20 21:42:46.519 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:46.790 4: mySignalduino: Read, msg: MC;LL=-1271;LH=1282;SL=-654;SH=622;D=04444443A8B11;C=638;L=52;R=244;
2021.11.20 21:42:46.790 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 638 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:46.790 5: mySignalduino: Parse_MC, extracted data 1111101110111011101110111011110001010111010011101110 (bin)
2021.11.20 21:42:46.790 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 21:42:46.934 4: mySignalduino: Read, msg: MC;LL=-1287;LH=1272;SL=-645;SH=614;D=502222221D45888;C=636;L=57;R=244;
2021.11.20 21:42:46.934 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 636 RSSI = -80 -> Somfy RTS
2021.11.20 21:42:46.934 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 21:42:46.934 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 21:42:46.934 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 21:42:46.934 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 21:42:46.935 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 21:42:46.935 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 21:42:46.935 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 21:42:46.936 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 21:42:46.937 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 21:42:46.937 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)

Irgendwie bin ich ratlos.
MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 November 2021, 22:46:33
Dies ist ein bekanntes Problem, es gibt einige Somfy Fernbedienungen mit denen die firmware und das offizielle 00_SIGNALduino.pm Modul von sidey nicht zurecht kommt.
Z.B. die MC Nachrichten mit einer Länge von L=81, da ist am Anfang ein Bit zuviel.

Habs mal mit meinem angepasstem 00_SIGNALduino.pm Modul  und einem dummy sduino simuliert, da passt es:
MC;LL=-1274;LH=1215;SL=-644;SH=598;D=52444625D66FAAE2000C8;C=621;L=81;R=57;
Dispatch: YsA4888C4BACDF55C40019
SOMFY Unknown device 8A73E7 (A4 04C7), cmd=20 please define it

MC;LL=-1259;LH=1229;SL=-630;SH=602;D=52444625D66FAAC6001B8;C=619;L=81;R=57;
Dispatch: YsA4888C4BACDF558C0037
SOMFY Unknown device 8A73E7 (A4 04C7), cmd=20 please define it


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 20 November 2021, 23:16:29
Zitat von: Ralf9 am 20 November 2021, 22:46:33
Dies ist ein bekanntes Problem, es gibt einige Somfy Fernbedienungen mit denen die firmware und das offizielle 00_SIGNALduino.pm Modul von sidey nicht zurecht kommt.
Z.B. die MC Nachrichten mit einer Länge von L=81, da ist am Anfang ein Bit zuviel.

Habs mal mit meinem angepasstem 00_SIGNALduino.pm Modul  und einem dummy sduino simuliert, da passt es:
MC;LL=-1274;LH=1215;SL=-644;SH=598;D=52444625D66FAAE2000C8;C=621;L=81;R=57;
Dispatch: YsA4888C4BACDF55C40019
SOMFY Unknown device 8A73E7 (A4 04C7), cmd=20 please define it

MC;LL=-1259;LH=1229;SL=-630;SH=602;D=52444625D66FAAC6001B8;C=619;L=81;R=57;
Dispatch: YsA4888C4BACDF558C0037
SOMFY Unknown device 8A73E7 (A4 04C7), cmd=20 please define it


Gruß Ralf

Ok, dies bedeutet nun, dein Modul nehmen und alles wird gut?!
Werde ich morgen ausprobieren.

Mir ist allerdings noch was anderes aufgefallen.
Ich habe um ca. 22:57:35 (Zeit von fhem via ssh) den Rolladen mit der Fernbedienung bedient (nicht neben dem sduino, sondern weiter weg).
Im Log erscheint jedoch ca. eine Minute später erst etwas was für mich nach etwas empfangenem aussieht.
Kann dies sein, was braucht da so viel Zeit, oder liegt dies an den 8MHz?


2021.11.20 22:57:11.034 4: mySignalduino: HandleWriteQueue, nothing to send, stopping timer
2021.11.20 22:58:10.723 4: mySignalduino: KeepAlive, ok, retry = 0
2021.11.20 22:58:38.624 4: mySignalduino: Read, msg: MC;LL=-1280;LH=1269;SL=-643;SH=624;D=8751622;C=635;L=27;R=243;
2021.11.20 22:58:38.720 4: mySignalduino: Read, msg: MC;LL=-1289;LH=1265;SL=-639;SH=629;D=81111110;C=636;L=30;R=249;
2021.11.20 22:58:38.720 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -77.5 -> Oregon Scientific PIR
2021.11.20 22:58:38.720 5: mySignalduino: Parse_MC, extracted data 01111110111011101110111011101111 (bin)
2021.11.20 22:58:38.720 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:38.906 4: mySignalduino: Read, msg: MC;LL=-1273;LH=1251;SL=-644;SH=632;D=02222221D4588;C=633;L=50;R=245;
2021.11.20 22:58:38.906 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 633 RSSI = -79.5 -> Oregon Scientific PIR
2021.11.20 22:58:38.906 5: mySignalduino: Parse_MC, extracted data 1111110111011101110111011101111000101011101001110111 (bin)
2021.11.20 22:58:38.906 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:38.964 4: mySignalduino: Read, msg: MC;LL=-1277;LH=1272;SL=-636;SH=641;D=502222221D0;C=637;L=41;R=245;
2021.11.20 22:58:38.964 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -79.5 -> Oregon Scientific PIR
2021.11.20 22:58:38.964 5: mySignalduino: Parse_MC, extracted data 10101111110111011101110111011101111000101111 (bin)
2021.11.20 22:58:38.964 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:43.218 4: mySignalduino: Read, msg: MC;LL=-1287;LH=1269;SL=-638;SH=615;D=4444443A8B11;C=634;L=48;R=245;
2021.11.20 22:58:43.218 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 634 RSSI = -79.5 -> Oregon Scientific PIR
2021.11.20 22:58:43.218 5: mySignalduino: Parse_MC, extracted data 101110111011101110111011110001010111010011101110 (bin)
2021.11.20 22:58:43.218 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:43.263 5: mySignalduino: Read, RAW rmsg: Mu;���;��;���;���;���;���;���;���;D#CEeeeecEecEecEecEecEecG;C6;RF5;
2021.11.20 22:58:43.263 4: mySignalduino: Read, msg READredu: MU;P0=112;P1=-360;P2=2088;P3=-1264;P4=1294;P5=-646;P6=624;P7=-248;D=01234345656565656345656345656345656345656345656347;CP=6;R=245;
2021.11.20 22:58:43.263 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 8 -> TX3 Protocol matches, trying to demodulate
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|65){43,})) did not match
2021.11.20 22:58:43.264 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 9 -> weather matches, trying to demodulate
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:63|43){60,}(?:6|4)?)) did not match
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, start pattern for MU protocol id 13.1 -> FLAMINGO FA22RF / FA21RF / LM-101LD not found, aborting
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, start pattern for MU protocol id 16 -> Dooya not found, aborting
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, start pattern for MU protocol id 21 -> Einhell Garagedoor not found, aborting
2021.11.20 22:58:43.264 5: mySignalduino: Parse_MU, start pattern for MU protocol id 24 -> Visivo remote not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 26 -> xavax not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 28 -> IC Ledspot not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 29 -> HT12e not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 30 -> diverse not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 31 -> LTECH not found, aborting
2021.11.20 22:58:43.265 5: mySignalduino: Parse_MU, start pattern for MU protocol id 32 -> wireless doorbell not found, aborting
2021.11.20 22:58:43.265 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2021.11.20 22:58:43.266 5: mySignalduino: Parse_MU, part is 5656565634565634565634565634565634565634 starts at position 0 and ends at 41
2021.11.20 22:58:43.266 5: mySignalduino: Parse_MU, Starting demodulation (StartStr: 6 first found at 8 regex: (?:6)((?:34|56){19,}(?:5|3)?) Pos 8) length_min_max (19..20) length=20
2021.11.20 22:58:43.266 5: mySignalduino: Parse_MU, dispatching hex: P34#09249
2021.11.20 22:58:43.266 4: mySignalduino: Parse_MU, Decoded matched MU protocol id 34 dmsg P34#09249 length 20 dispatch(1/4) RSSI = -79.5
2021.11.20 22:58:43.266 5: mySignalduino: Dispatch, P34#09249, test ungleich: disabled
2021.11.20 22:58:43.266 5: mySignalduino: Dispatch, P34#09249, -79.5 dB, dispatch
2021.11.20 22:58:43.266 5: mySignalduino: dispatch P34#09249
2021.11.20 22:58:43.289 4: mySignalduino: SD_UT protocol 34, bitData 00001001001001001001, hlen 5
2021.11.20 22:58:43.289 1: mySignalduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 09249, code 092
2021.11.20 22:58:43.293 5: mySignalduino: Parse_MU, start pattern for MU protocol id 36 -> remote not found, aborting
2021.11.20 22:58:43.293 5: mySignalduino: Parse_MU, for MU protocol id 39, applying filterfunc SIGNALduino_compPattern
2021.11.20 22:58:43.293 5: mySignalduino: Parse_MU, start pattern for MU protocol id 39 -> X10 Protocol not found, aborting
2021.11.20 22:58:43.294 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 42 -> wireless doorbell matches, trying to demodulate
2021.11.20 22:58:43.294 5: mySignalduino: Parse_MU, 0. try, regex ((?:656565)((?:65|45){28,})) did not match
2021.11.20 22:58:43.294 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44 -> BresserTemeo not found, aborting
2021.11.20 22:58:43.294 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44.1 -> BresserTemeo not found, aborting
2021.11.20 22:58:43.294 5: mySignalduino: Parse_MU, start pattern for MU protocol id 45 -> Revolt not found, aborting
2021.11.20 22:58:43.295 5: mySignalduino: Parse_MU, start pattern for MU protocol id 46 -> SKXxxx, GF0x0x not found, aborting
2021.11.20 22:58:43.295 5: mySignalduino: Parse_MU, start pattern for MU protocol id 48 -> TFA Dostmann not found, aborting
2021.11.20 22:58:43.295 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.1 -> GT-9000 not found, aborting
2021.11.20 22:58:43.295 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.2 -> GT-9000 not found, aborting
2021.11.20 22:58:43.295 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2021.11.20 22:58:43.295 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:63|43){47,}(?:6|4)?)) did not match
2021.11.20 22:58:43.296 5: mySignalduino: Parse_MU, start pattern for MU protocol id 56 -> AC114-xxB not found, aborting
2021.11.20 22:58:43.296 5: mySignalduino: Parse_MU, start pattern for MU protocol id 59 -> AK-HD-4 not found, aborting
2021.11.20 22:58:43.296 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2021.11.20 22:58:43.296 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|01){30,})) did not match
2021.11.20 22:58:43.296 5: mySignalduino: Parse_MU, start pattern for MU protocol id 62 -> Clarus_Switch not found, aborting
2021.11.20 22:58:43.297 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2021.11.20 22:58:43.297 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:63|43){48,})) did not match
2021.11.20 22:58:43.297 5: mySignalduino: Parse_MU, start pattern for MU protocol id 66 -> WS7035 not found, aborting
2021.11.20 22:58:43.297 5: mySignalduino: Parse_MU, start pattern for MU protocol id 69 -> Hoermann not found, aborting
2021.11.20 22:58:43.297 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2021.11.20 22:58:43.297 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|01){50,})) did not match
2021.11.20 22:58:43.298 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 71 -> PEARL matches, trying to demodulate
2021.11.20 22:58:43.298 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|23){48,})) did not match
2021.11.20 22:58:43.298 5: mySignalduino: Parse_MU, start pattern for MU protocol id 72 -> Siro shutter not found, aborting
2021.11.20 22:58:43.298 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2021.11.20 22:58:43.298 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|01){59,})) did not match
2021.11.20 22:58:43.299 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2021.11.20 22:58:43.299 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|01){50,})) did not match
2021.11.20 22:58:43.299 5: mySignalduino: Parse_MU, start pattern for MU protocol id 76 -> LED XM21 not found, aborting
2021.11.20 22:58:43.299 5: mySignalduino: Parse_MU, start pattern for MU protocol id 78 -> BeSmart_Sx not found, aborting
2021.11.20 22:58:43.299 5: mySignalduino: Parse_MU, start pattern for MU protocol id 79 -> wireless doorbell not found, aborting
2021.11.20 22:58:43.299 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2021.11.20 22:58:43.299 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:65|01){104,})) did not match
2021.11.20 22:58:43.300 5: mySignalduino: Parse_MU, start pattern for MU protocol id 81 -> SA-434-1 not found, aborting
2021.11.20 22:58:43.300 5: mySignalduino: Parse_MU, start pattern for MU protocol id 83 -> RH787T not found, aborting
2021.11.20 22:58:43.300 5: mySignalduino: Parse_MU, start pattern for MU protocol id 86 -> BOSCH | CAME | Novy | Neff | Refsta Topdraft not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 91 -> Atlantic security not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 92 -> KRINNER Lumix not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 94 -> Atech not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 97 -> Momento not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 98 -> GEA-028DB not found, aborting
2021.11.20 22:58:43.301 5: mySignalduino: Parse_MU, start pattern for MU protocol id 99 -> Navaris 44344.04 not found, aborting
2021.11.20 22:58:43.302 5: mySignalduino: Parse_MU, start pattern for MU protocol id 104 -> TR60C-1 not found, aborting
2021.11.20 22:58:43.302 5: mySignalduino: Parse_MU, start pattern for MU protocol id 105 -> BF-301 not found, aborting
2021.11.20 22:58:43.302 5: mySignalduino: Parse_MU, start pattern for MU protocol id 110 -> ADE_WS_1907 not found, aborting
2021.11.20 22:58:43.302 5: mySignalduino: Parse_MU, start pattern for MU protocol id 111 -> TS-FT002 not found, aborting
2021.11.20 22:58:43.302 5: mySignalduino: Parse_MU, start pattern for MU protocol id 114 -> TR401 not found, aborting
2021.11.20 22:58:43.503 4: mySignalduino: Read, msg: MC;LL=-1282;LH=1284;SL=-647;SH=613;D=A04444443A8B11;C=637;L=56;R=244;
2021.11.20 22:58:43.503 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 637 RSSI = -80 -> Somfy RTS
2021.11.20 22:58:43.503 5: mySignalduino: Parse_MC, extracted data 10100000010001000100010001000100001110101000101100010001 (bin)
2021.11.20 22:58:43.503 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001 (56)
2021.11.20 22:58:43.503 5: mySignalduino: Dispatch, YsA04444443A8B11, test ungleich: disabled
2021.11.20 22:58:43.503 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 22:58:43.503 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 22:58:43.503 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 22:58:43.506 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:43.506 5: mySignalduino: Parse_MC, extracted data 01011111101110111011101110111011110001010111010011101110 (bin)
2021.11.20 22:58:43.506 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:43.615 4: mySignalduino: Read, msg: MC;LL=-1283;LH=1273;SL=-649;SH=615;D=A04444443A8B11;C=636;L=56;R=244;
2021.11.20 22:58:43.615 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 636 RSSI = -80 -> Somfy RTS
2021.11.20 22:58:43.615 5: mySignalduino: Parse_MC, extracted data 10100000010001000100010001000100001110101000101100010001 (bin)
2021.11.20 22:58:43.615 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001 (56)
2021.11.20 22:58:43.615 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 22:58:43.615 4: mySignalduino: Dispatch, YsA04444443A8B11, Dropped due to short time or equal msg
2021.11.20 22:58:43.615 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:43.615 5: mySignalduino: Parse_MC, extracted data 01011111101110111011101110111011110001010111010011101110 (bin)
2021.11.20 22:58:43.615 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:43.934 4: mySignalduino: Read, msg: MC;LL=-1282;LH=1275;SL=-643;SH=620;D=2221D45888;C=636;L=37;R=244;
2021.11.20 22:58:43.935 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:43.947 5: mySignalduino: Parse_MC, extracted data 1101110111011110001010111010011101110111 (bin)
2021.11.20 22:58:43.947 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:46.861 4: mySignalduino: Read, msg: MC;LL=-1270;LH=1278;SL=-636;SH=621;D=502222221D45888;C=634;L=57;R=244;
2021.11.20 22:58:46.861 4: mySignalduino: Parse_MC, Found manchester protocol id 43 clock 634 RSSI = -80 -> Somfy RTS
2021.11.20 22:58:46.862 5: mySignalduino: Parse_MC, extracted data 010100000010001000100010001000100001110101000101100010001000 (bin)
2021.11.20 22:58:46.862 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 010100000010001000100010001000100001110101000101100010001000 (57)
2021.11.20 22:58:46.862 4: mySignalduino: lib/mcBit2SomfyRTS, bitdata: 10100000010001000100010001000100001110101000101100010001, truncated to length: 56
2021.11.20 22:58:46.862 5: mySignalduino: Dispatch, YsA04444443A8B11, test gleich
2021.11.20 22:58:46.862 5: mySignalduino: Dispatch, YsA04444443A8B11, -80 dB, dispatch
2021.11.20 22:58:46.862 5: mySignalduino: dispatch YsA04444443A8B11
2021.11.20 22:58:46.862 4: mySignalduino: Somfy RTS preprocessing check: 4 enc: A04444443A8B11 dec: A0E400007EB19A
2021.11.20 22:58:46.865 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 634 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:46.865 5: mySignalduino: Parse_MC, extracted data 101011111101110111011101110111011110001010111010011101110111 (bin)
2021.11.20 22:58:46.865 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:46.941 4: mySignalduino: Read, msg: MC;LL=-1286;LH=1263;SL=-651;SH=613;D=1D45888;C=635;L=25;R=244;
2021.11.20 22:58:47.193 5: mySignalduino: Read, RAW rmsg: Mu;���;�ȃ;���;�؄;���;���;��;d######e##`;C4;RF2;
2021.11.20 22:58:47.193 4: mySignalduino: Read, msg READredu: MU;P0=-685;P1=840;P2=-1309;P3=1240;P4=636;P5=264;P6=-15980;D=01232304040404042304042304042304042305650323236;CP=4;R=242;
2021.11.20 22:58:47.194 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 8 -> TX3 Protocol matches, trying to demodulate
2021.11.20 22:58:47.194 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|40){43,})) did not match
2021.11.20 22:58:47.194 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 9 -> weather matches, trying to demodulate
2021.11.20 22:58:47.194 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|30){60,}(?:4|3)?)) did not match
2021.11.20 22:58:47.194 5: mySignalduino: Parse_MU, start pattern for MU protocol id 13.1 -> FLAMINGO FA22RF / FA21RF / LM-101LD not found, aborting
2021.11.20 22:58:47.195 5: mySignalduino: Parse_MU, start pattern for MU protocol id 16 -> Dooya not found, aborting
2021.11.20 22:58:47.195 5: mySignalduino: Parse_MU, start pattern for MU protocol id 21 -> Einhell Garagedoor not found, aborting
2021.11.20 22:58:47.195 5: mySignalduino: Parse_MU, start pattern for MU protocol id 24 -> Visivo remote not found, aborting
2021.11.20 22:58:47.195 5: mySignalduino: Parse_MU, start pattern for MU protocol id 26 -> xavax not found, aborting
2021.11.20 22:58:47.196 5: mySignalduino: Parse_MU, start pattern for MU protocol id 28 -> IC Ledspot not found, aborting
2021.11.20 22:58:47.196 5: mySignalduino: Parse_MU, start pattern for MU protocol id 29 -> HT12e not found, aborting
2021.11.20 22:58:47.196 5: mySignalduino: Parse_MU, start pattern for MU protocol id 30 -> diverse not found, aborting
2021.11.20 22:58:47.196 5: mySignalduino: Parse_MU, start pattern for MU protocol id 31 -> LTECH not found, aborting
2021.11.20 22:58:47.196 5: mySignalduino: Parse_MU, start pattern for MU protocol id 32 -> wireless doorbell not found, aborting
2021.11.20 22:58:47.196 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2021.11.20 22:58:47.197 5: mySignalduino: Parse_MU, 0. try, regex ((?:4)((?:03|04){19,}(?:0)?)) did not match
2021.11.20 22:58:47.197 5: mySignalduino: Parse_MU, start pattern for MU protocol id 36 -> remote not found, aborting
2021.11.20 22:58:47.197 5: mySignalduino: Parse_MU, for MU protocol id 39, applying filterfunc SIGNALduino_compPattern
2021.11.20 22:58:47.197 5: mySignalduino: Parse_MU, start pattern for MU protocol id 39 -> X10 Protocol not found, aborting
2021.11.20 22:58:47.198 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 42 -> wireless doorbell matches, trying to demodulate
2021.11.20 22:58:47.198 5: mySignalduino: Parse_MU, 0. try, regex ((?:404040)((?:40|30){28,})) did not match
2021.11.20 22:58:47.198 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44 -> BresserTemeo not found, aborting
2021.11.20 22:58:47.198 5: mySignalduino: Parse_MU, start pattern for MU protocol id 44.1 -> BresserTemeo not found, aborting
2021.11.20 22:58:47.198 5: mySignalduino: Parse_MU, start pattern for MU protocol id 45 -> Revolt not found, aborting
2021.11.20 22:58:47.198 5: mySignalduino: Parse_MU, start pattern for MU protocol id 48 -> TFA Dostmann not found, aborting
2021.11.20 22:58:47.199 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.1 -> GT-9000 not found, aborting
2021.11.20 22:58:47.199 5: mySignalduino: Parse_MU, start pattern for MU protocol id 49.2 -> GT-9000 not found, aborting
2021.11.20 22:58:47.199 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 50 -> Opus_XT300 matches, trying to demodulate
2021.11.20 22:58:47.199 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|30){47,}(?:4|3)?)) did not match
2021.11.20 22:58:47.199 5: mySignalduino: Parse_MU, start pattern for MU protocol id 56 -> AC114-xxB not found, aborting
2021.11.20 22:58:47.199 5: mySignalduino: Parse_MU, start pattern for MU protocol id 59 -> AK-HD-4 not found, aborting
2021.11.20 22:58:47.200 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 61 -> FS10 matches, trying to demodulate
2021.11.20 22:58:47.200 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:50|50){30,})) did not match
2021.11.20 22:58:47.200 5: mySignalduino: Parse_MU, start pattern for MU protocol id 62 -> Clarus_Switch not found, aborting
2021.11.20 22:58:47.200 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 64 -> WH2 matches, trying to demodulate
2021.11.20 22:58:47.200 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|30){48,})) did not match
2021.11.20 22:58:47.200 5: mySignalduino: Parse_MU, start pattern for MU protocol id 66 -> WS7035 not found, aborting
2021.11.20 22:58:47.201 5: mySignalduino: Parse_MU, start pattern for MU protocol id 69 -> Hoermann not found, aborting
2021.11.20 22:58:47.201 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 70 -> FHT80TF matches, trying to demodulate
2021.11.20 22:58:47.201 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|50){50,})) did not match
2021.11.20 22:58:47.201 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 71 -> PEARL matches, trying to demodulate
2021.11.20 22:58:47.201 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|32){48,})) did not match
2021.11.20 22:58:47.201 5: mySignalduino: Parse_MU, start pattern for MU protocol id 72 -> Siro shutter not found, aborting
2021.11.20 22:58:47.201 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 73 -> FHT80 matches, trying to demodulate
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|50){59,})) did not match
2021.11.20 22:58:47.202 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 74 -> FS20 matches, trying to demodulate
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:40|50){50,})) did not match
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, start pattern for MU protocol id 76 -> LED XM21 not found, aborting
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, start pattern for MU protocol id 78 -> BeSmart_Sx not found, aborting
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, start pattern for MU protocol id 79 -> wireless doorbell not found, aborting
2021.11.20 22:58:47.202 4: mySignalduino: Parse_MU, Fingerprint for MU protocol id 80 -> EM1000WZ matches, trying to demodulate
2021.11.20 22:58:47.202 5: mySignalduino: Parse_MU, 0. try, regex ((?:)((?:50|50){104,})) did not match
2021.11.20 22:58:47.203 5: mySignalduino: Parse_MU, start pattern for MU protocol id 83 -> RH787T not found, aborting
2021.11.20 22:58:47.203 5: mySignalduino: Parse_MU, start pattern for MU protocol id 91 -> Atlantic security not found, aborting
2021.11.20 22:58:47.203 5: mySignalduino: Parse_MU, start pattern for MU protocol id 92 -> KRINNER Lumix not found, aborting
2021.11.20 22:58:47.203 5: mySignalduino: Parse_MU, start pattern for MU protocol id 94 -> Atech not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 95 -> Techmar not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 97 -> Momento not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 98 -> GEA-028DB not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 99 -> Navaris 44344.04 not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 104 -> TR60C-1 not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 105 -> BF-301 not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 110 -> ADE_WS_1907 not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 111 -> TS-FT002 not found, aborting
2021.11.20 22:58:47.204 5: mySignalduino: Parse_MU, start pattern for MU protocol id 114 -> TR401 not found, aborting
2021.11.20 22:58:50.918 4: mySignalduino: Read, msg: MC;LL=-1265;LH=1293;SL=-632;SH=643;D=0888888751622;C=638;L=51;R=244;
2021.11.20 22:58:50.919 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 638 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:50.919 5: mySignalduino: Parse_MC, extracted data 1111011101110111011101110111100010101110100111011101 (bin)
2021.11.20 22:58:50.919 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:51.030 4: mySignalduino: Read, msg: MC;LL=-1282;LH=1266;SL=-628;SH=622;D=8751622;C=632;L=27;R=243;
2021.11.20 22:58:51.186 4: mySignalduino: Read, msg: MC;LL=-1282;LH=1272;SL=-642;SH=631;D=11110EA2C4;C=637;L=40;R=244;
2021.11.20 22:58:51.186 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 637 RSSI = -80 -> Oregon Scientific PIR
2021.11.20 22:58:51.187 5: mySignalduino: Parse_MC, extracted data 1110111011101110111100010101110100111011 (bin)
2021.11.20 22:58:51.187 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:58:51.822 4: mySignalduino: Read, msg: MC;LL=-1261;LH=1287;SL=-628;SH=641;D=444443A8B11;C=636;L=44;R=245;
2021.11.20 22:58:51.822 4: mySignalduino: Parse_MC, Found manchester protocol id 52 clock 636 RSSI = -79.5 -> Oregon Scientific PIR
2021.11.20 22:58:51.822 5: mySignalduino: Parse_MC, extracted data 10111011101110111011110001010111010011101110 (bin)
2021.11.20 22:58:51.822 5: mySignalduino: Parse_MC, protocol does not match return from method: (undef)
2021.11.20 22:59:10.724 4: mySignalduino: KeepAlive, ok, retry = 0
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 20 November 2021, 23:41:38
Mein 00_SIGNALduino.pm Modul optimiert nur den Empfang von Somfy Nachrichten
https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881

Beim Senden sollte es eigentlich egal sein welche firmware und 00_SIGNALduino.pm Modul  Du verwendest.

ZitatIm Log erscheint jedoch ca. eine Minute später erst etwas was für mich nach etwas empfangenem aussieht.
Kann dies sein, was braucht da so viel Zeit, oder liegt dies an den 8MHz?
Nach so einer Verzögerung kann es eigentlich nicht mehr die Somfy Fernbedienung sein, ist es evtl ein Sensor vom Nachbarn?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 21 November 2021, 09:36:52
Zitat von: Ralf9 am 20 November 2021, 23:41:38
...
Nach so einer Verzögerung kann es eigentlich nicht mehr die Somfy Fernbedienung sein, ist es evtl ein Sensor vom Nachbarn?

Also das glaub ich so langsam auch, denn es wurden heute Nacht auch Somfy Nachrichten Empfangen und 4 Somfy Geräte angelegt obwohl ich die Rolläden nicht bewegt hatte.
Kann irgendjemand noch etwas zu den 8MHz sagen bzw bestätigen, daß diese funktionieren?

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 21 November 2021, 11:30:33
Hat evtl ein Nachbar auch Somfy?
Zitat
Kann irgendjemand noch etwas zu den 8MHz sagen bzw bestätigen, daß diese funktionieren?
Die 8MHz funktionieren stabil, wenn Du beim sduino eine uptime kleiner 30 Tage hast, dann passt was nicht mit der firmware oder Hardware. 

Du hast wahrscheinlich die Verkabelung vom nanoCul verwendet:
PIN_SEND            3   // gdo0 Pin
PIN_RECEIVE         2  //  gdo2 Pin


Der MiniCul hat auch 8MHz und 3.3V, dafür gibts auch eine Firmware.
Die PIN_SEND und PIN_RECEIVE sind da aber vertauscht:
PIN_RECEIVE     3   // gdo2 Pin
PIN_SEND        2  //  gdo0 Pin


Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 21 November 2021, 16:10:53
Zitat von: Ralf9 am 21 November 2021, 11:30:33
Hat evtl ein Nachbar auch Somfy?Die 8MHz funktionieren stabil, wenn Du beim sduino eine uptime kleiner 30 Tage hast, dann passt was nicht mit der firmware oder Hardware. 

Du hast wahrscheinlich die Verkabelung vom nanoCul verwendet:
PIN_SEND            3   // gdo0 Pin
PIN_RECEIVE         2  //  gdo2 Pin


Der MiniCul hat auch 8MHz und 3.3V, dafür gibts auch eine Firmware.
Die PIN_SEND und PIN_RECEIVE sind da aber vertauscht:
PIN_RECEIVE     3   // gdo0 Pin
PIN_SEND        2  //  gdo2 Pin


Gruß Ralf

Hallo Ralf9,

ja ich vermute das mein Nachbar auch Somfy hat. Er hat zumindest aussen so einen Windsensor für eine Markise hängen, und ich habe folgendes Somfy Device bei mir gefunden:

Internals:
   ADDRESS    68C6FA
   DEF        68C6FA
   FUUID      61997328-f33f-62d8-4f62-06269ab5d8f4ad85
   IODev      mySignalduino
   NAME       SOMFY_68C6FA
   NR         297
   STATE      ???
   TYPE       SOMFY
   move       stop
   CODE:
     1          68C6FA
   READINGS:
     2021-11-21 15:38:50   IODev           mySignalduino
     1970-01-01 01:00:00   enc_key         81
     2021-11-21 08:06:42   parsestate      wind_sun_9
     2021-11-21 08:06:42   received        90
     1970-01-01 01:00:00   rolling_code    0001
   hmccu:
Attributes:
   DbLogExclude .*
   model      somfyshutter
   room       SOMFY

Eventuell haben auch meine beiden Nachbarn Somfy, da beides relativ gleich alte Schwörer Häuser sind.

Zur Uptime kann ich noch nichts sagen, da ich momentan immer wieder neu starte usw.
Nach der Pinbelegung müsste es ein MiniCul sein.
Wobei ich der Meinung bin, daß Dir in deinem vorherigen Post ein Fehler unterlaufen ist.

NanoCUL
PIN_SEND            3   // gdo0 Pin
PIN_RECEIVE         2  //  gdo2 Pin

MiniCul
PIN_RECEIVE     3   // gdo2 Pin <-- Kommentar gd0 und gd2 in deinem vorherigen Post vertauscht
PIN_SEND        2  //  gdo0 Pin


Du schreibst das es hierzu auch eine Firmware gibt, diese ist dann vermutlich von Dir, https://github.com/Ralf9/SIGNALDuino/blob/master/firmware/SIGNALduino_miniCUL_3321rc8.hex oder würdest Du eine andere empfehlen?

Ich werde nun mal deine Firmware versuchen.

Mfg Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 21 November 2021, 17:35:02
ZitatWobei ich der Meinung bin, daß Dir in deinem vorherigen Post ein Fehler unterlaufen ist.
Stimmt, habs korrigiert.

Eine firmware für den Minicul gibts von sidey und von mir.
Meine aktuelle ist die 3.3.2.1-rc9
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.2.1-rc9

"SIGNALduino_3v3prominiCC1101_3321rc9.hex" ist für die nanocul Belegung.

Wenn Du nur senden willst, ist es egal welche firmware Du verwendest.
Meine firmware hat Vorteile bei nicht optimalen Empfangsbedingungen.

Gruß Ralf
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Stephan.K am 21 November 2021, 18:52:36
Also, ich hab nun doch nen nanocul.
Mit deiner FW SIGNALduino_3v3prominiCC1101_3321rc9.hex geflasht und siehe das die Rolläden lassen sich anlernen uns funktionieren.

Jetzt muß ich mir noch anschauen wie dies mit den auf/zu Zeiten usw funktioniert, bzw wie ich am besten das morgendliche öffnen und abendliche schließen realisieren.
Sollte hierzu jemand Empfehlungen habe, nur her damit.

Vielen Danks ans Forum für die Hilfe und ganz besonders an Ralf9.

MfG Stephan
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: McShire am 21 November 2021, 22:42:55
Hallo Stephan,

Jetzt doch der Standard.
ich habe dazu einen Helligkeitsensor Homematic (Selbstbau mit der AskSinpp Hardware und dem BH1750) mit dem
ich unter anderem Rolläden steuere. Das halte ich für besser, als nach der Uhrzeit oder sunrise und sunset zu steuern.


([HM_xxxxxx1:state:d] > 40)
      ( set tahoma_xxxxxxx dim 0) ## Rolladen WoZi auf
      ( set RolloDach off)        ## Rolladen Dachfenster Schlafzimmer auf
      { if(strftime('%H', localtime) < 10) {fhem 'set morgen_ende '.strftime('%H:%M' , localtime(time+10*60))} }
                                           ## Dummy auf die Zeit zur Steuerung der Schaltuhren setzen.
   DOELSEIF ([HM_xxxxxx:state:d] < 30)
      ( set tahoma_xxxxxxx dim 20, ### zur Vorwarnung, damit man nicht auf der Terrasse ausgeschlossen wird
        defmod r1 at +00:10:00
              {if (ReadingsVal('HM_xxxxxx', 'brightness', 0) < 41) {fhem 'set tahoma_xxxxxxx dim 100'} }
           ##;; {if(strftime('%H', localtime) > 15) {fhem 'set abend_start '.strftime('%H:%M', localtime(time+11*60))} }
           ## letzte Zeile nur aktivieren, wenn der Abend beginnen soll, wenn der
           ## Rolladen ganz unten ist, r1 überschreibt dann die Zeit, die sonst
           ## unten sofort gesetzt wird, nach 10 min (at +00:10:00)
       )
       ( attr r1 room Schaltuhren )
       ## naechste Zeile auskommentieren, wenn oben die Zeit gesetzt wird.
       { if(strftime('%H', localtime) > 15) {fhem 'set abend_start '.strftime('%H:%M', localtime(time+11*60)) }}

       ## warum oben die Anweisung:
       ##{ if (ReadingsVal('HM_xxxxxx', 'brightness', 0) < 41)  {fhem 'set tahoma_xxxxxxx dim 100'} } ?
            ## bei Helligkeitsschwankungen am Morgen
            ## falls Helligkeit > 40, ist es wieder heller und der Rolladen ist wieder hoch,
            ## wenn er dann mit durch die at Anweisung wieder schließt, geht er danach nicht wieder hoch,
            ## weil die DOIF im State cmd1 ist und deshalb cmd1 nicht noch einmal ausführt.


Viele Grüße
Werner
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: fhem@supergut am 28 Januar 2022, 15:36:29
Zitat von: Ralf9 am 01 Juni 2017, 20:50:06
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.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 28 Januar 2022, 17:20:45
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Januar 2022, 12:08:11
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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 30 Januar 2022, 13:52:54
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 (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://electronics.stackexchange.com/questions/135767/high-frequency-logic-level-conversion)
https://circuitdigest.com/tutorial/bi-directional-logic-level-controller-using-mosfet (https://circuitdigest.com/tutorial/bi-directional-logic-level-controller-using-mosfet)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 Januar 2022, 20:42:14
ZitatMit welchem Takt läuft der SPI beim SIGNALduino eigentlich?
Beim nano sinds 4 MHz (SPI speed = CLK/4)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 29 November 2022, 15:05:11
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:
Zitat
/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)
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)
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
one => [-2,1],
zero => [-1,2],
start => [-43,1],
clockabs => 342,


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 29 November 2022, 17:50:20
Bei der aktuellen Version von Sidey (https://github.com/RFD-FHEM/RFFHEM)

   versionProtocols 1.48
   versionmodul 3.5.4+20221126


ist dafür genau eine Datei zuständig:

/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.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 29 November 2022, 18:47:39
Zitat von: elektron-bbs am 29 November 2022, 17:50:20
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 (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?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 November 2022, 20:30:13
Bei meiner Variante der 00_SIGNALDuino.pm ist es die signalduino_protocols.pm

Du kannst mal testweise die clockabs anpassen
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 29 November 2022, 20:48:42
Ach so, deshalb der Hickhack mit den verschiedenen Dateien :-(
Die Rohdaten sehen auch eher nach deiner Version aus:

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-
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 29 November 2022, 21:15:45
Zitat von: Ralf9 am 29 November 2022, 20:30:13
Du kannst mal testweise die clockabs anpassen
Danach die Datei neu einlesen? Aber wie?
ZitatCan't read ./FHEM/signalduino_protocols.pm
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 29 November 2022, 22:29:13
ZitatDanach die Datei neu einlesen? Aber wie?
mit einem fhem neustart

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

reload lib/signalduino_protocols.pm
ergibt
Can't read ./FHEM/libsignalduino_protocols.pm: No such file or directory
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 30 November 2022, 08:00:03
Du kannst auch mit "set sduino raw" senden, da kannst Du dann direkt die Pulszeiten anpassen
set sduino raw SR;R=10;P0=-15400;P1=350;P2=-700;P3=-350;P4=700;D=01212121342121213421212134;

Den Sendebefehl findest Du im Log
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;

Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 30 November 2022, 08:29:10
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?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 30 November 2022, 13:37:54
Hallo,
ich hätte da 2 Ideen:

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

Horst
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 30 November 2022, 14:10:01
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 (https://forum.pilight.org/showthread.php?tid=2771)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 30 November 2022, 14:11:23
Beim Mitschneiden ging es mir nicht ums Timing, sondern um die Pegel.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 30 November 2022, 14:14:08
Das stimmt, das ist eine gute Idee. Wie kann ich denn Pegel messen, welches Gerät müsste ich dazu nehmen?
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Harst am 30 November 2022, 14:16:48
Stichwort SDR, z.B. ein logilink vg0002a

Da gibt es Software aus dem Amateurradio-Bereich zu.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: x86 am 14 Januar 2023, 20:44:22
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:

        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!
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 14 Januar 2023, 21:27:26
Danke für die Info, ich schau mir das an
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 15 Januar 2023, 09:46:41
Zitat von: x86 am 14 Januar 2023, 20:44:22

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:

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
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: x86 am 15 Januar 2023, 23:20:15
Hi Sidey,

Zitat von: Sidey am 15 Januar 2023, 09:46:41
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
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Rainer1 am 09 August 2023, 09:00:52
Hallo, was ist denn z.Z. die Empfehlung zur Hardware ? Nano mit CUL1101 ?
Gibt es eine HARDWARESeite mit aktuellen Infos ?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 09 August 2023, 09:43:10
Zitat von: piuser1 am 09 August 2023, 09:00:52Hallo, 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 :)
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 09 August 2023, 20:13:58
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


Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: beaune am 12 August 2023, 16:25:01
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?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 13 August 2023, 23:02:05
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.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: beaune am 14 August 2023, 19:40:11
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:
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?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 14 August 2023, 19:44:12
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...
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 15 August 2023, 17:18:37
Zitat@Ralf9: kann man für SD_GT vielleicht etwas ähnliches wie ITclock bei IT einbauen?
Du kannst selber testen ob es eine Verbesserung bringt.

Dazu den sduino verbose auf 5 erhöhen, wenn dann zuviele Meldungen ins log kommen, kannst Du den Empfang mit "get raw XQ" ausschalten und hinterher mit "get raw XE" wieder einschalten.

Dann mit dem SD_GT device was senden.

Dann steht im log so was ähnliches:
... 5: sduino/write: sending via Set sendMsg P49#0xE6D12C#R4
... 5: sduino: sendmsg msg=P49#0xE6D12C#R4

Bei der sendmsg dann die clock anhängen z.B. "P49#0xE6D12C#R4#C460"

Dies dann mit set sendmsg senden, im log steht dann sowas ähnliches:
... 5: sduino: sendmsg Preparing rawsend command for protocol=49, repeats=4, clock=460 bits=111001101101000100101100
... 4: sduinoA/set: sending via SendMsg: SR;R=4;P0=460;P1=-2760;P2=1380;P3=-460;P4=-1380;D=01232323040423230423230423040404230404230423230404;


Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: beaune am 16 August 2023, 08:45:32
Danke, verstanden. Habs auch gleich probiert, aber tatsächlich schaltet das Device nicht mehr zuverlässig aus, auch bei geänderten clocks. Dann werde ich dieses Gerät einfach mal aussortieren
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 16 August 2023, 10:03:52
Hast Du auch mal versucht die repeats zu erhöhen oder die Frequenz am sduino zu ändern?
Sind die Batterien ok?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: beaune am 16 August 2023, 10:32:29
Ne hab ich nicht, aber einfach weil ich noch zwei andere Baugleiche Steckdosen habe, die einwandfrei funktionieren, und auch weitere Geräte, die über denselben sduino kommunizieren. Das ist schon ein Problem dieser einen Steckdose, die früher auch einwandfrei funktioniert hat. Interessant ist auch, dass auch die Fernbedienung nur noch abschaltet, wenn man unmittelbar neben der Steckdose steht. Sehr komisch, einschalten geht problemlos auch über große Entfernungen, abschalten nur wenn man daneben steht. Irgendwie läßt mich das auch nicht los,ich würds gerne verstehen, aber faktisch kann man es auch ignorieren, weil es nur um ein Gerät geht. Wär nur interessant, wenn sowas ähnliches nochmal irgendwo auftritt.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: frank am 16 August 2023, 11:07:25
everntuell erzeugt das netzteil im aktor im eigeschalteten zustand erhöhte störstrahlung, wodurch das funksignal zum ausschalten nicht mehr empfangen werden kann.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 16 August 2023, 20:51:20
Interessanter Aspekt, es könnte aber auch eines der an die Schaltsteckdose angeschlossenen Geräte sein. Also einfach mal Stecker ziehen und dann probieren, ob sich die Steckdose schalten lässt.
Man weiß ja nie, was Schaltnetzteile so an Störungen verbreiten. Ich hatte gerade so einen Fall: Von heute auf morgen plötzlich jede Menge CRC-Fehler auf einem 1-Wire-Bus. Es hat eine ganze Weile gedauert, bis ich bemerkt habe, das die Fehler immer dann auftraten, wenn das Notebook in Betrieb war. Netzteil getauscht und der Spuk war vorbei.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: beaune am 16 August 2023, 21:11:17
Bei den letzten Tests war nichts dran angeschlossen. Wenn es um Störstrahlung geht, kann es nur was internes in der Schaltsteckdose sein.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: andies am 17 August 2023, 20:39:57
Sind da Elkos verbaut? Ich habe mit alten Elkos zu oft böse Überraschungen erlebt.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 06 September 2023, 18:00:36
Ein paar bescheidene Fragen, nachdem ich bereits Stunden mit Lesen verbracht habe:

Es ist korrekt, dass ich das Modul SIGNALDuino nicht mit einem Standard-CUL, auf dem CULFW geflasht ist, nutzen kann?
Es ist korrekt, dass ich den Standard-CUL nicht mit einer anderen Firmware flashen kann, um ihn mit SIGNALDuino nutzen zu können?
Es ist korrekt, dass ein Maple-SignalDuino mit einem einzigen CC1101 auch zum jetzigen Zeitpunkt die beste Alternative darstellt, wenn ich auf jeden Fall einen per LAN angeschlossenen SIGNALDuino nutzen möchte? Oder was wären mit LAN die aktuellen Alternativen, die auch eine gewisse Zukunftssicherheit bieten?

Mein Anwendungsfall: einen Bresser 7in1-Sensor abgreifen und in FHEM über MQTT anderen Anwendungen zur Verfügung stellen. LAN deswegen, da ich nicht per USB an einen bestimmten LXC auf einem bestimmten Host binden will.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 September 2023, 18:12:25
Auf was für eine CUL Hardware möchstet Du eine sduino firmware flashen.

Für LAN gibts außer dem Maple-SignalDuino auch noch LAN zu seriell Umsetzer, z.B. das USR-TCP232-T2
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 06 September 2023, 18:15:11
Es ist ein busware CUL V3 bzw. V3.4
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 06 September 2023, 18:22:57
Für den culV3 gibts von mir eine firmware, das flashen ist aber etwas aufwändiger als beim NanoCul
https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.5-dev220529/SIGNALduino_culV3CC1101_onlyFsk_335dev20220521.hex
oder
https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.2.1-rc9/SIGNALduino_culV3CC1101_3321rc9.hex
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 06 September 2023, 18:27:35
Danke!

Dann werde ich mich in die Richtung noch mal belesen. Ist ein paar Jährchen her, dass ich den CUL mit CULFW geflasht habe.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 10 September 2023, 19:59:39
Habe es hinbekommen und es funktioniert grundsätzlich. Vielen Dank!

Mir ist aufgefallen, dass der Barometer-Wert / Luftdruck nicht dekodiert und in ein Reading umgewandelt wird. Habe ich da noch etwas nachzujustieren?

Das ist meine Definition:

defmod Bresser7in1 SD_WS SD_WS_207_AB9B
attr Bresser7in1 comment SD_WS_207_AB9B
attr Bresser7in1 event-min-interval .*:300
attr Bresser7in1 event-on-change-reading .*
attr Bresser7in1 mqttPublish *:topic={"WEATHER/$device/$reading"}
attr Bresser7in1 room SD_WS

setstate Bresser7in1 T: 24.9 H: 64 Ws: 0 Wg: 0 Wd: NW Lux: 316 UV: 0 R: 3.5
setstate Bresser7in1 2023-09-10 16:48:07 batteryChanged 0
setstate Bresser7in1 2023-09-10 19:58:19 batteryState ok
setstate Bresser7in1 2023-09-10 19:58:19 humidity 64
setstate Bresser7in1 2023-09-10 19:58:19 id AB9B
setstate Bresser7in1 2023-09-10 19:58:19 lux 316
setstate Bresser7in1 2023-09-10 19:58:19 rain 3.5
setstate Bresser7in1 2023-09-10 19:58:19 rain_total 3.5
setstate Bresser7in1 2023-09-10 19:58:19 state T: 24.9 H: 64 Ws: 0 Wg: 0 Wd: NW Lux: 316 UV: 0 R: 3.5
setstate Bresser7in1 2023-09-10 19:58:19 temperature 24.9
setstate Bresser7in1 2023-09-10 19:58:19 type Bresser_7in1
setstate Bresser7in1 2023-09-10 19:58:19 uv 0
setstate Bresser7in1 2023-09-10 19:58:19 windDirectionDegree 306
setstate Bresser7in1 2023-09-10 19:58:19 windDirectionText NW
setstate Bresser7in1 2023-09-10 19:58:19 windGust 0
setstate Bresser7in1 2023-09-10 19:58:19 windGust_kmh 0.0
setstate Bresser7in1 2023-09-10 19:58:19 windSpeed 0
setstate Bresser7in1 2023-09-10 19:58:19 windSpeed_kmh 0.0

Darüber hinaus habe ich noch ein Pool-Thermometer von Bresser, welches auf Kanal 7 an meine Wetterstation sendet. Kann ich diesen Sensor auch mit abfangen?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 10 September 2023, 21:31:58
ZitatMir ist aufgefallen, dass der Barometer-Wert / Luftdruck nicht dekodiert und in ein Reading umgewandelt wird. Habe ich da noch etwas nachzujustieren?
Der Luftdruck ist nicht dabei da er in der Basisstation gemessen wird.

ZitatDarüber hinaus habe ich noch ein Pool-Thermometer von Bresser, welches auf Kanal 7 an meine Wetterstation sendet. Kann ich diesen Sensor auch mit abfangen?
Wird der Pool-Thermometer auch an der Basisstation des Bresser 7in1 angezeigt.

Evtl wird der Pool-Thermometer als Protokoll ID 115 (Bresser comfort 6in1 (5in1 neu)) erkannt.

Du kannst mal mit sduino verbose 4 im log schauen ob da so was ähnliches steht:
4: sduino Parse_MN: Found 2-FSK Protocol id 115 length 56 RSSI = -70 -> Bresser comfort 6in1 (5in1 neu)
4: sduino Dispatch: W115#...
4: sduino SD_WS_Parse protocol 115
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 11 September 2023, 05:13:05
Perfekt, genau so wurde der Sensor gefunden und ist nun auch eingebunden, vielen Dank!
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 September 2023, 11:32:47
Bitte poste mal ein paar MN-Nachrichten des Pool-Thermometers, ich möchte es mir mal anschauen.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 11 September 2023, 13:36:59
MN;D=1B3F22C000B43F00000000002756000000ADFFFF0700000000000000;N=7;R=215;
MN;D=1B3F22C000B43F00000000002756000000ADFFFF0700000000000000;N=7;R=210;
MN;D=37D622C000B43F000000000027660000009DFFFF0700000000000000;N=7;R=212;

Im Logfile sieht das mit Verbose 4 so aus:

2023.09.11 17:07:03 4: SIGNALduino/msg READ: ␂MN;D=B0790131AD2A18AAAAAAAAAA9FFC9B3A99A98E2BA89AAAAAAA000000;N=7;R=237;␃
2023.09.11 17:07:03 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:03 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=C272 crcRef=B079
2023.09.11 17:07:03 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:03 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B0780B2000000000035563190330324810230000000
2023.09.11 17:07:03 4: SIGNALduino Dispatch: W207#AB9B0780B2000000000035563190330324810230000000, -83.5 dB, dispatch
2023.09.11 17:07:03 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B0780B2000000000035563190330324810230000000
2023.09.11 17:07:03 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.11 17:07:03 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.11 17:07:05 4: SIGNALduino/keepalive ok, retry = 0
2023.09.11 17:07:07 4: SIGNALduino/msg READ: ␂MN;D=BA0B22C000B43F00000000002916000000EBFFFF0700000000000000;N=7;R=218;␃
2023.09.11 17:07:07 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:07 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002916000000
2023.09.11 17:07:07 4: SIGNALduino Dispatch: W115#22C000B43F00000000002916000000, -93 dB, dispatch
2023.09.11 17:07:07 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002916000000
2023.09.11 17:07:07 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.11 17:07:07 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:07 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=B393 not equal to 0x6DF1
2023.09.11 17:07:16 4: SIGNALduino/msg READ: ␂MN;D=3FC80131BBEA18AA8AA8AAAA9FFC9B3A99A98EF8A8EAAAAAAA000000;N=7;R=237;␃
2023.09.11 17:07:16 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:16 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=0416 crcRef=3FC8
2023.09.11 17:07:16 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:16 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B1140B2002002000035563190330324520240000000
2023.09.11 17:07:16 4: SIGNALduino Dispatch: W207#AB9B1140B2002002000035563190330324520240000000, -83.5 dB, dispatch
2023.09.11 17:07:16 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B1140B2002002000035563190330324520240000000
2023.09.11 17:07:16 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.11 17:07:16 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.11 17:07:20 4: SIGNALduino/msg READ: ␂MN;D=BA0B22C000B43F00000000002916000000EBFFFF0700000000000000;N=7;R=216;␃
2023.09.11 17:07:20 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:20 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002916000000
2023.09.11 17:07:20 4: SIGNALduino Dispatch: W115#22C000B43F00000000002916000000, -94 dB, dispatch
2023.09.11 17:07:20 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002916000000
2023.09.11 17:07:20 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.11 17:07:20 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:20 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=B393 not equal to 0x6DF1
2023.09.11 17:07:28 4: SIGNALduino/msg READ: ␂MN;D=9B870131B8CA18AADAADAAAA9FFC9B3A98A9892DA88AAAAAAA000000;N=7;R=233;␃
2023.09.11 17:07:28 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:28 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=F1AB crcRef=9B87
2023.09.11 17:07:28 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:28 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B1260B2007007000035563190320323870220000000
2023.09.11 17:07:28 4: SIGNALduino Dispatch: W207#AB9B1260B2007007000035563190320323870220000000, -85.5 dB, dispatch
2023.09.11 17:07:28 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B1260B2007007000035563190320323870220000000
2023.09.11 17:07:28 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.11 17:07:28 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.11 17:07:33 4: SIGNALduino/msg READ: ␂MN;D=BA0B22C000B43F00000000002916000000EBFFFFC1C0000000000000;N=7;R=217;␃
2023.09.11 17:07:33 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:33 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002916000000
2023.09.11 17:07:33 4: SIGNALduino Dispatch: W115#22C000B43F00000000002916000000, -93.5 dB, dispatch
2023.09.11 17:07:33 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002916000000
2023.09.11 17:07:33 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.11 17:07:33 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:33 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=0159 not equal to 0x6DF1
2023.09.11 17:07:41 4: SIGNALduino/msg READ: ␂MN;D=FD610131A3EA18AAEAAEAAAA9FFC98AA98A988CEA8BAAAAAAA000000;N=7;R=232;␃
2023.09.11 17:07:41 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:41 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=308C crcRef=FD61
2023.09.11 17:07:41 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:41 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B0940B2004004000035563200320322640210000000
2023.09.11 17:07:41 4: SIGNALduino Dispatch: W207#AB9B0940B2004004000035563200320322640210000000, -86 dB, dispatch
2023.09.11 17:07:41 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B0940B2004004000035563200320322640210000000
2023.09.11 17:07:41 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.11 17:07:41 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.11 17:07:46 4: SIGNALduino/msg READ: ␂MN;D=BA0B22C000B43F00000000002916000000EBFFFFC1C0000000000000;N=7;R=227;␃
2023.09.11 17:07:46 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:46 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002916000000
2023.09.11 17:07:46 4: SIGNALduino Dispatch: W115#22C000B43F00000000002916000000, -88.5 dB, dispatch
2023.09.11 17:07:46 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002916000000
2023.09.11 17:07:46 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.11 17:07:46 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:46 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=0159 not equal to 0x6DF1
2023.09.11 17:07:53 4: SIGNALduino/msg READ: ␂MN;D=00F30131A3CA18AAAAAAAAAA9FFC98AA99A98B33A8FAAAAAAA000000;N=7;R=238;␃
2023.09.11 17:07:53 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:53 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=1EB9 crcRef=00F3
2023.09.11 17:07:53 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:53 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B0960B2000000000035563200330321990250000000
2023.09.11 17:07:53 4: SIGNALduino Dispatch: W207#AB9B0960B2000000000035563200330321990250000000, -83 dB, dispatch
2023.09.11 17:07:53 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B0960B2000000000035563200330321990250000000
2023.09.11 17:07:53 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.11 17:07:53 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.11 17:07:59 4: SIGNALduino/msg READ: ␂MN;D=BA0B22C000B43F00000000002916000000EBFFFF0700000000000000;N=7;R=223;␃
2023.09.11 17:07:59 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.11 17:07:59 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002916000000
2023.09.11 17:07:59 4: SIGNALduino Dispatch: W115#22C000B43F00000000002916000000, -90.5 dB, dispatch
2023.09.11 17:07:59 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002916000000
2023.09.11 17:07:59 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.11 17:07:59 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.11 17:07:59 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=B393 not equal to 0x6DF1
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 11 September 2023, 18:14:38
Danke, es gibt demnächst eine neue Version vom 14_SD_WS Modul,
Das reading type ist dann "Bresser_6in1_u_7in1 Pool Thermometer"
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralli am 12 September 2023, 20:59:49
Mir ist aufgefallen, dass die Wetterstation mir die aktuelle Niederschlagsmenge ("Rate") anzeigt, in den Readings des Sensors wird aber nur die Gesamtmenge angezeigt und hochgezählt.

Ist die aktuelle Rate auch zu dekodieren aus den Meldungen?

2023.09.12 21:00:22 4: SIGNALduino/msg READ: ␂MN;D=A9F7013188AA18A9DA9CAAAAD9CCB2CA3BAAAAAAAAAAAAAAAA000000;N=7;R=240;␃
2023.09.12 21:00:22 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.12 21:00:22 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=B74C crcRef=A9F7
2023.09.12 21:00:22 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.12 21:00:22 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B2200B2037036000073661860910000000000000000
2023.09.12 21:00:22 4: SIGNALduino Dispatch: W207#AB9B2200B2037036000073661860910000000000000000, -82 dB, dispatch
2023.09.12 21:00:22 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B2200B2037036000073661860910000000000000000
2023.09.12 21:00:22 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.12 21:00:22 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.12 21:00:24 4: SIGNALduino/msg READ: ␂MN;D=A89B22C000B43F000000000027960000006DFFFFC1C0000000000000;N=7;R=209;␃
2023.09.12 21:00:24 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.12 21:00:24 4: SIGNALduino ParseMN: ID=115 dmsg=W115#22C000B43F00000000002796000000
2023.09.12 21:00:24 4: SIGNALduino Dispatch: W115#22C000B43F00000000002796000000, -97.5 dB, dispatch
2023.09.12 21:00:24 4: SIGNALduino: SD_WS_Parse protocol 115, rawData 22C000B43F00000000002796000000
2023.09.12 21:00:24 4: SIGNALduino: SD_WS_Parse decoded protocol-id 115 (Bresser_6in1_u_7in1 other), sensor-id 22C000B4
2023.09.12 21:00:24 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.12 21:00:24 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=8029 not equal to 0x6DF1
2023.09.12 21:00:34 4: SIGNALduino/msg READ: ␂MN;D=BA6401318EAA18AC2ACBAAAAD9CCB2CA3BAAAAAAAAAAAAAAAA000000;N=7;R=236;␃
2023.09.12 21:00:34 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.12 21:00:34 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=E242 crcRef=BA64
2023.09.12 21:00:34 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.12 21:00:34 4: SIGNALduino ParseMN: ID=207 dmsg=W207#AB9B2400B2068061000073661860910000000000000000
2023.09.12 21:00:34 4: SIGNALduino Dispatch: W207#AB9B2400B2068061000073661860910000000000000000, -84 dB, dispatch
2023.09.12 21:00:34 4: SIGNALduino: SD_WS_Parse protocol 207, rawData AB9B2400B2068061000073661860910000000000000000
2023.09.12 21:00:34 4: SIGNALduino: SD_WS_Parse decoded protocol-id 207 (Bresser_7in1), sensor-id AB9B
2023.09.12 21:00:34 4: SIGNALduino: using longid for 0 device SD_WS_207_AB9B
2023.09.12 21:00:37 4: SIGNALduino/msg READ: ␂MN;D=A89B22C0000000000000000000000000000000000000000000000000;N=7;R=207;␃
2023.09.12 21:00:37 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 115 length 56 -> Bresser comfort 6in1 (5in1 neu)
2023.09.12 21:00:37 4: SIGNALduino ParseMN: method error! Bresser 5in1_neu: crc Error crc=AC0C crcRef=A89B
2023.09.12 21:00:37 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2023.09.12 21:00:37 4: SIGNALduino ParseMN: method error! Bresser 7in1 crc Error: crcXORref=F3ED not equal to 0x6DF1
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 13 September 2023, 19:26:56
Das rain vom Sensor ist ein fortlaufender Zähler mit einem Überlauf bei 99999.9
Wenn die Wetterstation einen Tageszähler hat, dann wird dieser in der Wetterstation ermittelt.
Dafür gibts in fhem das statistics Modul.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: elektron-bbs am 24 September 2023, 14:01:46
Welchen Prozessor du verwendest ist eigentlich egal. Die Firmwarestände werden beim Original für alle Prozessoren gleich aktualisiert (siehe https://github.com/RFD-FHEM/SIGNALDuino/releases).

Beim Arduino Nano bist du halt beim Anschluss eingeschränkt auf den USB, während sich ESP8266 und ESP32 flexibler per WLAN einbinden lassen. Die Empfangseigenschaften sind eigentlich identisch. Ich konnte bisher keine Beeinflussung durch das WLAN feststellen.

Ich habe mal einige Anschlussbelegungen zusammen gestellt:

Arduino Nano  -> CC1101
-----------------------
VCC 3,3 V     -> VDD
PIN D13 -> LS -> SCK
PIN D12       -> SO (MISO)
PIN D11 -> LS -> SI (MOSI)
PIN D10 -> LS -> CSN (SS)
PIN D03 -> LS -> GDO0
PIN D02       -> GDO2
PIN GND       -> GND
(LS = Levelshifter 5V->3V, oder Spannungsteiler)

ESP8266 -> CC1101
-----------------
3V3     -> VCC
GPIO15  -> CSN
GPIO14  -> SCK
GPIO13  -> SI (MOSI)
GPIO12  -> SO (MISO)
GPIO5   -> GDO2
GPIO4   -> GDO0
GND     -> GND

SIGNALDuino bis Release 3.4.0
=============================
ESP32  -> CC1101
----------------
3V     -> VCC
GPIO23 -> SI (MOSI)
GPIO19 -> SO (MISO)
GPIO18 -> SCK
GPIO16 -> GDO2
GPIO5  -> CSN
GPIO4  -> GDO0
GND    -> GND

SIGNALDuino ab Release 3.5.0-dev
================================
ESP32  -> CC1101
----------------
3V     -> VCC
GPIO23 -> SI (MOSI)
GPIO19 -> SO (MISO)
GPIO18 -> SCK
GPIO13 -> GDO2 (old 16, not good (serial) and not all boards)
GPIO5  -> CSN
GPIO4  -> GDO0
GND    -> GND
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Rainer1 am 07 Januar 2024, 17:25:10
Ich habe einen 2ten SIGNALduino installiert mit 868MHz. Welchen RF-Mode muss ich einstellen, um wm-bus-Daten des Wasserzählers zu empfangen ? Es handelt sich um Qualcosonic W1
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Januar 2024, 17:42:17
Was für eine SIGNALDuino Hardware verwendest Du?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Rainer1 am 07 Januar 2024, 17:51:43
Ich habe einen 2ten nanoCUL mit CC1101 (868) aufgebaut
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 07 Januar 2024, 18:10:15
Mit dem nanoCUL funktioniert WMBUS nur mit der culw firmware
siehe hier
https://forum.fhem.de/index.php?topic=24517.msg915481#msg915481
Es ist vermutlich der rfmode WMBus_T

Bei weiteren Fragen bitte dort (CUL -> Hard- und Firmware -> Wireless M-Bus für CUL) posten


Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: kask am 07 März 2024, 20:02:48
Hallo,
ich habe das Problem das mein log voll "gemüllt" wird mit folgender Meldung:
2024.03.06 21:34:35.791 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:36:36.988 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:38:40.360 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:40:42.621 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:42:41.859 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:44:41.914 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:46:42.818 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:48:45.950 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:50:46.037 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:52:46.762 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:54:46.936 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:56:48.209 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 21:58:48.683 0: SignalDuino433cc1101: Parse, noMsg: OK
2024.03.06 22:00:51.314 0: SignalDuino433cc1101: Parse, noMsg: OK

Kann mir einer sagen wie ich das unterbinden kann? Ich finde dazu nichts brauchbares.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 März 2024, 20:11:56
Zitat von: kask am 07 März 2024, 20:02:48Kann mir einer sagen wie ich das unterbinden kann? Ich finde dazu nichts brauchbares.


Schick doch bitte mal ein List von deiner Definition und erzähle uns doch noch welches Log das ist.

Grüße Sidey
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: kask am 07 März 2024, 20:45:46
OK, das ist kein  Problem.

standard fhem logfile: fhem-2024-03.log

define SignalDuino433cc1101 SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
attr SignalDuino433cc1101 DbLogExclude .*
attr SignalDuino433cc1101 eventlogging 0
attr SignalDuino433cc1101 hardware nanoCC1101
attr SignalDuino433cc1101 icon cul_usb
attr SignalDuino433cc1101 noMsgVerbose 0
attr SignalDuino433cc1101 rfmode SlowRF
attr SignalDuino433cc1101 room GATEWAYS
attr SignalDuino433cc1101 updateChannelFW stable
attr SignalDuino433cc1101 verbose 0
#   Clients    :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya: :FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT: :KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt: :SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL: :SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick: :SOMFY: :Siro:SIGNALduino_un
#   ClientsKeepOrder 1
#   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
#   DMSG       W84#A702330AEE
#   DevState   initialized
#   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
#   FD         15
#   FUUID      627f5f2f-f33f-3c15-fbf8-854f64ab5883cbb7
#   IDsNoDispatch 2,72.1,82
#   LASTDMSG   W84#A702330AEE
#   LASTDMSGID 84
#   MSGCNT     13806
#   NAME       SignalDuino433cc1101
#   NR         276
#   PARTIAL   
#   RAWMSG     MU;P0=-277;P1=456;P2=234;P3=-503;P4=705;P5=-763;D=01010231010101323454545451023102323101010232323232323102323231010232310102323232310231023101010231010101;CP=2;R=211;
#   RSSI       -96.5
#   STATE      opened
#   TIME       1709840767.14507
#   TYPE       SIGNALduino
#   cc1101_available 1
#   eventCount 689
#   sendworking 0
#   unknownmessages
#   version    V 3.5.0-dev+20210808 SIGNALduino cc1101 (chip CC1101) - compiled at Aug  7 2021 22:44:01
#   versionProtocols 1.56
#   versionmodul 3.5.6+20231214
#   DoubleMsgIDs:
#   MatchList:
#     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
#     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
#     12:SD_WS   ^W\d+x{0,1}#.*
#     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
#     14:Dooya   ^P16#[A-Fa-f0-9]+
#     15:SOMFY   ^Ys[0-9A-F]+
#     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
#     17:SD_UT   ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121|127|128|130|132)#.*
#     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
#     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
#     1:IT       ^i......
#     20:Revolt  ^r[A-Fa-f0-9]{22}
#     21:FS10    ^P61#[A-F0-9]+
#     22:Siro    ^P72#[A-Fa-f0-9]+
#     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
#     24:FS20    ^81..(04|0c)..0101a001
#     25:CUL_EM  ^E0.................
#     26:Fernotron ^P82#.*
#     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
#     28:SD_Keeloq ^P(?:87|88)#.*
#     29:SD_GT   ^P49#[A-Fa-f0-9]+
#     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
#     30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
#     31:KOPP_FC ^kr\w{18,}
#     32:PCA301  ^\S+\s+24
#     33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
#     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
#     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
#     5:CUL_TX   ^TX..........
#     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
#     7:Hideki   ^P12#75[A-F0-9]+
#     9:CUL_FHTTK ^T[A-F0-9]{8}
#     X:SIGNALduino_un ^[u]\d+#.*
#   QUEUE:
#   READINGS:
#     2024-03-07 19:53:11   cc1101_config   Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5.60 kBaud
#     2024-03-07 19:53:11   cc1101_config_ext Modulation: ASK/OOK
#     2024-03-07 19:53:13   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
#     2022-05-14 10:11:43   freeram         990
#     2024-03-07 20:46:35   ping            OK
#     2024-03-07 19:53:10   state           opened
#   additionalSets:
#     flash      3.5.0,3.4.0,3.3.1
#   keepalive:
#     ok         1
#     retry      0
#   mcIdList:
#     10
#     11
#     12
#     18
#     43
#     47
#     52
#     57
#     58
#     96
#     119
#     129
#   mnIdList:
#     100
#     101
#     102
#     103
#     107
#     107.1
#     108
#     109
#     112
#     115
#     116
#     116.1
#     117
#     123
#     125
#     126
#     131
#   msIdList:
#     0
#     0.1
#     0.2
#     0.3
#     0.4
#     0.5
#     1
#     3
#     3.1
#     4
#     6
#     7
#     7.1
#     13
#     13.2
#     14
#     15
#     17
#     20
#     23
#     25
#     33
#     33.1
#     33.2
#     35
#     41
#     49
#     51
#     53
#     54.1
#     55
#     65
#     68
#     74.1
#     87
#     88
#     90
#     91.1
#     93
#     106
#     113
#     118.1
#     127.1
#     128.1
#     130
#   muIdList:
#     8
#     9
#     13.1
#     16
#     17.1
#     19
#     20.1
#     21
#     22
#     24
#     26
#     27
#     28
#     29
#     30
#     31
#     32
#     34
#     36
#     37
#     38
#     39
#     40
#     42
#     44
#     44.1
#     45
#     46
#     48
#     49.1
#     49.2
#     50
#     54
#     56
#     59
#     60
#     61
#     62
#     64
#     66
#     67
#     69
#     70
#     71
#     72
#     73
#     74
#     76
#     78
#     79
#     80
#     81
#     83
#     84
#     85
#     86
#     89
#     91
#     92
#     94
#     95
#     97
#     98
#     99
#     104
#     105
#     110
#     111
#     114
#     118
#     120
#     121
#     122
#     127
#     128
#     132
#
setstate SignalDuino433cc1101 opened
setstate SignalDuino433cc1101 2024-03-07 19:53:11 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5.60 kBaud
setstate SignalDuino433cc1101 2024-03-07 19:53:11 cc1101_config_ext Modulation: ASK/OOK
setstate SignalDuino433cc1101 2024-03-07 19:53:13 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
setstate SignalDuino433cc1101 2022-05-14 10:11:43 freeram 990
setstate SignalDuino433cc1101 2024-03-07 20:46:35 ping OK
setstate SignalDuino433cc1101 2024-03-07 19:53:10 state opened

Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 März 2024, 21:01:04
Zitat von: kask am 07 März 2024, 20:45:46OK, das ist kein  Problem.


Entferne das Attribut 'noMsgVerbose' oder setze es auf einen Wert höher als das Attribut 'verbose', dann werden die Meldungen nicht mehr geloggt.

Viele Grüße
Sidey
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: kask am 07 März 2024, 21:06:25
Ok teste ich. Danke soweit erst einmal.
Auch wenn ich den Sinn nicht verstehe wenn doch 'noMsgVerbose' und 'verbose' auf 0 sind.
Sollten doch eigenlich überhaupt keine Meldungen mehr ins log kommen.
Was ist der Hintergrund?
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: kask am 07 März 2024, 21:15:50
Meldungen sind weg. danke!

Ich habe aber noch eine Anmerkung. Und zwar steht in der attr-hilfe beim setzen/ändern des noMsgVerbose Attributes

ZitatnoMsgVerbose
With this attribute you can control the logging of debug messages from the io device. If set to 3, this messages are logged if global verbose is set to 3 or higher.

Mein global verbose steht aber auf 2.
Und das device verbose, wie oben gepostet, auf 0.

Ich habe jetzt den noMsgVerbose auf 1 gesetzt und die Meldungen sind weg.

sollte es da nicht eher so heißen?
ZitatnoMsgVerbose
With this attribute you can control the logging of debug messages from the io device. If set to 3, this messages are logged if globaldevice verbose is set to 3 or higher.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 07 März 2024, 21:18:38
Zitat von: kask am 07 März 2024, 21:06:25Auch wenn ich den Sinn nicht verstehe wenn doch 'noMsgVerbose' und 'verbose' auf 0 sind.
Sollten doch eigenlich überhaupt keine Meldungen mehr ins log kommen.
Was ist der Hintergrund?


noMsgVerbose
Mit diesem Attribut können Sie die Protokollierung von Debug-Nachrichten vom io-Gerät steuern. Wenn dieser Wert auf 3 festgelegt ist, werden diese Nachrichten protokolliert, wenn der globale Verbose auf 3 oder höher eingestellt ist.



Letztendlich hast Du damit eingestellt, dass die Debug Meldungen mit Verbose level 0 gesendet werden.
Dadurch werden diese immer protokolliert.


OK Verwirrung verstanden wegen dem Begriff global.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zernima am 13 März 2024, 21:05:22
Hallo,
ich habe eine Markise vom Hornbach gekauft. Verbaut ist ein Dooya Motor...Den hab ich auch ohne Probleme mit meinen Signalduiono 433 einbinden können.

Nun hat die Markise auch Licht welches über den Motor bzw die Fernbedienung gesteuert wird.
Das Signal wird auch erkannt. Nur schaff ich es nicht das Licht an oder aus zu machen.

Was muss ich genau senden um das Signal der Fernbedienung zu emulieren?

Hier das was ich mitscheniden konnte:

2024.03.12 21:55:10 4: sduino: Read, msg READredu: MU;P0=-7850;P1=-1479;P2=31976;P3=5077;P4=743;P5=-346;P6=364;P7=-722;D=12121212121212121212121212121212121213145676767454545456767674567456745454567674545454567676767674567456767676745454540314567676745454545676767456745674545456767454545456767676767456745676767674545454031456767674545454567676745674567454545676745454545676;CP=6;R=62;O;
2024.03.12 21:55:10 4: sduino: Parse_MU, Fingerprint for MU protocol id 16 -> Dooya matches, trying to demodulate
2024.03.12 21:55:10 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(1/4) RSSI = -43
2024.03.12 21:55:10 4: Dooya_Parse: rawData = 8F15CF050E length: 10
2024.03.12 21:55:10 4: Dooya_Parse: converted to bits: 1000111100010101110011110000010100001110
2024.03.12 21:55:10 4: Dooya_Parse: device ID: 1000111100010101110011110000
2024.03.12 21:55:10 4: Dooya_Parse: Channel: 5
2024.03.12 21:55:10 4: Dooya_Parse: Cmd: 0000  Newstate:
2024.03.12 21:55:10 4: Dooya_Parse: deviceCode: 1000111100010101110011110000_5
2024.03.12 21:55:10 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(2/4) RSSI = -43
2024.03.12 21:55:10 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:10 4: sduino: Read, msg READredu: MU;P0=-744;P1=344;P2=717;P3=-367;P4=-7852;P5=4844;P6=-1504;D=01010102310231010101023232324562310101023232323101010231023102323231010232323231010101010231023101010102323232;CP=1;R=60;
2024.03.12 21:55:10 4: sduino: Parse_MU, Fingerprint for MU protocol id 16 -> Dooya matches, trying to demodulate
2024.03.12 21:55:10 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(1/4) RSSI = -44
2024.03.12 21:55:10 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:11 4: sduino: Read, msg READredu: MU;P0=21432;P1=-1344;P2=31938;P3=7028;D=01212121212121212121212121212121212121212121212121212121212121212121212121212121212121213;CP=2;R=216;
2024.03.12 21:55:12 4: sduino: Read, msg READredu: MU;P0=4846;P1=-1490;P2=32001;P3=705;P4=-369;P5=355;P6=-736;P7=-7844;D=12134565656343434345656563456345634343456563434343456565656563456345656565634343437013456565634343434565656345634563434345656343434345656565656345634565656563434343701345656563434343456565634563456343434565634343434565656565634563456565656343434370134565;CP=5;R=61;O;
2024.03.12 21:55:12 4: sduino: Parse_MU, Fingerprint for MU protocol id 16 -> Dooya matches, trying to demodulate
2024.03.12 21:55:12 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(1/4) RSSI = -43.5
2024.03.12 21:55:12 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:12 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(2/4) RSSI = -43.5
2024.03.12 21:55:12 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:12 4: sduino: Read, msg READredu: MU;P0=-723;P1=364;P2=729;P3=-350;D=01023232323101010231023102323231010232323231010101010231023101010102323232;CP=1;R=59;
2024.03.12 21:55:13 4: sduino: Read, msg READredu: MU;P0=31953;P1=-1342;P2=7016;D=01010101010101010101010101010101010101010101010101010101010101012;CP=0;R=215;
2024.03.12 21:55:16 4: sduino: KeepAlive, ok, retry = 0
2024.03.12 21:55:16 4: sduino: Read, msg READredu: MU;P0=2636;P1=-1293;P2=31980;P3=736;P4=-136;P5=116;D=012121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121345;CP=2;R=217;
2024.03.12 21:55:39 4: sduino: Read, msg READredu: MU;P0=4767;P1=-1489;P2=726;P3=-364;P4=361;P5=-720;P6=-7845;D=01234545452323232345454523452345232323454523232323454545454523452345454545232323260123454545232323234545452345234523232345452323232345454545452345234545454523232326012345454523232323454545234523452323234545232323234545454545234523454545452323232601234545;CP=4;R=61;O;
2024.03.12 21:55:39 4: sduino: Parse_MU, Fingerprint for MU protocol id 16 -> Dooya matches, trying to demodulate
2024.03.12 21:55:39 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(1/4) RSSI = -43.5
2024.03.12 21:55:39 4: Dooya_Parse: rawData = 8F15CF050E length: 10
2024.03.12 21:55:39 4: Dooya_Parse: converted to bits: 1000111100010101110011110000010100001110
2024.03.12 21:55:39 4: Dooya_Parse: device ID: 1000111100010101110011110000
2024.03.12 21:55:39 4: Dooya_Parse: Channel: 5
2024.03.12 21:55:39 4: Dooya_Parse: Cmd: 0000  Newstate:
2024.03.12 21:55:39 4: Dooya_Parse: deviceCode: 1000111100010101110011110000_5
2024.03.12 21:55:39 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(2/4) RSSI = -43.5
2024.03.12 21:55:39 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:39 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(3/4) RSSI = -43.5
2024.03.12 21:55:39 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:39 4: sduino: Read, msg READredu: MU;P0=366;P1=-720;P2=734;P3=-344;D=0123232323010101230123012323230101232323230101010101230123010101012323232;CP=0;R=58;
2024.03.12 21:55:46 4: sduino: Read, msg READredu: MU;P0=-716;P1=4777;P2=-1494;P3=733;P4=-361;P5=371;P7=-7850;D=01234505050343434345050503450345034343450503434343450505050503450345050505034343437123450505034343434505050345034503434345050343434345050505050345034505050503434343712345050503434343450505034503450343434505034343434505050505034503450505050343434371234505;CP=5;R=49;O;
2024.03.12 21:55:46 4: sduino: Parse_MU, Fingerprint for MU protocol id 16 -> Dooya matches, trying to demodulate
2024.03.12 21:55:46 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(1/4) RSSI = -49.5
2024.03.12 21:55:46 4: Dooya_Parse: rawData = 8F15CF050E length: 10
2024.03.12 21:55:46 4: Dooya_Parse: converted to bits: 1000111100010101110011110000010100001110
2024.03.12 21:55:46 4: Dooya_Parse: device ID: 1000111100010101110011110000
2024.03.12 21:55:46 4: Dooya_Parse: Channel: 5
2024.03.12 21:55:46 4: Dooya_Parse: Cmd: 0000  Newstate:
2024.03.12 21:55:46 4: Dooya_Parse: deviceCode: 1000111100010101110011110000_5
2024.03.12 21:55:46 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(2/4) RSSI = -49.5
2024.03.12 21:55:46 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:46 4: sduino: Parse_MU, Decoded matched MU protocol id 16 dmsg P16#8F15CF050E length 40 dispatch(3/4) RSSI = -49.5
2024.03.12 21:55:46 4: sduino: Dispatch, P16#8F15CF050E, Dropped due to short time or equal msg
2024.03.12 21:55:46 4: sduino: Read, msg READredu: MU;P0=-741;P1=348;P2=722;P3=-366;D=01023232323101010231023102323231010232323231010101010231023101010102323232;CP=1;R=48;
2024.03.12 21:56:16 4: sduino: KeepAlive, ok, retry = 0
2024.03.12 21:56:19 4: sduino: Read, msg READredu: MU;P0=15990;P1=-1297;P2=31983;D=0121212121212121212121212121212121212121212121210;CP=2;R=216;
2024.03.12 21:56:25 4: sduino: Read, msg READredu: MU;P0=31998;P1=-1278;P2=1176;D=01010101010101010101010101010101010101010101010101010101012;CP=0;R=216;
2024.03.12 21:57:16 4: sduino: KeepAlive, ok, retry = 0
2024.03.12 21:58:16 4: sduino: KeepAlive, not ok, retry = 1 -> get ping
2024.03.12 21:58:16 4: sduino: HandleWriteQueue, called
2024.03.12 21:58:16 4: sduino: SendFromQueue, called
2024.03.12 21:58:16 4: sduino: Read, msg: OK
2024.03.12 21:58:16 4: sduino: HandleWriteQueue, called
2024.03.12 21:58:16 4: sduino: HandleWriteQueue, nothing to send, stopping timer

Irgendwie steh ich auf dem Schlauch.... ::)

Danke schon mal :)
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 März 2024, 22:26:33
Da Du mehrmals  P16#8F15CF050E emfpangen hat, würde ich es damit versuchen.
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zernima am 13 März 2024, 22:41:20
Danke fü die schnelle Antwort :)

Wie muss ich das genau senden..?

sooo..?
set sduino raw SR;;R=3;;P0=500;;D=P16#8F15CF050E;; 


Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Sidey am 13 März 2024, 22:56:34
Zitat von: zernima am 13 März 2024, 22:41:20sooo..?
set sduino raw SR;;R=3;;P0=500;;D=;; 



Nein, für den raw Befehl müsstest Du es erst in ein Signal wandeln, ich würde es mal so versuchen:


set sduino sendMsg P16#0x8F15CF050E#R4

Details zum SendMSG Befehl findest Du unter anderem in der commandref:

sendMsg
Dieser Befehl erstellt die erforderlichen Anweisungen zum Senden von Rohdaten über den SIGNALduino. Sie können die Signaldaten wie Protokoll und die Bits angeben, die Sie senden möchten.
Alternativ ist es auch moeglich, die zu sendenden Daten in hexadezimaler Form zu uebergeben. Dazu muss ein 0x vor den Datenteil geschrieben werden.

Bitte beachte, dieses Kommando funktioniert nur fuer MU oder MS Protokolle nach dieser Vorgehensweise:

Argumente sind:
P#binarydata#R#C (#C is optional)
Beispiel binarydata: set sduino sendMsg P0#0101#R3#C500
Dieser Befehl erzeugt ein Sendekommando fuer die Bitfolge 0101 anhand der protocol id 0. Als Takt wird 500 verwendet.
SR;R=3;P0=500;P1=-9000;P2=-4000;P3=-2000;D=03020302;

P#0xhexdata#R#C (#C is optional)
Beispiel 0xhexdata: set sduino sendMsg P29#0xF7E#R4
Dieser Befehl erzeugt ein Sendekommando fuer die Hexfolge F7E anhand der protocol id 29. Die Nachricht soll 4x gesendet werden.
SR;R=4;P0=-8360;P1=220;P2=-440;P3=-220;P4=440;D=01212121213421212121212134;

P#0xhexdata#R#C#F (#C #F is optional)
Beispiel 0xhexdata: set sduino sendMsg P36#0xF7#R6#Fxxxxxxxxxx (xxxxxxxxxx = Registerwert des CC1101)
Dieser Befehl erzeugt ein Sendekommando fuer die Hexfolge F7 anhand der protocol id 36. Die Nachricht soll 6x gesendet werden mit der angegebenen Frequenz.
SR;R=6;P0=-8360;P1=220;P2=-440;P3=-220;P4=440;D=012323232324232323;F= (Registerwert des CC1101);


Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zernima am 13 März 2024, 23:15:06
Super ..Vielen Dank...Ich habs mehrfach gelesen. Aber leider nicht so verstanden... O:-)

Ich habs jetzt mal getestet. Auf Anhieb hat es jetzt mal nicht funktioniert :-\
Titel: Aw: SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: zernima am 14 März 2024, 07:37:20
Aaaalso...

Ich hab das gestern mal noch getestet....Leider ging es nicht.
Was sehr sehr komisch war. Wenn ich das Signal für aus- oder einfahren in genau der gleichen Form...
Zitatset sduino sendMsg P16#8F15CF0554E#R4

Dann fährt die Markise.
Nur das Licht geht leider nicht an...

Was kann ich jetzt noch machen? :)