Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

Begonnen von Ralf9, 13 Dezember 2019, 12:48:26

Vorheriges Thema - Nächstes Thema

Reinhard.M

Hallo Jürgen,
ich hatte das schon mal mit verbose=4 versucht. Das hat mir innerhalb kürzester Zeit das Log auf 15MB aufgeblasen. Hat leider keine weiterführenden Informationen geliefert. Höchstens das bereits kurz vorher Empfangssamples verloren wurden (bei mir kommt alle 4 Sekunden etwas vom LaCross Sender). Ich werde das Maple Log mal auf täglich umstellen und hoffe darin dann noch etwas wiederzufinden.

Gruß
Reinhard

P.S.: Mir ist schon klar, dass meine Aussagen recht vage sind, HW/SW debugging mache ich bereits seit sehr vielen Jahren. Leider ist das komplette System (FHEM, Maple, Radio, ...) für mich neu und ich muss mich an vielen Stellen erst einmal orientieren und einarbeiten. Es wird aber von Tag zu Tag besser  :)

juergs

Hallo Reinhard,
bitte nicht falsch verstehen, war kein Vorwurf!

15 MB ist jetzt auch nicht unbedingt "viel"     ;-) 

Vielleicht hilft dann schon ein tail -f -n 200 in der Konsole auf das Log?

Du kannst ja den einem Plot den Referenz-Zeitpunkt entnehmen, danach  einfach wieder verbose auf 3 zurücksetzen.

Grüße,
Jürgen 

killah78

Zwischeninfo:
Seit gestern 0 Uhr bis jetzt, also ca 36h, nur eine(1) 'Verzögerung' von nur 30 Sekunden. Ansonsten immer Empfang zwischen 5 und 10 Sekunden. Ich dachte immer der Intervall sei 10 Sekunden, aber scheinbar sind es 5.
Signalduino läuft jetzt 12 Tage.
Am ersten Tag gab es eine Verzögerung von 20 Stunden, es wurde von Tag zu Tag besser. Jetzt aktuell quasi fehlerfrei.

juergs

UART2+3 funktionieren schon mal im Zusammenspiel im MapleSduino_SER2WLAN.

juergs

Hallo Ralf,

Zitatvoid serialEvent()
{
  while (MSG_PRINTER.available())
  {
    char inChar = (char)MSG_PRINTER.read();
    switch(inChar)
    {
        case '\n':
        case '\r':
        case '\0':
        case '#':
           _command_available = true;
           break;
        default:
           cmdstring += inChar;
    }   
       
    if (cmdstring.length() > maxCmdString)
    {
        cmdstring = "";            //--- restliche Zeichen ignorieren        
        MSG_PRINT(F("cmd to long! (max "));
        MSG_PRINT(maxCmdString);
        MSG_PRINTLN(F(")"));
    }
  }
 
  if (cmdstring != "")
  {
    MSG_PRINT("serialEvent.cmdstring = ");MSG_PRINTLN(cmdstring);
  }
}

Ich glaube, dass die Bedingung
Zitatwhile (MSG_PRINTER.available())
von der zeitlichen Abfolge der Übergabe des KommandoStrings abhängt!

Ist sie zu lang (wie z.B. bei einer manueller Eingabe), schaltet available zwischendurch gemäß ihrem internen Timeout  auf false.
=> Wäre zu klären, wie lange das Timeout sein darf ? (Vermute es sind 1..n Char-Übertragungs-Zeiten bis es kippt.) 
Dann wird das folgende "CR" oder "LF" als eigenständiger Befehl interpretiert und liefert "Unknown Command":

ZitatserialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
...
HandleCommand.cmd0=V. Length:1 : Char: V
HandleCommand.cmd1=V. Length:1 : Char: .
HandleCommand.TokenFound: V. Index: 18
HandleCommand.cmdstring = >V<
HandleCommand.cmd0=V. Length:1 : Char: V
HandleCommand.cmd1=V. Length:1 : Char: .
HandleCommand.break: Length=1
V 4.2.0-dev20050z6_juergs SIGNALduino cc1101 (R: Ai B-* C- D-) - compiled at May 24 2020 11:36:19
HandleCommand.cmd0=. Length:0 : Char: .
HandleCommand.cmd1=. Length:0 : Char: .
HandleCommand.cmdstring = ><
...
HandleCommand.cmd0=. Length:0 : Char: .
HandleCommand.cmd1=. Length:0 : Char: .
HandleCommand.i=23   unsupported?
Unsupported command

Das scheint mir ein Manko bei der Eingaberoutine zu sein ... und muss mal über eine Lösungs-Möglichkeit grübeln....  ;)

Ggf. ist aber nur eine Ausprägung beim manuellen Testen und käme "automatisiert" so eigentlich nicht vor ?

Die SerialCommand-Lib scheint mir da besser geeignet und komfortabler zu sein...

Der Unterschied zwischen USBSerial und HardwareSerial? => unterschiedliche Timeoutzeiten?


Ralf9

Ich hab mir mal die optimize Optionen bei der Arduino IDE angeschaut:
-Os
-O1
-O2
-O3
with LTO
-g (debug)


verwendet wird beim MapleMini der "arm-none-eabi-c++"

ich hab zu den Optimize-Options folgendes gefunden
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

ZitatLTO - Link-Time-Optimizations:

Der Linker optimiert den kompletten Code. Da er nicht nur ein Source-File, sondern alle kennt, kann er optimieren, wo dem Compiler Informationen fehlen. Achtung: bei älteren Compiler-Versionen muss nach diesem Flag noch einmal die Optimierungsstufe angegeben werden.

Da beim -Os folgendes steht und das -O0 nicht zur Auswahl steht
Zitat-Os -  Optimize for size. -Os enables all -O2 optimizations except those that often increase code size:
müsste eigentlich das -O1 die wenigsten Optimierungen machen.


zu -g habe ich folgendes gefunden:
ZitatProduce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.

On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).

Kann ich die debug Info irgendwie nutzen um bei einem Absturz den Grund rauszufinden?


Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

juergs

ZitatKann ich die debug Info irgendwie nutzen um bei einem Absturz den Grund rauszufinden?
Das erzeugt nur Metafiles die über einen Debugger genutzt werden könnten. Ohne  explizite Debugausgaben  z.B. Led ein oder sogar ein Muster bei Interrupt-Routinen ein etc. wäre wahrscheinlich
einfacher die Code-Ebene bzw. ein Deadlock einzugrenzen.
Wie Du schon erwähnt hast, bedeuten serielle Debugausgaben auch eine Beeinflussung der Performance.

Schau Dir mal diese Lib dazu an: https://github.com/JoaoLopesF/SerialDebug
Die Java-App dazu gibt es leider nicht mehr ... geht aber über Serial-Monitor genauso.
Dort kann man sogar online den Tracelevel ändern und scheint ganz brauchbar zu sein.

ZitatSerialDebug takes care of inputs from serial, and process predefined commands as:
  ? or help -> display these help of commands
  m -> show free memory
  n -> set debug level to none
  v -> set debug level to verbose
  d -> set debug level to debug
  i -> set debug level to info
  w -> set debug level to warning
  e -> set debug level to errors
  s -> silence (Not to show anything else, good for analysis)
  p -> profiler:
    p      -> show time between actual and last message (in millis)
    p min  -> show only if time is this minimal
  r -> repeat last command (in each debugHandle)
    r ? -> to show more help
  reset -> reset the Arduino board

  f -> call the function
      f ?  -> to show more help

  dbg [on|off] -> enable/disable the simple software debugger

  Only if debugger is enabled:
      g -> see/change global variables
        g ?  -> to show more help
      wa -> see/change watches for global variables
        wa ?  -> to show more help

  Not yet implemented:
    gpio -> see/control gpio

Ralf9

ich habe für mein angepasstes 00_SIGNALduino.pm ein neues Thema angelegt
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900

Ich mache gerade ein Dauertest über WLAN ich verwende dafür den Wemos D1 mini als serielle Bridge, die Verbindung läuft stabil ohne Abbrüche oder Aussetzer.
Es gibt dafür eine firmware bei der anstatt USB die erste serielle RX und TX verwendet wird
https://github.com/Ralf9/SIGNALDuino/releases

@Reinhard.M
hast Du inzwischen den MapleSduino zusammengebaut, funktioniert es damit besser?


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Zitat von: Ralf9 am 29 Mai 2020, 19:06:20
@Reinhard.M
hast Du inzwischen den MapleSduino zusammengebaut, funktioniert es damit besser?
Hallo Ralf,
ich warte noch auf die Maple Platinen vom Ali. Hatte in der Zwischenzeit weitere Aussetzer des Empfängers auf Modul A, Lacross. Bei selbstheilenden Aussetzern ging der Empfang nach einiger Zeit einfach weiter. Ohne irgendeine Einwirkung von mir. Wenn ich einen solchen Aussetzer beobachtet habe, meist nach mehreren Stunden, brauchte ich den Receiver nur mit einem simplen "get Maple XEA" einschalten und der Empfang ging ebenfalls weiter.
Hatte außerdem wieder "Device Closed" Fehler. Der Maple war also komplett abgeschaltet. Watchdog hatte entweder überhaupt nicht zugeschlagen oder zu spät, so dass der Maple vom FHEM abgehängt wurde. Ein "upload_reset" über Raspi hat ihn nicht wieder auf die Beine gestellt. Mehrfach wiederholt. Erst ein "set Maple reset" über FHEM brachte das Teil wieder zum Laufen. Oftmals mit mehreren Restarts (DISCONNECTED, CONNECTED, DISCONNECTED, ...) kurz nacheinander. Danach aber alles bestens.
Soviel vorab, ich versuche weiterhin aus den Log Daten Auffälligkeiten abzuleiten. Bislang konnte ich noch nichts entdecken. Muss auch noch mehr über Abhängigkeiten im FHEM lernen und verstehen, dauert etwas. Und momentan ist mein Zeitkonto dafür extrem dünn  :-\ Ich hoff aber in den kommenden Tagen mehr Zeit zu haben  :) Dann werde ich die aufbereiteten Log Daten hier zur Verfügung stellen.

Gruß
Reinhard


Ralf9

Hallo Reinhard,
Zitat
Hatte in der Zwischenzeit weitere Aussetzer des Empfängers auf Modul A, Lacross.
Ich habe hier überhaupt keine Ausetzer, bei Modul A, Lacross.
Ich habe momentan eine uptime von 2 Tagen und 12 Stunden
Ich habe ein "event-min-interval .*:600" gesetzt und im filelog habe ich alle 10 Min einen Eintrag.

Ich habe hier nur einen Lacross Sensor.
Evtl ist bei Dir mehr als ein Lacross Sensor in Reichweite und es kommt zu überlagerungs Effekten
oder es gibt bei Dir ein Problem mit der Hardware mit dem meine Firmware nicht zurecht kommt.

Zitat
Hatte außerdem wieder "Device Closed" Fehler.

Du kannst mal schauen ob Du im Log so was ähnliches findest.
Ich habe in der aktuellen Version vom 00_SIGNALduino Modul was geändert, seither war beim init bei get version ein timeout von 10 sek,
nun erhöht sich bei jedem rety der timeout um 30 sek
2020.05.28 16:01:22.494 3: sduino/KeepAlive not ok, retry = 2 -> get ping
2020.05.28 16:02:22.499 3: sduino/KeepAlive not ok, retry = 3 -> get ping
2020.05.28 16:03:22.499 3: sduino/keepalive not ok, retry count reached. Reset
2020.05.28 16:03:22.499 3: sduino reset
2020.05.28 16:03:22.499 3: Opening sduino device 192.168.0.13:23
2020.05.28 16:03:22.603 1: sduino/define: 192.168.0.13:23
2020.05.28 16:03:22.603 1: sduino/init: 192.168.0.13:23
2020.05.28 16:03:22.603 3: sduino device opened
2020.05.28 16:03:24.105 3: sduino/init: disable receiver (XQ)
2020.05.28 16:03:24.604 3: sduino/init: get version, retry = 0
2020.05.28 16:03:34.617 3: sduino/init: get version, retry = 1
2020.05.28 16:04:14.632 3: sduino/init: get version, retry = 2
2020.05.28 16:05:24.645 3: sduino/init: get version, retry = 3



Mir ist auch aufgefallen, daß der Maple Mini mit dem Bootloader 2.0 ein seltsames Verhalten hat.
Nach dem reset funktioniert der serielle Empfang über USB sofort wieder und fällt dann nach sehr kurzer Zeit wieder kurz aus

2020.05.30 09:29:10.001 3 : Setting sduinoRXB serial parameters to 115200,8,N,1
2020.05.30 09:29:10.002 1 : sduinoRXB/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:10.002 1 : sduinoRXB/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:10.002 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-05-30 09:29:10.003 SIGNALduino sduinoRXB CONNECTED
2020.05.30 09:29:10.022 3 : sduinoRXB/noMsg Parse: Reading values from eeprom
2020.05.30 09:29:10.022 3 : sduinoRXB/noMsg Parse: CCInit
2020.05.30 09:29:10.023 3 : sduinoRXB/noMsg Parse: detect A: Partn=0 Ver=24
2020.05.30 09:29:10.025 3 : sduinoRXB/noMsg Parse: detect B: Partn=0 Ver=20
2020.05.30 09:29:10.027 3 : sduinoRXB/noMsg Parse: detect C: Partn=0 Ver=20
2020.05.30 09:29:10.028 3 : sduinoRXB/noMsg Parse: Starting timerjob
2020.05.30 09:29:10.084 3 : sduinoRXB/noMsg Parse: rxA=1 rxB=1 rxC=1
2020.05.30 09:29:11.502 3 : sduinoRXB/init: disable receiver (XQ)
2020.05.30 09:29:11.513 3 : sduinoRXB/noMsg Parse: Unsupported command
2020.05.30 09:29:12.003 3 : sduinoRXB/init: get version, retry = 0
2020.05.30 09:29:13.584 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 disconnected, waiting to reappear (sduinoRXB)
2020-05-30 09:29:13.586 SIGNALduino sduinoRXB DISCONNECTED
2020.05.30 09:29:22.014 3 : sduinoRXB/init: get version, retry = 1

2020.05.30 09:29:30.029 3 : Setting sduinoRXB serial parameters to 115200,8,N,1
2020.05.30 09:29:30.030 1 : sduinoRXB/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:30.030 1 : sduinoRXB/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:30.030 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-05-30 09:29:30.031 SIGNALduino sduinoRXB CONNECTED
2020.05.30 09:29:31.532 3 : sduinoRXB/init: disable receiver (XQ)
2020.05.30 09:29:31.542 3 : sduinoRXB/noMsg Parse: rxA=0 rxB=0 rxC=0
2020.05.30 09:29:32.031 3 : sduinoRXB/init: get version, retry = 0
2020.05.30 09:29:32.041 3 : sduinoRXB/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0* C3) - compiled at May 9 2020 19:14:17
2020-05-30 09:29:32.043 SIGNALduino sduinoRXB opened
2020.05.30 09:29:32.054 3 : sduinoRXB/noMsg Parse: r=A b=1 rx=0 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07137C43023B900070018146C070090 boffs=0000* r=C b=3 rx=0 N=3 ccmode=3 sync=2DD4 ccconf=216BD0880B0622F853070018166C436891 boffs=0180
2020.05.30 09:29:32.054 2 : sduinoRXB: initialized. v3.4.5-dev_ralf_05.28.
2020.05.30 09:29:32.064 3 : sduinoRXB/init: enable receiver (XE)
2020.05.30 09:29:32.065 3 : sduinoRXB/noMsg Parse: rxA=1 rxB=1 rxC=1


Gruß Ralf


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Hallo Ralf,
danke für das schnelle Feedback. Wie gesagt möchte ich brauchbares Feedback liefern aber dafür brauche ich noch Zeit. Gerade bei den Funkprotokollen bin ich quasi noch bei null und muss mir noch einiges anlesen. Vom FHEM Wiki und Forum abgesehen weiß ich allerdings noch nicht wo. Muss halt suchen. Falls du mir einen Tipp geben kannst - herzlichen Dank  :)
Mein Lacross jagt alle 4 Sekunden ein Telegram raus, scheint aber der einzige Sender dieser Art zu sein. Konnte bislang jedenfalls keinen anderen entdecken.
Seit ich den Watchdog aktiviert habe sehe ich den von dir gezeigten 2020.05.28 16:03:22.499 3: sduino reset nicht mehr. Wohl aber ein "disconnected/connected". Ich werde mal den Watchdog Timer hochdrehen auf 15 Sekunden, derzeit steht er noch auf 5 Sekunden.
Ich verwende den MSC_Bootloader von Telekatz und nicht den Bootloader_2.0, der 2.0 sollte also keinen Einfluss haben. Aber dein letzter Codeschnipsel 2020-05-30 09:29:13.586 SIGNALduino sduinoRXB DISCONNECTED
2020-05-30 09:29:30.031 SIGNALduino sduinoRXB CONNECTED
kommt mir sehr bekannt vor. So ähnlich sieht es bei mir auch aus. Teilweise mehrfach nacheinander.
Bitte noch ein wenig Geduld, ich möchte das vernünftig dokumentieren damit ihr mit den Informationen auch etwas anfangen könnt.

Reinhard.M

Hallo Ralf,
ich habe jetzt einen recht stabilen Fehlerfall dokumentiert, eventuell kannst du aus den angehängten Daten erkennen.
Ich verwende den Maple auch für die Rollosteuerung in meinem Haus. Sobald ein Steuerbefehl raus geht ruft das einen Reset des Maples hervor. So massiv ist es mir bislang nicht aufgefallen. Allerdings habe ich heute den Watchdog Timer von 4s auf 20s gesetzt und dafür die v4.1.1 neu kompiliert:
Zitat
#define MAPLE_CUL 1
V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
Hier noch die komplette Aufzeichnung eines solchen Absturz:


2020.05.31 23:59:32.485 3: myMaple: SingleJaro set up 7
2020.05.31 23:59:32.485 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.487 SingleJaro LastAction_Channel_07: up
2020.05.31 23:59:32.487 SingleJaro button: up
2020.05.31 23:59:32.487 SingleJaro channel: 7
2020.05.31 23:59:32.487 SingleJaro channel_control: no
2020.05.31 23:59:32.487 SingleJaro counter_send: 8521
2020.05.31 23:59:32.487 SingleJaro state: send up
2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 4: myMaple/msg READ: 1. Received answer (V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05) for sendraw does not match ^S(R|C|M|N);
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:35.319 4: myMaple/msg READ: MU;P0=-6472;P1=1116;P2=3172;CP=1;R=230;D=010202020202010101020201020202010102020202010201010102020202020101020202020102020201;e;
2020.05.31 23:59:35.752 4: myMaple/msg READ: MU;P0=-6496;P1=3144;P2=1111;CP=2;R=230;D=01020101010101020202010102010101020201010101020102020201010101010202010101010201010102;e;
2020.05.31 23:59:35.928 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:35.928 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000AF52BA;R=221;
2020.05.31 23:59:35.929 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91.5 dB, dispatch
2020.05.31 23:59:35.929 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:35.929 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:36.069 3: myMaple: SingleJaro set stop 7
2020.05.31 23:59:36.069 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.074 SingleJaro LastAction_Channel_07: stop
2020.05.31 23:59:36.074 SingleJaro button: stop
2020.05.31 23:59:36.074 SingleJaro channel: 7
2020.05.31 23:59:36.074 SingleJaro channel_control: no
2020.05.31 23:59:36.074 SingleJaro counter_send: 8522
2020.05.31 23:59:36.074 SingleJaro state: send stop
2020.05.31 23:59:36.179 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.553 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.05.31 23:59:36.555 myMaple DISCONNECTED
2020.05.31 23:59:36.800 SD_WS_85_THW_1 myRD: myMaple T: 11.8 H: 72 W: 0
2020.05.31 23:59:38.180 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:38.181 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:38.628 3: Setting myMaple serial parameters to 115200,8,N,1
2020.05.31 23:59:38.632 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.05.31 23:59:38.632 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.05.31 23:59:38.633 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.05.31 23:59:38.634 myMaple CONNECTED
2020.05.31 23:59:38.654 4: myMaple/msg READ: Reading values from eeprom
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: CCInit
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: Reading values from eeprom
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: detect A: Partn=0 Ver=20
2020.05.31 23:59:38.655 4: myMaple/msg READ: CCInit
2020.05.31 23:59:38.655 4: myMaple/msg READ: detect A: Partn=0 Ver=20
2020.05.31 23:59:38.657 3: myMaple/noMsg Parse: detect B: Partn=0 Ver=24
2020.05.31 23:59:38.657 4: myMaple/msg READ: detect B: Partn=0 Ver=24
2020.05.31 23:59:38.658 3: myMaple/noMsg Parse: Starting timerjob
2020.05.31 23:59:38.658 4: myMaple/msg READ: Starting timerjob
2020.05.31 23:59:38.712 3: myMaple/noMsg Parse: rxA=1 rxB=1
2020.05.31 23:59:38.712 4: myMaple/msg READ: rxA=1 rxB=1
2020.05.31 23:59:39.990 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000D36BA8;R=222;
2020.05.31 23:59:39.991 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:39.991 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:39.991 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:39.992 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91 dB, dispatch
2020.05.31 23:59:40.133 3: myMaple/init: disable receiver (XQ)
2020.05.31 23:59:40.416 3: myMaple/noMsg Parse: Unsupported command
2020.05.31 23:59:40.416 4: myMaple/msg READ: Unsupported command
2020.05.31 23:59:40.633 3: myMaple/init: get version, retry = 0
2020.05.31 23:59:40.644 4: myMaple/msg READ: OK
2020.05.31 23:59:40.645 4: myMaple/msg READ: 2. Received answer (OK) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.05.31 23:59:40.645 4: myMaple/noMsg Parse: OK
2020.05.31 23:59:41.305 3: myMaple/noMsg Parse: 10948
2020.05.31 23:59:41.305 4: myMaple/msg READ: 10948
2020.05.31 23:59:41.305 4: myMaple/msg READ: 3. Received answer (10948) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.05.31 23:59:44.036 3: myMaple/noMsg Parse: Unsupported command
2020.05.31 23:59:44.036 4: myMaple/msg READ: Unsupported command
2020.05.31 23:59:44.037 1: myMaple: Not an SIGNALduino device, setting attribute dummy=1 got for V:  Unsupported command
2020.05.31 23:59:44.039 myMaple state: no SIGNALduino found
2020.05.31 23:59:44.047 2: myMaple closed
2020.05.31 23:59:44.050 myMaple state: closed
2020.05.31 23:59:44.056 di_myMaple state: closed, reset device
2020.05.31 23:59:45.054 3: Opening myMaple device /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00
2020.05.31 23:59:45.054 3: myMaple reset
2020.05.31 23:59:45.055 1: myMaple: Can't open /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00: Device or resource busy
2020.05.31 23:59:45.056 myMaple reset
2020.06.01 00:00:04.849 3: Setting myMaple serial parameters to 115200,8,N,1
2020.06.01 00:00:04.853 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.01 00:00:04.853 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.01 00:00:04.854 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.06.01 00:00:04.856 myMaple CONNECTED
2020.06.01 00:00:06.354 3: myMaple/init: disable receiver (XQ)
2020.06.01 00:00:06.365 4: myMaple/msg READ: rxA=0 rxB=0
2020.06.01 00:00:06.366 3: myMaple/noMsg Parse: rxA=0 rxB=0
2020.06.01 00:00:06.366 4: myMaple/msg READ: 1. Received answer (rxA=0 rxB=0 ) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.06.01 00:00:06.854 3: myMaple/init: get version, retry = 0
2020.06.01 00:00:06.866 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.06.01 00:00:06.866 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.06.01 00:00:06.868 myMaple state: opened
2020.06.01 00:00:06.874 di_myMaple state: opened, set patable 10dBm
2020.06.01 00:00:06.884 4: myMaple/init: firmwareversion with ccBankSupport and multi cc1101 found
2020.06.01 00:00:06.895 4: myMaple/msg READ: r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100  r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*
2020.06.01 00:00:06.896 3: myMaple/noMsg Parse: r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100  r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*
2020.06.01 00:00:06.896 4: myMaple/init: Write ccBankInfo: (r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100  r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*) to Internal ccconf
2020.06.01 00:00:06.897 2: myMaple: initialized. v3.4.5-dev_ralf_05.24.
2020.06.01 00:00:06.907 3: myMaple/init: enable receiver (XE)
2020.06.01 00:00:06.908 3: myMaple/noMsg Parse: rxA=1 rxB=1
2020.06.01 00:00:06.908 4: myMaple/msg READ: rxA=1 rxB=1
2020.06.01 00:00:08.307 SD_WS_85_THW_1 myRD: myMaple T: 11.8 H: 72 W: 0
2020.06.01 00:00:10.875 myMaple cc1101_patable_433 10_dBm
2020.06.01 00:00:12.499 LaCrosse_08 myRD: myMaple T: 13.8 H: 63
2020.06.01 00:00:16.561 LaCrosse_08 myRD: myMaple T: 13.9 H: 63
2020.06.01 00:00:24.699 LaCrosse_08 myRD: myMaple T: 13.8 H: 63
2020.06.01 00:00:28.756 LaCrosse_08 myRD: myMaple T: 13.9 H: 63
2020.06.01 00:00:32.820 LaCrosse_08 myRD: myMaple T: 13.8 H: 63


Ich hoffe diese Daten helfen etwas weiter. Momentan habe ich den Verbose Level des Maples auf 4 gesetzt, sollte es nötig sein kann ich es mit 5 wiederholen.

Gruß Reinhard

Ralf9

es sieht so aus als würde kurz nach dem Senden der watchdog auslösen
2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 4: myMaple/msg READ: 1. Received answer (V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05) for sendraw does not match ^S(R|C|M|N);
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:35.319 4: myMaple/msg READ: MU;P0=-6472;P1=1116;P2=3172;CP=1;R=230;D=010202020202010101020201020202010102020202010201010102020202020101020202020102020201;e;
2020.05.31 23:59:35.752 4: myMaple/msg READ: MU;P0=-6496;P1=3144;P2=1111;CP=2;R=230;D=01020101010101020202010102010101020201010101020102020201010101010202010101010201010102;e;
2020.05.31 23:59:35.928 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:35.928 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000AF52BA;R=221;
2020.05.31 23:59:35.929 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91.5 dB, dispatch
2020.05.31 23:59:35.929 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:35.929 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:36.069 3: myMaple: SingleJaro set stop 7
2020.05.31 23:59:36.069 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.074 SingleJaro LastAction_Channel_07: stop
2020.05.31 23:59:36.074 SingleJaro button: stop
2020.05.31 23:59:36.074 SingleJaro channel: 7
2020.05.31 23:59:36.074 SingleJaro channel_control: no
2020.05.31 23:59:36.074 SingleJaro counter_send: 8522
2020.05.31 23:59:36.074 SingleJaro state: send stop
2020.05.31 23:59:36.179 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.553 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.05.31 23:59:36.555 myMaple DISCONNECTED


Der watchdog muss regelmässig getriggert werden, damit er nicht auslöst, evtl passt da etwas noch nicht so ganz

Seltsam ist, daß fast zeitgleich mit dem Senden die Antwort von einem "get version" empfangen wird:

2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Zitat von: Ralf9 am 01 Juni 2020, 10:19:16
es sieht so aus als würde kurz nach dem Senden der watchdog auslösen
Der watchdog muss regelmässig getriggert werden, damit er nicht auslöst, evtl passt da etwas noch nicht so ganz
Ich hatte den Watchdog von 4 auf 20 Sekunden hochgesetzt. Eventuell habe ich den Timer überzogen, ich habe noch nicht herausgefunden wie hoch ich ihn maximal stellen kann. Mit 4 Sekunden ist das Verhalten nicht zu sehen, das habe ich gerade nochmals getestet.
Bislang wird der WD nur in der Hauptschleife getriggert, also so, wie es momentan im 'SIGNALDuino.ino' schon vorgegeben ist. Und mit 4 Sekunden lief auch alles problemlos.

Zitat von: Ralf9 am 01 Juni 2020, 10:19:16
Seltsam ist, daß fast zeitgleich mit dem Senden die Antwort von einem "get version" empfangen wird:
Auf mich macht es den Eindruck, dass in der Message Queue etwas hängen bleibt. Der Maple fliegt ja quasi mit dem Senden der Message raus:
2020.06.01 00:57:36.980 3: myMaple: SingleJaro set up 7
2020.06.01 00:57:37.080 5: myMaple SW: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151515124515124512424242451512424515124512451515124512424512451512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.06.01 00:57:37.090 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151515124515124512424242451512424515124512451515124512424512451512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.06.01 00:57:37.609 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)

Zwischen Senden und Disconnect liegt nicht einmal eine Sekunde, das lässt sich tatsächlich jederzeit reproduzieren. Etwa 4 Sekunden später folgt dann die merkwürdige Versionsabfrage (der IWDG ist hier auf ~20s eingestellt). Und was könnte das mit dem Setting des IWDG zu tun haben?

Ralf9

ZitatIch hatte den Watchdog von 4 auf 20 Sekunden hochgesetzt. Eventuell habe ich den Timer überzogen, ich habe noch nicht herausgefunden wie hoch ich ihn maximal stellen kann.

@Telekatz :
weisst Du zufällig wie hoch man den Watchdogtimer setzen kann?
Verwendest Du bei der a-culw einen Watchdog? Wie hoch hast Du ihn gesetzt?

ZitatMit 4 Sekunden ist das Verhalten nicht zu sehen, das habe ich gerade nochmals getestet.
4 Sekunden sollten eigentlich reichen, gibt es bei 4 sek noch Probleme?

Mit dem Watchdog habe ich mich noch nicht beschäftigt.
Hast Du mir mal den Code wie Du den Watchdog aktivierst?
Hast Du im Internet eine Beschreibung darüber gefunden?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7