Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[hjgode]

Hallo

nur als Info:

Mit dem Update vom 20.2.2019 gehen zwei meiner SD_WS07 Sensoren schlagartig nicht mehr, ein dritter funktioniert weiter ohne Probleme. Bin daher wieder auf eine alte Version zurück.

Gruss

~Josef

[HomeAuto_User]

Hallo hjgode,
Danke für die Info. Aktuell wird daran gefixt. Wenn du vom Update 20.02. schreibst, meinst du damit die dev_r34 Version?
Mfg


Gesendet von iPhone mit Tapatalk Pro

[Ralf9]

Mit dem Update vom 20.2.2019 gehen zwei meiner SD_WS07 Sensoren schlagartig nicht mehr

Mich wundert, daß sich noch nicht mehr mit diesem Problem gemeldet haben, Du bist erst der dritte.
Der Fehler hat sich letztes Jahr durch einen Patch in das SD_WS07 Modul der dev-r33 eingeschlichen.
In der fehlerhaften Version steht in DEF und CODE der Kanal anstatt Model + Kanal (SD_WS07_TH_1)

siehe auch hier
https://forum.fhem.de/index.php/topic,97910.0.html

Demnach verwendest Du keine oder eine recht alte Entwicklerversion dev-r33 und hast nun ein fhem update gemacht.
Von dem Problem müssten eigentlich alle betroffen sein, die ein fhem update machen, SD_WS07 Sensoren haben und ein SD_WS07 Modul verwenden das den Fehler nicht enthält (In DEF ist SD_WS07_T enthalten, z.B. SD_WS07_TH_1).

Gruß Ralf

[hjgode]

Hallo Ralf

danke, die im gelinkten Thread gepostete Version funktioniert, die zwei fehlenden Sensoren sind auch damit wieder live.

Gruss

Josef

[Ralf9]

Hallo Sidey,

es wäre schön, wenn Du dies in die dev-r34 einbauen könntest
Neues Internal ID bei Devices:
https://github.com/RFD-FHEM/RFFHEM/issues/499

Es sollte eigentlich reichen, wenn die ID nur dann als addvals per dispatch übergeben wird, wenn in der dmsg keine # enthalten ist,
oder ist es besser, wenn die ID immer im Internal steht, also auch wenn die ID im DMSG vor der # steht?

Falls es noch nicht allgemein bekannt ist, bei der dmsg ist die Zahl vor der # die ID.

Damit ist dann bei einem neuen Device, bei dem die ID nicht bekannt ist, folgendes möglich.
Bei dem Beispiel gehe ich davon aus, daß die Entwicklerversion dev-r34 und die whitelist verwendet wird.

Damit alle IDs aktiv sind wird das Attribut development auf 1 gesetzt und die whitelist durch ein # am Anfang deaktiviert.

Nun wird geschaut ob, wenn der neue Sensor/Fernbedienung sendet, ein neues Device angelegt wird.
Nun steht die ID in dem neuen Device.
Das Attribut development kann nun wieder auf 0 gesetzt werden und die # aus der der whitelist entfernt werden.
Nun kann die ID z.B. mit "Display protocollist" zu der whitelist zugefügt werden.

Bei einem Auriol steht z.B. im neuen Device im Internal "sduino_ID 0.4"

Gruß Ralf

[Sidey]

Hallo Sidey,

es wäre schön, wenn Du dies in die dev-r34 einbauen könntest
Neues Internal ID bei Devices:
https://github.com/RFD-FHEM/RFFHEM/issues/499

Es sollte eigentlich reichen, wenn die ID nur dann als addvals per dispatch übergeben wird, wenn in der dmsg keine # enthalten ist,
oder ist es besser, wenn die ID immer im Internal steht, also auch wenn die ID im DMSG vor der # steht?

Hi Ralf,

ich habe bislang auf einen Patch oder ein PR von dir gewartet. Schreibst Du einen?
Dass ich das Internal immer einbauen würde, hatte ich ja bereits angemerkt. Dann ist es konsistent. Egal ob es jetzt in der dmsg steht oder nicht würde ein Anwender es dann immer im Internal finden.

Grüße Sidey

[Ralf9]

Hier ist der PR
https://github.com/RFD-FHEM/RFFHEM/pull/554

Gruß Ralf

[Gisbert]

Hallo,

ich hab mir meinen Signalduino zerschossen.
Der Signalduino hängt an einem HP ThinClient T610 und hat bis zum Update-Versuch funktioniert.

Wenn ich einen reset-Befehl abschicke bekomme ich folgendes;

Code Auswählen Erweitern

2019.04.07 13:13:46 3: mySIGNALduino reset
2019.04.07 13:13:46 3: Opening mySIGNALduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0
2019.04.07 13:13:46 3: Setting mySIGNALduino serial parameters to 57600,8,N,1
2019.04.07 13:13:46 1: mySIGNALduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
2019.04.07 13:13:46 1: mySIGNALduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
2019.04.07 13:13:46 3: mySIGNALduino device opened
2019.04.07 13:13:47 3: mySIGNALduino/init: disable receiver (XQ)
2019.04.07 13:13:47 5: mySIGNALduino SW: XQ
2019.04.07 13:13:48 3: mySIGNALduino/init: get version, retry = 0
2019.04.07 13:13:48 5: mySIGNALduino SW: V
2019.04.07 13:13:58 3: mySIGNALduino/init: get version, retry = 1
2019.04.07 13:13:58 5: mySIGNALduino SW: V
2019.04.07 13:14:08 3: mySIGNALduino/init: get version, retry = 2
2019.04.07 13:14:08 5: mySIGNALduino SW: V
2019.04.07 13:14:18 3: mySIGNALduino/init: get version, retry = 3
2019.04.07 13:14:18 2: mySIGNALduino/init retry count reached. Reset
2019.04.07 13:14:18 3: mySIGNALduino reset
2019.04.07 13:14:18 3: Opening mySIGNALduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0
2019.04.07 13:14:18 3: Setting mySIGNALduino serial parameters to 57600,8,N,1
2019.04.07 13:14:18 1: mySIGNALduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
2019.04.07 13:14:18 1: mySIGNALduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
2019.04.07 13:14:18 3: mySIGNALduino device opened
2019.04.07 13:14:19 3: mySIGNALduino/init: disable receiver (XQ)
2019.04.07 13:14:19 5: mySIGNALduino SW: XQ
2019.04.07 13:14:20 3: mySIGNALduino/init: get version, retry = 0
2019.04.07 13:14:20 5: mySIGNALduino SW: V
2019.04.07 13:14:30 3: mySIGNALduino/init: get version, retry = 1
2019.04.07 13:14:30 5: mySIGNALduino SW: V
2019.04.07 13:14:40 3: mySIGNALduino/init: get version, retry = 2
2019.04.07 13:14:40 5: mySIGNALduino SW: V
2019.04.07 13:14:50 3: mySIGNALduino/init: get version, retry = 3
2019.04.07 13:14:50 2: mySIGNALduino/init retry count reached. Closed
2019.04.07 13:14:50 2: mySIGNALduino closed

Wenn ich versuche diese Firmware zu flashen: ./FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex (Datei befindet sich in diesem Ordner), bekomme ich folgenden Last Flashlog:

Code Auswählen Erweitern

avrdude: Version 6.3
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

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

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

Ein list meines Devices:

Code Auswählen Erweitern

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
   DMSG       nothing
   DevState   INACTIVE
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103SXYZ-if00-port0@57600
   FUUID      5c92818b-f33f-e986-6d47-fb7aae3a694cebbe
   LASTDMSG   nothing
   NAME       mySIGNALduino
   NR         27
   STATE      closed
   TIME       1554633853
   TYPE       SIGNALduino
   initResetFlag 1
   initretry  3
   sendworking 0
   unknownmessages
   version   
   versionProtocols 1.01
   versionmodul v3.4.0_dev_16.03
   .attraggr:
   .attrminint:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-03-20 21:19:01   config          MS=1;MU=1;MC=1
     2019-03-20 21:50:09   freeram         769
     2019-04-07 12:01:24   ping            OK
     2019-04-07 13:20:58   state           closed
     2019-03-20 21:50:23   uptime          0 00:15:39
     2019-04-07 12:06:08   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   helper:
     bm:
       SIGNALduino_Attr:
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        07.04. 12:48:33
         max        0.000696897506713867
         tot        0.00156450271606445
         mAr:
           set
           mySIGNALduino
           verbose
           5
       SIGNALduino_Get:
         cnt        22
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        07.04. 13:20:27
         max        5.81741333007812e-05
         tot        0.00071406364440918
         mAr:
           HASH(0x55c4ca168690)
           mySIGNALduino
           ?
       SIGNALduino_Set:
         cnt        67
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        07.04. 13:20:26
         max        51.4582250118256
         tot        205.9014108181
         mAr:
           HASH(0x55c4ca168690)
           mySIGNALduino
           flash
           ./FHEM/firmware/SIGNALDuino_nanocc1101R3.3.1-RC10.hex
   mcIdList:
   msIdList:
     13
   muIdList:
     9
     13.1
Attributes:
   WS09_CRCAUS 2
   flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      SIGNALduino
   hardware   nanoCC1101
   icon       cul
   updateChannelFW stable
   verbose    5
   whitelist_IDs 9,13,13.1

Das Fhem-Wiki habe ich gelesen.
Wie sollte ich vorgehen, damit ich eine stabile Firmware auf den Arduino flashen kann?
Falls möglich, wie kann man den Arduino evtl. ohne Fhem an einem Windows-Rechner flashen?

Viele Grüße Gisbert

[rcmcronny]

Hallo,

einfach die hex datei flashen, ist letztlich ne binary

Ich nutze da meistens den nodemcu flasher:  https://github.com/nodemcu/nodemcu-flasher
Da die hex laden als file bei "config" und als Adresse die 0x00000 angeben , Kreuz vorn bei dem anmachen und bei den anderen aus und go

Ronny

[elektron-bbs]

Mhmm, einen Arduino mit nodemcu flashen, kann das funktionieren?
Besser geeignet wäre sicher die Arduino-IDE.

[Sidey]

Die Arduino IDE ruft auch nur avrdude auf.
Hast Du einen Programmer um den Bootloader neu zu brennen?

[Gisbert]

Hallo Ronny,

im NodeMCU-Flasher werden keine MAC-Adressen gefunden; der Uploadvorgang startet nicht.
Unter Advanced steht:
Baudrate: 115200, Flashsize 4MByte, Flash speed: 40 MHz, SPI Method: DIO - ist das richtig?
Unter log steht:
Note:Detect serial port changed.
Note:Auto MAP serial port.Port-->COM6

In der Arduino-IDE habe ich versucht einen quasi leeren Sketch zu flashen.
Als Antwort bekomme ich folgendes:

Code Auswählen Erweitern

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xae
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xae
Das ist in etwa das, was Fhem auch ausgespuckt hatte.
Gehe ich richtig in der Annahme, dass der Arduino Nano hin ist?
Oder gibt es eine Möglicheit ihn zu beleben?.

Viele Grüße Gisbert

[Gisbert]

Die Arduino IDE ruft auch nur avrdude auf.
Hast Du einen Programmer um den Bootloader neu zu brennen?

Ich hab ein Teil, mit dem ich die ESP8266-01 flashen kann, meinst du so was?

[rcmcronny]

Hoi,

ach sorry, ich war beim SignalESP :/
Arduino geht natürlich nicht damit

Hmm, ich hatte bei meinem SignalDuino das nur, wenn die Baudraute usw nicht stimmt, aber ob das nun genau gleich war oder nicht, weiss ich nichtmehr.

FlashCommand bei dem ist im FHEM:

Code Auswählen Erweitern

avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]

Aber das ist ja wie Deiner, daran liegts also nicht, wird der Nano wohl hin sein ..hmm

Ronny

[Gisbert]

Hallo Ronny,

SignalESP hört sich interessant an, dann wäre ich unabhängig vom Standort des Servers.
Läuft der bei dir?
Wie ist ggf. deine Erfahrung damit?
Was muss ich auf einen ESP flashen, ich hab NodeMCU, Wemos D1 mini und einen ESP8266-12 zur Verfügung?

Viele​ Grüße​ Gisbert​