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:
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:
CED -> Debugausgaben ein
CDD -> Debugausgaben aus
CDL -> Message-LED aus
CEL -> Message-LED ein
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

https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
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
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
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
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
Zitat
Wie 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)
Zitat
Bei 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
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
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
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 :)


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
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
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
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

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.

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: Michl1003! 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?

Zitat
When 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
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
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
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
Zitat
A 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
Zitat
When 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


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
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
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
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
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.

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
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#).

Zitat
Hier 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)?

Zitat
Quarter-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
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
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
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.


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.

<edit>  *__brkval; ist extern void, nicht int.</edit>

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

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:
Zitat
Using 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

Zitat
x<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
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?


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.

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.

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.

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
Zitat
Ich 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
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:
Zitat
C:\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
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 ...
Zitat
Sketch 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:

Zitat
Sketch 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.
Zitat
SIGNALDuino-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
Zitat
SIGNALDuino-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.

Zitat
Benutzt 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 0Ich 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: Michl1003! 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
Zitat
Wie 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: Michl1003! 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.txtausfü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: Michl1003! 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: Michl1003! 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: Michl1003! 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

Zitat
define 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":
Zitat
V 3.3.1-dev SIGNALduino cc1101 - compiled ...


Gruß Ralf


Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Michl1003! 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
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
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
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: Michl1003! 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
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:
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: Michl1003! 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
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
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
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
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:
Zitat
MuP0C9P1D34P2ABCP31F9D<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);


Zitat
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.

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
Zitat
Das 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.
Zitat
One 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
Zitat
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)

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
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
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.  :'( )

Zitat
Starting 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
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
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.


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 eeinen 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 ehat 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
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
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
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
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
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
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
Zitat
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.

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,

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
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
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
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
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
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
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
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
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
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
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
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-idauf 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,
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.

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

Zitat
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.
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.

Zitat
Wenn 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
Zitat
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.

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
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
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
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

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
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
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
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
@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
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,

Zitat
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.
getan

Zitat
Board 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
...
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
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
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
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
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:
Zitat
Using 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
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.


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
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,
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
Zitat
CCInit
CCVersion=0
CCPartnum=0
no CC11xx found!

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
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
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
@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
@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
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)
Zitat
Das 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,

@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
@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,

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!

Zitat
Using 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
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!

Zitat
Using sFIFO
Init eeprom to defaults after flash
ccFactoryReset done
CCInit
CCVersion=0
CCPartnum=0
no CC11xx found!

Zitat
Hast 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

Zitat
Also, 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.

Zitat
Den 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
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,  ;)

@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,

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.

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

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

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

Viele Grüße,
Ingo
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,

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,

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
Zitat
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

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

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

War es gewollt, das neben dem RSSI auch die Meldungen DMSG + RAWMSG auch im Log des jeweiligen Sensor erscheinen?
Ich kenne es, das neben den normalen Werten, nichts anderes mitgeloggt wurde. (BSP: T: H: RSSI )
Wenn ja, könnte man das ganze etwas einschränken, in etwa so
Zitat
2017-02-27_18:35:58 Hideki_30_5 T: 21 H: 47
2017-02-27_18:35:58 Hideki_30_5 temperature: 21
2017-02-27_18:35:58 Hideki_30_5 RSSI: -110.25
2017-02-27_18:35:58 Hideki_30_5 DMSG: P12#75B7BACAF0BE3D55E15701
2017-02-27_18:35:58 Hideki_30_5 RAWMSG: MC;LL=-1006;LH=945;SL=-514;SH=466;D=A8C4B45ACF860A8755BC454;C=488;L=90;R=3;
???

Grund zum Test, Funktion addvaltrigger 1 testen.

MfG

EDIT: Sobald ich das Backup zurück schiebe geht wieder "alles". Es muss also Unterschiede geben welche beim Update ggf. noch fehlerbehaftet sind.
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: Ralf9 am 27 Februar 2017, 20:53:37
Zitat
danach FHEM neu gestartet. Es tat sich wieder das Phänomen auf, das die Empfänger als "offen = open" angezeigt werden und erst nach einem get ccconf des jeweiligen Empfänger erst wieder Signale empfangen.
Das Ganze lässt sich reproduzieren, sobald ich nun FHEM neu starte, bin ich gezwungen das erneut zu machen.
Ich kann dies bei mir nicht nachvollziehen, wenn ich fhem neu starte, funktioniert der Empfang automatsch wieder.

Zitat
War es gewollt, das neben dem RSSI auch die Meldungen DMSG + RAWMSG auch im Log des jeweiligen Sensor erscheinen?
Beim Attribut "addvaltrigger" besteht kein Einfluss bei welchen zusätzlichen Werten events erzeugt werden. Es wird von allen Werten, die beim dispatch ans jeweilige Modul übergeben werden events erzeugt.

Gruß Ralf 
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: HomeAuto_User am 03 März 2017, 12:38:01
Hallo und danke Ralf,

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

Gruß Ralf

das Problem RasPi, keine Initialisierung bzw. PING habe ich einen neuen Faden "geschoben". Hier (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
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
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
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
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
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
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
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 -> weatherID7Das 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:
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
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
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
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
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
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
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
Zitat
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.

Zitat
ich 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
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 
Zitat
Well, 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
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
Zitat
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.

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
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
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
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.

Zitat
Was 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
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
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
Zitat
Kann 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
Zitat
aber 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
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
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
@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
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
@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
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
Zitat
Die 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
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, Herstellung oder gewerblichen 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
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
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.txtund 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
Zitat
kann 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.

Zitat
Wie 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-iddie USB Schnittstelle ermittelt und dann mit:
define sduino SIGNALduino dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600das 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
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
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
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
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.binoder mit NodeMCU Flasher (https://github.com/nodemcu/nodemcu-flasher) geflasht.

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
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
Zitat
Habe 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
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
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
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
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
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
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
Soweit 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
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
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
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
Lä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
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
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
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
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
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
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
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
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.


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
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
@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
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
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
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
... 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
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
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
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
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
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
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:

Zitat
cc1101 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
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
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


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
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
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
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
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_flashlöscht den kompletten Flash, sowohl die Firmware als auch die Settings.

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
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
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
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
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:
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
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
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
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
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
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
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.txthabe 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
Zitat
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.
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
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


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:
0101011001010000010111111000100Damit 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
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
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
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
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:
Zitat
Arduino 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
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
sduino (Arduino+RBX6) sendet und signalESP (ESP8266+locutus cc1101 shield) empfängt

Den Fehler habe ich behoben und RC2 bereitgestellt.

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.

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
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
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
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
Zitat
syntax 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
Zitat
Bei 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
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
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
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
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
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:

Zitat
SIGNALESP_331rc1.bin (mit cc1101)

Soll doch bestimmt so aussehen:

Zitat
SIGNALESP_331rc2.bin (mit cc1101)
Titel: Antw:SIGNALDuino Empfänger Firm- und Hardware
Beitrag von: pejonp am 14 Januar 2018, 12:07:40
..
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
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&