FHEM Forum

CUL => Hard- und Firmware => Thema gestartet von: noansi am 09 Juni 2014, 19:16:01

Titel: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 09 Juni 2014, 19:16:01
*************************************************************************************************************
*************************************************************************************************************

Hier https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796) geht es zur aktuellen Version 0.39 von TS Firmware, auch mit CUNX Unterstützung und FHEM Modulen.

*************************************************************************************************************
*************************************************************************************************************

Hier https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733 (https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733) geht es zu einer für tsculfw VTS 0.28 und höher angepassten Version
von Michael Gernoths flash-ota tool.

*************************************************************************************************************
*************************************************************************************************************



Hallo Rudolf,

hier mein Vorschlag zu einer Firmwareerweiterung für den CUL zur Unterstützung der TimeStamp Option. Sie bringt für das Senden zusammen mit Martins 00_CUL Änderungen eine Verbesserung.
Wenn Du es einpflegen würdest, würde ich mich freuen. Natürlich bin ich auch für Kritik offen.

Edit: Vergleichsbasis zum diff ist ein trunk culfw-code-419-trunk Stand vom 7.6.14. Meine Änderungen basieren auf culfw-code-416-trunk von Mitte Mai.

Zwei Teile für die Diffs sind notwendig wegen der Länge.

--- clib/cc1100.c Wed Feb 06 00:29:54 2013
+++ clib/cc1100.c Thu May 29 23:47:48 2014
@@ -310,7 +310,7 @@
       DS_P( PSTR(" = ") );
       DH2(out);                  // result, hex
       DS_P( PSTR(" / ") );
-      DU(out,2);                  // result, decimal
+      DU(out,2);  // should be DU(out,3);               // result, decimal
       DNL();
     }
 
--- clib/cdc.c Sat Apr 17 12:31:34 2010
+++ clib/cdc.c Mon Jun 09 16:55:51 2014
@@ -72,13 +72,23 @@
 
   if(!inCDC_TASK && Endpoint_ReadWriteAllowed()){ // USB -> RingBuffer
 
+    uint8_t sreg;
+
+    sreg = SREG;
+    cli();
+
     while (Endpoint_BytesInEndpoint()) {          // Discard data on buffer full
       rb_put(&TTY_Rx_Buffer, Endpoint_Read_Byte());
     }
-    Endpoint_ClearCurrentBank();
+    Endpoint_ClearCurrentBank();
+
+    SREG = sreg;
+
     inCDC_TASK = 1;
+
     output_flush_func = CDC_Task;
     input_handle_func(DISPLAY_USB);
+
     inCDC_TASK = 0;
   }
 
@@ -86,13 +96,20 @@
   Endpoint_SelectEndpoint(CDC_TX_EPNUM);          // Then data out
   if(TTY_Tx_Buffer.nbytes && Endpoint_ReadWriteAllowed()) {
 
+    uint8_t sreg;
+
+    sreg = SREG;
     cli();
     while(TTY_Tx_Buffer.nbytes &&
           (Endpoint_BytesInEndpoint() < USB_BUFSIZE))
       Endpoint_Write_Byte(rb_get(&TTY_Tx_Buffer));
-    sei();
+//    SREG = sreg;
+    //sei();
     
+//    sreg = SREG;
+//    cli();
     Endpoint_ClearCurrentBank();                  // Send the data
+    SREG = sreg;
 
   }
 }
--- clib/cdcLUFA.c Sat Apr 17 12:31:34 2010
+++ clib/cdcLUFA.c Mon Jun 09 16:55:21 2014
@@ -71,7 +71,7 @@
 void
 CDC_Task(void)
 {
-  static char inCDC_TASK = 0;
+  static uint8_t inCDC_TASK = 0;
 
   if(!USB_IsConnected)
     return;
@@ -79,14 +79,24 @@
   Endpoint_SelectEndpoint(CDC_RX_EPNUM);          // First data in
   if(!inCDC_TASK && Endpoint_IsReadWriteAllowed()){ // USB -> RingBuffer
 
+    uint8_t sreg;
+
+    sreg = SREG; // make it safer for call in an interrupt
+    cli(); // inhibit interrupts, to avoid reading an empty byte due to empty USB Buffer, emptied in interrupt
+
     while (Endpoint_BytesInEndpoint()) {          // Discard data on buffer full
       rb_put(&TTY_Rx_Buffer, Endpoint_Read_Byte());
     }
-    Endpoint_ClearOUT();
+
+    Endpoint_ClearOUT(); //better not to be disturbed here by interrupt doing the same
+
+    SREG = sreg;       // allow interrupts
 
     inCDC_TASK = 1;
+
     output_flush_func = CDC_Task;
     input_handle_func(DISPLAY_USB);
+
     inCDC_TASK = 0;
   }
 
@@ -94,17 +104,28 @@
   Endpoint_SelectEndpoint(CDC_TX_EPNUM);          // Then data out
   if(TTY_Tx_Buffer.nbytes && Endpoint_IsReadWriteAllowed()) {
 
-    cli();
+    uint8_t sreg;
+
+    sreg = SREG; // make it safer for call in an interrupt
+    cli(); // inhibit interrupts
     while(TTY_Tx_Buffer.nbytes &&
           (Endpoint_BytesInEndpoint() < USB_BUFSIZE))
       Endpoint_Write_Byte(rb_get(&TTY_Tx_Buffer));
-    sei();
+    SREG = sreg; // allow interrupts
     
-    bool IsFull = (Endpoint_BytesInEndpoint() == USB_BUFSIZE);
-    Endpoint_ClearIN();                  // Send the data
+    uint8_t IsFull = (Endpoint_BytesInEndpoint() == USB_BUFSIZE);
+
+    sreg = SREG; // make it safer for call in an interrupt
+    cli(); // inhibit interrupts
+    Endpoint_ClearIN(); // Send the data, better not to be disturbed here by interrupt doing the same
+    SREG = sreg; // allow interrupts
+
     if(IsFull) {
       Endpoint_WaitUntilReady();
-      Endpoint_ClearIN();
+      sreg = SREG; // make it safer for call in an interrupt
+      cli(); // inhibit interrupts
+      Endpoint_ClearIN(); // Send the data
+      SREG = sreg; // allow interrupts
     }
   }
 }
--- clib/clock.c Fri Feb 08 06:15:52 2013
+++ clib/clock.c Fri Jun 06 23:56:37 2014
@@ -3,6 +3,7 @@
 #include <avr/interrupt.h>
 
 #include "board.h"
+
 #include "led.h"
 #ifdef XLED
 #include "xled.h"
@@ -17,6 +18,7 @@
 #include "rf_send.h"                   // credit_10ms
 #include "mysleep.h"
 #include "pcf8833.h"
+#include "rf_asksin.h"
 #ifdef HAS_USB
 #include "cdc.h"
 #endif
@@ -35,8 +37,8 @@
 uint8_t ir_ticks_thrd = 0;
 #endif
 
-volatile uint32_t ticks;
-volatile uint8_t  clock_hsec;
+volatile uint32_t ticks = 0;
+volatile uint8_t  clock_hsec = 0;
 
 // count & compute in the interrupt, else long runnning tasks would block
 // a "minute" task too long
@@ -54,12 +56,30 @@
 #endif
 
 #if defined (HAS_IRTX) || defined (HAS_IRRX)
-     // if IRRX is compiled in, timer runs 125x faster ...
+     // if IRRX is compiled in, timer runs 125x faster ...
+     // 15625Hz
      if (++ir_ticks<125)
        return;
-       
+
      ir_ticks = 0;
-#endif
+
+     // 125Hz
+
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+ // only 8ms increment for low additional CPU interrupt load
+ rf_asksin_ms += 8; // noansi: counter for ms, incremented by Timer 3 or Timer 0 with less granularity
+#endif //HAS_MS_TIMER0
+
+#else //HAS_IRTX || HAS_IRRX
+
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+ // 250 Hz
+ // only 4ms increment for low additional CPU interrupt load
+ rf_asksin_ms += 4; // noansi: counter for ms, incremented by Timer 3 or Timer 0 with less granularity
+ if ((uint8_t)rf_asksin_ms & 0x04) return;
+#endif //HAS_MS_TIMER0
+
+#endif //HAS_IRTX || HAS_IRRX
 
      // 125Hz
      ticks++;
--- clib/display.c Sun Jun 30 23:01:20 2013
+++ clib/display.c Mon Jun 09 00:25:16 2014
@@ -109,6 +109,7 @@
     if((TTY_Tx_Buffer.nbytes  < TTY_BUFSIZE-2) ||
        (TTY_Tx_Buffer.nbytes  < TTY_BUFSIZE && (data == '\r' || data == '\n')))
     rb_put(&TTY_Tx_Buffer, data);
+ // what if buffer is full? better send and wait?
   }
 #endif
 
@@ -208,41 +209,101 @@
 }
 
 void
-display_udec(uint16_t d, int8_t pad, uint8_t padc)
+display_udec(uint16_t d, uint8_t pad, uint8_t padc)
 {
+  pad += 128;
+
   char buf[6];
-  int8_t i=6;
+  uint8_t i=5;
 
-  buf[--i] = 0;
+  buf[i] = 0;
   do {
-    buf[--i] = d%10 + '0';
+    buf[--i] = (d%10) + '0';
     d /= 10;
     pad--;
   } while(d && i);
 
-  while(--pad >= 0 && i > 0)
+  while(((--pad) >= 128) && (i > 0))
+    buf[--i] = padc;
+
+  DS(buf+i);
+}
+
+void
+display_hex(uint16_t h, uint8_t pad, uint8_t padc)
+{
+  pad += 128;
+
+  char buf[5];
+  int8_t i=4;
+
+  buf[i] = 0;
+  do {
+    uint8_t m = ((uint8_t)h & 0x0f);
+    buf[--i] = TO_HEX( m );
+    h >>= 4;
+    pad--;
+  } while(h);
+
+  while((i > 0) && ((--pad) >= 128))
     buf[--i] = padc;
+
   DS(buf+i);
 }
 
+/*
+void
+display_hex(uint16_t h, uint8_t pad, uint8_t padc)
+{
+  char buf[(2*sizeof(uint16_t))+1];
+  char *b = buf;
+
+  uint8_t p = sizeof(uint16_t);
+
+  while (p) {
+    *(b++) = TO_HEX( *((uint8_t *)&h + (--p)) >> 4 );
+    *(b++) = TO_HEX( *((uint8_t *)&h + p) & 0x0f );
+  }
+  *b = 0;
+
+  //if (!pad) pad++; // show zero at least
+  uint8_t padstart = (2*sizeof(uint16_t)) - pad;
+  p = 0;
+  b = buf;
+
+  while ((*b == '0') && *(b+1)) // show zero at least
+  {
+ *(b++) = padc;
+ if (p < padstart) p++;
+  }
+
+  DS(buf+p);
+}
+*/
+
+/*
 void
-display_hex(uint16_t h, int8_t pad, uint8_t padc)
+display_hex(uint16_t h, uint8_t pad, uint8_t padc)
 {
+  pad += 128;
+
   char buf[5];
-  int8_t i=5;
+  int8_t i=4;
 
-  buf[--i] = 0;
+  buf[i] = 0;
   do {
     uint8_t m = h%16;
-    buf[--i] = (m < 10 ? '0'+m : 'A'+m-10);
+    buf[--i] = (m < 10 ? '0'+m : ('A'-10)+m);
     h /= 16;
     pad--;
   } while(h);
 
-  while(--pad >= 0 && i > 0)
+  while(--pad >= 128 && i > 0)
     buf[--i] = padc;
+
   DS(buf+i);
 }
+*/
 
 void
 display_hex2(uint8_t h)
--- clib/display.h Mon Dec 10 13:21:50 2012
+++ clib/display.h Fri May 30 23:04:26 2014
@@ -8,8 +8,8 @@
 void display_char(char s);
 void display_string(char *s);
 void display_string_P(const char *s);
-void display_udec(uint16_t d, int8_t pad, uint8_t padc);
-void display_hex(uint16_t h, int8_t pad, uint8_t padc);
+void display_udec(uint16_t d, uint8_t pad, uint8_t padc);
+void display_hex(uint16_t h, uint8_t pad, uint8_t padc);
 void display_hex2(uint8_t h);
 void display_nl(void);
 
@@ -20,6 +20,7 @@
 #define DH(a,b) display_hex(a,b,'0')
 #define DH2(a) display_hex2(a)
 #define DNL display_nl
+#define TO_HEX(a) ((a)<10?(a)+'0':(a)+('A'-10))
 
 extern uint8_t display_channel;
 extern uint8_t log_enabled;
--- clib/fncollection.c Mon Sep 23 21:41:10 2013
+++ clib/fncollection.c Mon Jun 02 06:33:17 2014
@@ -276,24 +276,27 @@
   if(in)
     fromhex(in+1, &bl, 1);
 
-  if(bl)                     // Next reboot we'd like to jump to the bootloader.
-    ewb( EE_REQBL, 1 );      // Simply jumping to the bootloader from here
-                             // wont't work. Neither helps to shutdown USB
-                             // first.
+  if(bl) // Next reboot we'd like to jump to the bootloader.
+    ewb( EE_REQBL, 1 ); // Simply jumping to the bootloader from here
+ // wont't work. Neither helps to shutdown USB
+ // first.
                             
 #ifdef HAS_USB
-  USB_ShutDown();            // ??? Needed?
+  USB_ShutDown(); // ??? Needed?
 #endif
 #ifdef HAS_FS
-  fs_sync(&fs);              // Sync the filesystem
+  fs_sync(&fs); // Sync the filesystem
 #endif
 
+#ifdef HAS_MS_TIMER3
+  TIMSK3 = 0; // ??? Needed?
+#endif
 
-  TIMSK0 = 0;                // Disable the clock which resets the watchdog
+  TIMSK0 = 0; // Disable the clock which resets the watchdog
   cli();
   
-  wdt_enable(WDTO_15MS);       // Make sure the watchdog is running
-  while (1);                 // go to bed, the wathchdog will take us to reset
+  wdt_enable(WDTO_15MS); // Make sure the watchdog is running
+  while (1); // go to bed, the wathchdog will take us to reset
 }
 
 void
--- clib/intertechno.c Wed Feb 06 00:29:54 2013
+++ clib/intertechno.c Mon Jun 09 17:07:36 2014
@@ -172,6 +172,8 @@
  LED_ON();
 
     #if defined (HAS_IRRX) || defined (HAS_IRTX) //Blockout IR_Reception for the moment
+      uint8_t sreg;
+      sreg = SREG;
       cli();
     #endif
 
@@ -244,7 +246,8 @@
    }
 
     #if defined (HAS_IRRX) || defined (HAS_IRTX) //Activate IR_Reception again
-      sei();
+      //sei();
+      SREG = sreg;
     #endif  
 
  LED_OFF();
--- clib/rf_asksin.c Thu Mar 13 22:49:42 2014
+++ clib/rf_asksin.c Mon Jun 09 17:28:15 2014
@@ -1,15 +1,43 @@
+
 #include "board.h"
-#ifdef HAS_ASKSIN
+
+#include "rf_asksin.h"
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_ASKSIN)
+#include <avr/io.h>
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0 || HAS_ASKSIN_PLL_HELPER || HAS_ASKSIN
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+//#include <avr/wdt.h>
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+#include <avr/interrupt.h>
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+#if defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_ASKSIN)
 #include <string.h>
+#endif //HAS_ASKSIN_PLL_HELPER || HAS_ASKSIN
+
+#if defined(HAS_ASKSIN)
 #include <avr/pgmspace.h>
+#endif //HAS_ASKSIN
+
+#if defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_ASKSIN)
 #include "cc1100.h"
 #include "delay.h"
+#endif //HAS_ASKSIN_PLL_HELPER || HAS_ASKSIN
+
+#if defined(HAS_ASKSIN)
 #include "rf_receive.h"
+#endif //HAS_ASKSIN
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_ASKSIN)
 #include "display.h"
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0 || HAS_ASKSIN_PLL_HELPER || HAS_ASKSIN
 
-#include "rf_asksin.h"
 
-uint8_t asksin_on = 0;
+#ifdef HAS_ASKSIN
 
 const uint8_t PROGMEM ASKSIN_CFG[] = {
      0x00, 0x07,
@@ -55,59 +83,242 @@
 };
 
 static unsigned char asksin_update_mode = 0;
-#endif
+#endif  //HAS_ASKSIN_FUP
 
-static void rf_asksin_reset_rx(void);
+uint8_t asksin_on = 0;
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+static uint8_t asksin_timestamp_mode = 0; //default no Timestamp
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+#endif //HAS_ASKSIN
+
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+volatile uint32_t rf_asksin_ms = 0; // counter for ms, incremented by Timer 3 or Timer 0 with less granularity
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+
+#ifdef HAS_ASKSIN_PLL_HELPER
+uint8_t asksin_disable_PLLNOLOCK = 0;
+#endif //HAS_ASKSIN_PLL_HELPER
+
+
+
+#if defined(HAS_MS_TIMER3)
+
+// just count ms in the interrupt Timer 3
+ISR(TIMER3_COMPA_vect, ISR_BLOCK)
+{
+ rf_asksin_ms++;
+}
+
+#endif //HAS_MS_TIMER3
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
 
 void
-rf_asksin_init(void)
+rf_asksin_get_ms_timestamp(uint32_t *ts)
 {
+ uint8_t l = SREG;
+ cli();
+ *ts = rf_asksin_ms;
+ SREG = l;
+}
 
-  EIMSK &= ~_BV(CC1100_INT);                 // disable INT - we'll poll...
-  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );   // CS as output
+void
+rf_asksin_display_ms(uint32_t *ts)
+{
+ char buf[(2*sizeof(uint32_t)+1)];
+ uint8_t i = 255;
 
-  CC1100_DEASSERT;                           // Toggle chip select signal
-  my_delay_us(30);
-  CC1100_ASSERT;
-  my_delay_us(30);
-  CC1100_DEASSERT;
-  my_delay_us(45);
+ uint8_t p = sizeof(uint32_t);
+ while(p) {
+ uint8_t m = (*((uint8_t *)ts+(--p)) >> 4);
+ buf[++i] = TO_HEX( m );
+ m = (*((uint8_t *)ts+p) & 0x0f);
+ buf[++i] = TO_HEX( m );
+ }
+ buf[++i] = 0;
+
+ DS(buf);
+}
+
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+
+#ifdef HAS_ASKSIN_PLL_HELPER
+
+uint8_t
+rf_asksin_wait_state(uint8_t state, uint8_t poll_us)
+{
+ uint8_t l;
+
+ l = 255;
+ do
+ {
+ if (cc1100_readReg( CC1100_MARCSTATE ) == state) return 0; // ok, state reached
+ my_delay_us( poll_us );
+ }
+ while (l--);
+
+ return 1; // error, state not reached
+}
 
-  ccStrobe( CC1100_SRES );                   // Send SRES command
-  my_delay_us(100);
+uint8_t
+rf_asksin_checkPLL(void)  // noansi: returns 0 on success
+{
+ uint8_t l;
+
+ // noansi: check PLL Lock and try to calibrate. Possibly restoring a saved calibration could be faster...
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata
+
+ // noansi: try to recover as no PLL Lock as described in CC1101 doc and errata
+ ccStrobe( CC1100_SIDLE );
+
+ if (!asksin_disable_PLLNOLOCK) DS_P( PSTR( "PLLNOLOCK\r\n" ) );
+
+ // noansi: wait idle state, is it needed here?
+ rf_asksin_wait_state(MARCSTATE_IDLE, 1); // give a litle bit time, normal RX to IDLE should take about 0.1us with ASK, TX to idle about 1us with ASK
+
+ ccStrobe( CC1100_SCAL ); // noansi: Try Calibration
+
+ //my_delay_ms(1); // noansi: maybe waiting gives a better calibration instead of polling the state (noise?)
+
+ // noansi: wait idle state -> calibration finished, if no idle in between is reported here as it may be possible with the state returned by command strobe
+ rf_asksin_wait_state(MARCSTATE_IDLE, 4);
+
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata
+
+ if (!asksin_disable_PLLNOLOCK) DS_P( PSTR( "PLLLOCKFAIL\r\n" ) );
+
+ return 1; // noansi: error, no PLL Lock
+}
+
+#ifdef HAS_ASKSIN_PLL_HELPER_RX
+uint8_t
+rf_asksin_toRX(void)
+{
+ uint8_t n;
 
-  // load configuration
-  for (uint8_t i = 0; i < sizeof(ASKSIN_CFG); i += 2) {
-    cc1100_writeReg( pgm_read_byte(&ASKSIN_CFG[i]),
-                     pgm_read_byte(&ASKSIN_CFG[i+1]) );
+ // noansi: set RX with check/try PLL is in Lock in RX
+ n = 2; // noansi: Try to set RX several times before giving up
+ do {
+ // enable RX
+ while ((ccStrobe( CC1100_SRX ) & CC1100_STATUS_STATE_BM) != 0x10); // noansi: Set RX until Status Byte indicates RX
+
+ if (!rf_asksin_checkPLL()) return 0; // everything ok
+
+ } while (--n);
+
+ //if (!asksin_disable_PLLNOLOCK) DS_P( PSTR( "NoRXErr\r\n" ) );
+
+ return 1;
+}
+#endif //HAS_ASKSIN_PLL_HELPER_RX
+
+#ifdef HAS_ASKSIN_PLL_HELPER_TX
+uint8_t
+rf_asksin_toTX(void)
+{
+ uint8_t n;
+
+ // noansi: set TX with check/try PLL is in Lock in TX
+ n = 2; // noansi: Try to set TX several times before giving up
+ do {
+ // enable TX, wait for CCA
+ while ((ccStrobe( CC1100_STX ) & CC1100_STATUS_STATE_BM) != 0x20); // noansi: Set TX until Status Byte indicates TX
+
+ if (!rf_asksin_checkPLL()) return 0; // everything ok
+
+ } while (--n);
+
+ //if (!asksin_disable_PLLNOLOCK) DS_P( PSTR( "NoTXErr\r\n" ) );
+
+ return 1;
+}
+#endif //HAS_ASKSIN_PLL_HELPER_TX
+
+// check if stuck in RX state without PLL Lock
+void
+rf_asksin_check_PLL_task(void)
+{
+  if (cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_RX)
+  {
+ // noansi: try init or recalibration, if stuck in RX State with no PLL Lock as seen in extended read timeout logging
+ if (cc1100_readReg( CC1100_FSCAL1 ) == 0x3f) { // noansi: no PLL Lock as described in CC1101 errata
+ //rf_asksin_init(); // noansi: try init to recover
+ rf_asksin_checkPLL(); // noansi: try calibration to recover
+ //ccStrobe( CC1100_SRX ); // other tasks will give the wait time to fully switch to RX in background
+    while ((ccStrobe( CC1100_SRX ) & CC1100_STATUS_STATE_BM) != 0x10); // noansi: Set RX until Status Byte indicates RX
+ }
   }
+}
+
+#endif //HAS_ASKSIN_PLL_HELPER
+
+
+
+#ifdef HAS_ASKSIN
+
+static void rf_asksin_reset_rx(void);
+
+
+void
+rf_asksin_init(void)
+{
+ EIMSK &= ~_BV(CC1100_INT);                 // disable INT - we'll poll...
+ SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );   // CS as output
+
+ CC1100_DEASSERT;                           // Toggle chip select signal
+ my_delay_us(30);
+ CC1100_ASSERT;
+ my_delay_us(30);
+ CC1100_DEASSERT;
+ my_delay_us(45);
+
+ ccStrobe( CC1100_SRES );                   // Send SRES command
+ my_delay_us(100);
+
+ // load configuration
+ for (uint8_t i = 0; i < sizeof(ASKSIN_CFG); i += 2) {
+ cc1100_writeReg( pgm_read_byte(&ASKSIN_CFG[i]),
+ pgm_read_byte(&ASKSIN_CFG[i+1]) );
+ }
 
 #ifdef HAS_ASKSIN_FUP
-  if (asksin_update_mode) {
-    for (uint8_t i = 0; i < sizeof(ASKSIN_UPDATE_CFG); i += 2) {
-      cc1100_writeReg( pgm_read_byte(&ASKSIN_UPDATE_CFG[i]),
-                       pgm_read_byte(&ASKSIN_UPDATE_CFG[i+1]) );
-    }
-  }
-#endif

-  ccStrobe( CC1100_SCAL );
+ if (asksin_update_mode) {
+ for (uint8_t i = 0; i < sizeof(ASKSIN_UPDATE_CFG); i += 2) {
+ cc1100_writeReg( pgm_read_byte(&ASKSIN_UPDATE_CFG[i]),
+ pgm_read_byte(&ASKSIN_UPDATE_CFG[i+1]) );
+ }
+ }
+#endif  //HAS_ASKSIN_FUP
 
-  my_delay_ms(4);
+ ccStrobe( CC1100_SCAL );  // force a calibration
 
-  // enable RX, but don't enable the interrupt
-  do {
-    ccStrobe(CC1100_SRX);
-  } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+ //my_delay_ms(4); // noansi: maybe waiting gives a better calibration instead of polling the state (noise?)
+
+
+ rf_asksin_wait_state(MARCSTATE_IDLE, 15);  // noansi: wait idle state -> calibration finished -> may be
+
+ rf_asksin_checkPLL();  // noansi: check PLL Lock
+
+ // enable RX, but don't enable the interrupt
+ rf_asksin_toRX();  // noansi: and check PLL is in Lock in RX
 }
 
+
 static void
 rf_asksin_reset_rx(void)
 {
-  ccStrobe( CC1100_SFRX  );
-  ccStrobe( CC1100_SIDLE );
-  ccStrobe( CC1100_SNOP  );
-  ccStrobe( CC1100_SRX   );
+ ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
+ ccStrobe( CC1100_SNOP ); // give a litle bit time, normal RX to IDLE should take about 0.1us with ASK, TX to idle about 1us with ASK
+ ccStrobe( CC1100_SFRX  ); // flush RX-FIFO
+ rf_asksin_toRX(); // noansi: try to set RX with calibration
+ //DS_P( PSTR( "asksin_reset\r\n" ) );
 }
 
 void
@@ -143,9 +354,17 @@
 
     CC1100_DEASSERT;
 
-    do {
-      ccStrobe(CC1100_SRX);
-    } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+    // switch to RX again
+    //rf_asksin_toRX();  // takes just a little bit longer, if still in PLL lock
+    while ((ccStrobe( CC1100_SRX ) & CC1100_STATUS_STATE_BM) != 0x10); // noansi: Set RX until Status Byte indicates RX
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+
+    // get timestamp from ms timer
+    uint32_t ts;
+    rf_asksin_get_ms_timestamp(&ts);
+
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
 
     last_enc = msg[1];
     msg[1] = (~msg[1]) ^ 0x89;
@@ -160,32 +379,90 @@
     
     if (tx_report & REP_BINTIME) {
       
-      DC('a');
+      DC( 'a' );
       for (uint8_t i=0; i<=msg[0]; i++)
       DC( msg[i] );
         
     } else {
-      DC('A');
-     
+
+      DC( 'A' ); //Asksin Format ID
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+
+ if (asksin_timestamp_mode)
+ {
+ DH( 0xff01, 4 );  // TimeStamp Format ID FF01
+ rf_asksin_display_ms(&ts);
+ }
+
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
       for (uint8_t i=0; i<=msg[0]; i++)
         DH2( msg[i] );
       
       if (tx_report & REP_RSSI)
-        DH2(rssi);
-     
-      DNL();
+        DH2( rssi );
+
+      DNL( );
     }
   }
 
+  l = cc1100_readReg( CC1100_MARCSTATE );
+/*
+  if (l == MARCSTATE_RX)
+  {
+ // noansi: try init or recalibration, if stuck in RX State with no PLL Lock as seen in extended read timeout logging
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l == 0x3f) { // noansi: no PLL Lock as described in CC1101 errata
+ //rf_asksin_init(); // noansi: try init to recover
+ rf_asksin_checkPLL(); // noansi: try calibration to recover
+ ccStrobe( CC1100_SRX ); // other tasks will give the wait time to fully switch to RX in background
+ return;
+ }
+  }
+  else if (l == MARCSTATE_RXFIFO_OVERFLOW)
+*/
+  if (l == MARCSTATE_RXFIFO_OVERFLOW)
+  {
+ ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
+ ccStrobe( CC1100_SNOP  ); // give a litle bit time, normal RX to IDLE should take about 0.1us with ASK
+ ccStrobe( CC1100_SFRX  ); // flush the RX-FIFO
+ ccStrobe( CC1100_SRX   ); // other tasks will give the wait time to fully switch to RX in background
+  }
+  else
+  {
+ if (l != MARCSTATE_RX)
+ {
+ // we allways try to be on RX
+ //rf_asksin_toRX(); // noansi: try to set RX with calibration, would wait for state
+ ccStrobe( CC1100_SRX ); // other tasks will give the wait time to fully switch to RX in background
+ }
+  }
+
+/*
   switch(cc1100_readReg( CC1100_MARCSTATE )) {
+    case MARCSTATE_RX:
+ // noansi: try init or recalibration, if stuck in RX State with no PLL Lock as seen in extended read timeout logging
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l == 0x3f) { // noansi: no PLL Lock as described in CC1101 errata
+ //rf_asksin_init(); // noansi: try init to recover
+ rf_asksin_checkPLL(); // noansi: try calibration to recover
+ ccStrobe( CC1100_SRX ); // other tasks will give the wait time to fully switch to RX in background
+ return;
+ }
+ break;
     case MARCSTATE_RXFIFO_OVERFLOW:
-      ccStrobe( CC1100_SFRX  );
-    case MARCSTATE_IDLE:
-      ccStrobe( CC1100_SIDLE );
-      ccStrobe( CC1100_SNOP  );
-      ccStrobe( CC1100_SRX   );
-      break;
+ ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
+ ccStrobe( CC1100_SNOP  ); // give a litle bit time, normal RX to IDLE should take about 0.1us with ASK
+ ccStrobe( CC1100_SFRX  );
+    //case MARCSTATE_IDLE:
+    default:
+ // we allways try to be on RX
+ //rf_asksin_toRX(); // noansi: try to set RX with calibration, would wait for state
+ ccStrobe( CC1100_SRX ); // other tasks will give the wait time to fully switch to RX in background
+ break;
   }
+*/
 }
 
 void
@@ -195,17 +472,18 @@
   uint8_t ctl;
   uint8_t l;
 
-  uint8_t hblen = fromhex(in+1, msg, MAX_ASKSIN_MSG-1);
+  uint8_t hblen = fromhex(in, msg, MAX_ASKSIN_MSG-1);
 
   if ((hblen-1) != msg[0]) {
-//  DS_P(PSTR("LENERR\r\n"));
+//  DS_P( PSTR( "LENERR\r\n" ) );
     return;
   }
 
   // in AskSin mode already?
   if(!asksin_on) {
     rf_asksin_init();
-    my_delay_ms(3);             // 3ms: Found by trial and error
+    //my_delay_ms(3); // 3ms: Found by trial and error. noansi: We are in RX after init, why wait?
+    my_delay_ms(6); // noansi: removed wait 4ms in init during calib (735us so about 1ms), so 1(calib)+3+3ms should do the same
   }
 
   ctl = msg[2];
@@ -218,10 +496,9 @@
   
   msg[l] = msg[l] ^ ctl;
 
-  // enable TX, wait for CCA
-  do {
-    ccStrobe(CC1100_STX);
-  } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_TX);
+  // noansi: set TX
+  //rf_asksin_toTX();  // takes just a little bit longer, if still in PLL lock
+  while ((ccStrobe( CC1100_STX ) & CC1100_STATUS_STATE_BM) != 0x20); // noansi: Set TX until Status Byte indicates TX
 
   if (ctl & (1 << 4)) { // BURST-bit set?
     // According to ELV, devices get activated every 300ms, so send burst for 360ms
@@ -233,7 +510,7 @@
 
   // send
   CC1100_ASSERT;
-  cc1100_sendbyte(CC1100_WRITE_BURST | CC1100_TXFIFO);
+  cc1100_sendbyte( CC1100_WRITE_BURST | CC1100_TXFIFO );
 
   for(uint8_t i = 0; i < hblen; i++) {
     cc1100_sendbyte(msg[i]);
@@ -242,47 +519,106 @@
   CC1100_DEASSERT;
 
   // wait for TX to finish
-  while(cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_TX)
-    ;
+  while (((l = ccStrobe( CC1100_SNOP )) & CC1100_STATUS_STATE_BM) == 0x20); // Status Byte indicates still TX ?
 
-  if (cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_TXFIFO_UNDERFLOW) {
-      ccStrobe( CC1100_SFTX  );
-      ccStrobe( CC1100_SIDLE );
-      ccStrobe( CC1100_SNOP  );
-  }
+  // MARCSTATE_TXFIFO_UNDERFLOW ?
+  if (l == 0x70) { // Status Byte indicates TXFIFO_UNDERFLOW
+    ccStrobe( CC1100_SFTX  ); // flush the TX-FIFO
+    // ccStrobe( CC1100_SIDLE ); // why force idle? SFTX should end in idle with respect to cc1101 documentation
+    ccStrobe( CC1100_SNOP  ); // but give a litle bit time, normal TX to IDLE should take about 1us with ASK
+ }
   
   if(asksin_on) {
-    do {
-      ccStrobe(CC1100_SRX);
-    } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+    // noansi: set RX
+    //rf_asksin_toRX();  // takes just a little bit longer, if still in PLL lock
+    while ((ccStrobe( CC1100_SRX ) & CC1100_STATUS_STATE_BM) != 0x10); // noansi: Set RX until Status Byte indicates RX
   } else {
     set_txrestore();
   }
 }
 
+
 void
 asksin_func(char *in)
 {
-#ifndef HAS_ASKSIN_FUP
-  if(in[1] == 'r') {                // Reception on
-#else
-  if((in[1] == 'r') || (in[1] == 'R')) {                // Reception on
-    if (in[1] == 'R') {
-      asksin_update_mode = 1;
-    } else {
-      asksin_update_mode = 0;
-    }
-#endif
-    rf_asksin_init();
-    asksin_on = 1;
+ uint8_t asksin_command = in[1];
 
-  } else if(in[1] == 's') {         // Send
-    asksin_send(in+1);
+ if (asksin_command == 's') { // Send
+ asksin_send(in+2);
+ }
 
-  } else {                          // Off
-    asksin_on = 0;
+#ifndef HAS_ASKSIN_FUP
else if (asksin_command == 'r') { // Reception on
+#else  //HAS_ASKSIN_FUP
else if ((asksin_command == 'r') || (asksin_command == 'R')) { // Reception on
+ asksin_update_mode = asksin_command - 'r'; //'r'=off, 'R'=on for asksin_update_mode
+#endif  //HAS_ASKSIN_FUP
+ rf_asksin_init();
+ asksin_on = 1;
+
+ }
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+ else if (asksin_command == 'p') { // ping Timestamp echo + PingNo 32bit
+ // we do nothing (except a little error hint), if we don't have TimeStamp, so no urgend need for Hardware Detection
+ if (asksin_timestamp_mode)
+ {
+ // get timestamp from ms timer
+ uint32_t ts;
+ rf_asksin_get_ms_timestamp(&ts);
+
+ // send timestamp Answer
+ DC( 'A' ); // Asksin message ID; 1 characters
+ DH( 0xff02, 4 ); // TimeStamp Format ID FF02 for ping answer; 4 characters
+ rf_asksin_display_ms(&ts); // TimeStamp; 8 characters
+ DH2( strlen(in+2)>>1 ); // lenght of input hex bytes to send back; 2 characters
+ DS( in+2 ); // Message contains e.g. received ping number; 8 characters at least for 00_CUL
+ DH2( 128 ); // rssi = -138; 2 characters
+ DNL( );
+ }
+ #ifndef HAS_ASKSIN_NO_COMMAND_ERROR_HINT
+ else goto unknown_ASKSIN; // little error hint, as TimeStamp mode not enabled
+ #endif //HAS_ASKSIN_NO_COMMAND_ERROR_HINT
}
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
else if (asksin_command == 't') {          // Timestamp, t1=on, t0=off
+ // we do nothing (except a little error hint), if we don't have TimeStamp, so no urgend need for Hardware Detection
+ asksin_timestamp_mode = in[2] - '0'; // 0=deactivate timestamp from ms timer, else on
+
+ }
+#endif //HAS_MS_TIMER3 || HAS_MS_TIMER0
+
+#ifdef HAS_ASKSIN_PLL_HELPER
else if (asksin_command == 'P') {
+ asksin_disable_PLLNOLOCK = in[2] - '0'; //switch on/off PLLNOLOCK message, '0'=switch on, default on
+
+ }
+#endif //HAS_ASKSIN_PLL_HELPER
+
else if (asksin_command == 'x') { // only x should disable AskSin mode, see doc
+ asksin_on = 0; // AskSin Reception off
+
+ }
+
+// else {
+// asksin_on = 0; // AskSin Reception off, if unknown command
+// }
+
+#ifndef HAS_ASKSIN_NO_COMMAND_ERROR_HINT
+ else goto unknown_ASKSIN;
+#endif //HAS_ASKSIN_NO_COMMAND_ERROR_HINT
+
+ return;
+
+
+#ifndef HAS_ASKSIN_NO_COMMAND_ERROR_HINT
+unknown_ASKSIN:
+ DS_P( PSTR( "A?\r\n" ) ); // little error hint
 
-  }
+ return;
+#endif //HAS_ASKSIN_NO_COMMAND_ERROR_HINT
 }
 
-#endif
+#endif //HAS_ASKSIN
--- clib/rf_asksin.h Thu Mar 13 22:49:42 2014
+++ clib/rf_asksin.h Sun Jun 08 17:00:01 2014
@@ -1,6 +1,24 @@
 #ifndef _RF_ASKSIN_H
 #define _RF_ASKSIN_H
 
+#include <avr/io.h>
+
+
+#if defined(HAS_MS_TIMER3) || defined(HAS_MS_TIMER0)
+
+extern volatile uint32_t rf_asksin_ms; // noansi: counter for ms, incremented by Timer 3 or Timer 0 with less granularity
+
+extern void rf_asksin_get_ms_timestamp(uint32_t *ts); // noansi: get ms counter interrupt save
+extern void rf_asksin_display_ms(uint32_t *ts); // noansi: display as 8 digit Hex Value
+
+#endif
+
+
+#ifdef HAS_ASKSIN
+
+#define HAS_ASKSIN_PLL_HELPER
+#define HAS_ASKSIN_PLL_HELPER_RX
+
 #ifndef HAS_ASKSIN_FUP
 #define MAX_ASKSIN_MSG 30
 #else
@@ -9,8 +27,36 @@
 
 extern uint8_t asksin_on;
 
-void rf_asksin_init(void);
-void rf_asksin_task(void);
-void asksin_func(char *in);
+extern void rf_asksin_init(void);
+extern void rf_asksin_task(void);
+extern void asksin_func(char *in);
+
+#endif
+
+
+#if defined(HAS_ASKSIN_PLL_HELPER_TX) || defined(HAS_ASKSIN_PLL_HELPER_RX)
+#define HAS_ASKSIN_PLL_HELPER
+#endif
+
+
+#ifdef HAS_ASKSIN_PLL_HELPER
+
+extern uint8_t asksin_disable_PLLNOLOCK; // noansi: do not display PLLNOLOCK related errors if > 0
+
+extern uint8_t rf_asksin_wait_state(uint8_t state, uint8_t poll_us); // noansi: wait for a MARCSTATE to be reached for 256*poll_us, returns 0 on success
+extern uint8_t rf_asksin_checkPLL(void); // noansi: check CC1101 PLL lock with recalibration if necessary, returns 0 on success
+
+#ifdef HAS_ASKSIN_PLL_HELPER_RX
+extern uint8_t rf_asksin_toRX(void); // noansi: set CC1101 to RX with recalibration if necessary, returns 0 on success
+#endif
+
+#ifdef HAS_ASKSIN_PLL_HELPER_TX
+extern uint8_t rf_asksin_toTX(void); // noansi: set CC1101 to TX with recalibration if necessary, returns 0 on success
+#endif
+
+extern void rf_asksin_check_PLL_task(void); // noansi: check for PLL Lock and try recalibration, if not
+
+#endif
+
 
 #endif
--- clib/rf_send.c Sat Mar 29 07:17:22 2014
+++ clib/rf_send.c Mon Jun 09 17:11:46 2014
@@ -102,7 +102,9 @@
   LED_ON();
 
   #if defined (HAS_IRRX) || defined (HAS_IRTX) //Blockout IR_Reception for the moment
-    cli();
+  uint8_t sreg;
+  sreg = SREG;
+  cli();
   #endif
 
 #ifdef HAS_MORITZ
@@ -141,7 +143,8 @@
   }
 
   #if defined (HAS_IRRX) || defined (HAS_IRTX) //Activate IR_Reception again
-    sei();
+  //sei();
+  SREG = sreg;
   #endif
 
 #ifdef HAS_MORITZ
--- clib/ringbuffer.c Wed Mar 05 10:03:10 2014
+++ clib/ringbuffer.c Mon Jun 09 02:05:04 2014
@@ -23,28 +23,28 @@
     SREG = sreg;
     return;
   }
-  rb->nbytes++;
   rb->buf[rb->putoff++] = data;
   if(rb->putoff == TTY_BUFSIZE)
     rb->putoff = 0;
+  rb->nbytes++;
   SREG = sreg;
 }
 
 uint8_t
 rb_get(rb_t *rb)
 {
-  uint8_t sreg;
   uint8_t ret;
+  uint8_t sreg;
   sreg = SREG;
   cli();
   if(rb->nbytes == 0) {
     SREG = sreg;
     return 0;
   }
-  rb->nbytes--;
   ret = rb->buf[rb->getoff++];
   if(rb->getoff == TTY_BUFSIZE)
     rb->getoff = 0;
+  rb->nbytes--;
   SREG = sreg;
   return ret;
 }
--- CHANGED Tue Jun 03 17:07:38 2014
+++ CHANGED Mon Jun 09 17:23:56 2014
@@ -1,5 +1,25 @@
-- rpiaddon: initial version for Raspberry PI addon board by Damian Nelson
-
+Version 1.62 (2014-06-08)
+- stability improvements in CDC_Task (reentrance due to interrupt). by noansi
+- unknown or currently unusable AskSin command (Axx) gives little Error Feedback A?\r\n . by noansi
+- disable AskSin with Ax only, as written in doc. by noansi
+Version 1.61 (2014-06-08)
+- check of PLL lock problem generaly implemented as task (so usable for all RF modes with RX), can be configured as board option. by noansi
+- TimeStamp ms counter as configurable board option implemented, so usable with other code, too. by noansi
+- usage of Timer0 only for ms TimeStamp option, runs more stable than Timer3 (?), but only 4ms (8ms IR) increment, restored buffsizes to old value. by noansi
+Version 1.60 (2014-06-07)
+- Version number 1.60 and above needed for 00_CUL.pm to support AskSin TimeStamp mode. by noansi
+- COC: makefile changed, name COC.radio_only -> COC_radio_only. by noansi
+- COC: AskSin support of ms TimeStamp mode. 1ms increment (Timer 3). by noansi
+- CUL: AskSin support of ms TimeStamp mode. CUL_V2_HM 4ms increment (Timer 0), CUL_V4 4ms increment (Timer 0). by noansi
+- CUL: AskSin support of ms TimeStamp mode. CUL_V3 1ms increment (Timer 3). by noansi
+- all: board option HAS_ASKSIN_PLL_HELPER, HAS_ASKSIN_PLL_HELPER_TX for RX TX switching routines with PLL lock check for usage in other modules. by noansi
+- all: board option HAS_MS_TIMER0, HAS_MS_TIMER3 for ms TimeStamp support in AskSin. May be used separately in other modules, too. HAS_MS_TIMER3 with 1ms increment. HAS_MS_TIMER0 with 4ms increment without HAS_IRTX or HAS_IRRX, 8ms increment with. by noansi
+- clock.c: ms TimeStamp in Timer 0 interrupt routine. by noansi
+- AskSin: Timer 3 interrupt routine for 1ms TimeStamp support. by noansi
+- AskSin: ms TimeStamp mode support. Activate with At1 (messages AFF01ttttttttllmm*rr), deactivate with At0. Ping with Apaa* (answer AFF02ttttttttllaa*rr with rr=-138), only usable if TimeStamp mode is enabled. by noansi
+- AskSin: changes in to RX and to TX switching. by noansi
+- AskSin: robustness of AskSin-mode against missing PLL lock with recalibration. Display of respective error message. Disable messages with AP1, reenable with AP0. by noansi
+- display.c: definition and routines for HEX conversion changed. Saves some bytes in program memory. by noansi
 - SCC: inital addition of new RPi extension
 - UNIROLL send routines (currently CUL only) by C_Herrmann
 
--- version.h Fri Mar 14 19:57:58 2014
+++ version.h Mon Jun 09 16:08:00 2014
@@ -1,3 +1,3 @@
 #define VERSION_1               1
-#define VERSION_2               58
-#define VERSION                 "1.58"
+#define VERSION_2               62
+#define VERSION                 "1.62"

Gruß und Danke,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil2
Beitrag von: noansi am 09 Juni 2014, 19:17:10
und der zweite Teil:

--- Devices/AirLinked/board.h.CSM Fri Feb 01 11:07:16 2013
+++ Devices/AirLinked/board.h.CSM Sun Jun 08 19:57:59 2014
@@ -60,10 +60,14 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_RF_ROUTER
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_INTERTECHNO
 
 #define BOARD_ID_STR            "CSM868"
+//#define CUL_HW_REVISION "CSM"
 
 #define TTY_BUFSIZE             132
 
--- Devices/AirLinked/board.h.HM-LC-Sw1-PI Fri Feb 01 11:07:16 2013
+++ Devices/AirLinked/board.h.HM-LC-Sw1-PI Sun Jun 08 19:58:07 2014
@@ -73,10 +73,14 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_RF_ROUTER
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_INTERTECHNO
 
 #define BOARD_ID_STR            "CSM868"
+//#define CUL_HW_REVISION "HM-LC-Sw1-PI"
 
 #define TTY_BUFSIZE             132
 
--- Devices/AirLinked/board.h.RWE_PSS Fri Feb 01 11:07:16 2013
+++ Devices/AirLinked/board.h.RWE_PSS Sun Jun 08 19:57:11 2014
@@ -55,10 +55,14 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_RF_ROUTER
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_INTERTECHNO
 
 #define BOARD_ID_STR            "CSM868"
+//#define CUL_HW_REVISION "RWE_PSS"
 
 #define TTY_BUFSIZE             132
 
--- Devices/AirLinked/board.h.zCSM Mon Jul 01 12:05:26 2013
+++ Devices/AirLinked/board.h.zCSM Sun Jun 08 19:56:30 2014
@@ -66,10 +66,14 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_RF_ROUTER
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_INTERTECHNO
 
 #define BOARD_ID_STR            "CSM868"
+//#define CUL_HW_REVISION "zCSM"
 
 #define TTY_BUFSIZE             132
 
--- Devices/AirLinked/culfw.c Fri Jul 05 13:03:32 2013
+++ Devices/AirLinked/culfw.c Sun Jun 08 19:54:29 2014
@@ -36,7 +36,7 @@
 #include "intertechno.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -134,12 +134,16 @@
 //  }
 
   // Setup the timers. Are needed for watchdog-reset
-#if defined (HAS_IRRX) || defined (HAS_IRTX)
+#ifdef HAS_IRRX
   ir_init();
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -148,6 +152,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -202,6 +216,9 @@
 #endif
 #if defined (HAS_IRRX) || defined (HAS_IRTX)
     ir_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
 
 }
--- Devices/CCD/board.h Mon Mar 17 14:45:54 2014
+++ Devices/CCD/board.h Sun Jun 08 20:00:47 2014
@@ -51,6 +51,9 @@
 #define HAS_RAWSEND                   //
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_MORITZ
 #define HAS_ESA
 #define HAS_TX3
@@ -64,6 +67,9 @@
 #define BUSWARE_CSM
 #define BUSWARE_CCD
 #define RPI_TTY_FIX
+
+//#define CUL_HW_REVISION "CCD"
+
 
 #endif
 
--- Devices/CCD/CCD.c Sun Oct 06 21:08:48 2013
+++ Devices/CCD/CCD.c Sun Jun 08 20:02:11 2014
@@ -35,7 +35,7 @@
 #include "i2cmaster.h"
 #include "ds1339.h"
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -132,7 +132,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -141,6 +145,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
   wdt_enable(WDTO_2S);
@@ -185,6 +199,9 @@
 #endif
 #ifdef HAS_MORITZ
     rf_moritz_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
   }
 
--- Devices/COC/board.h Mon Mar 17 14:45:54 2014
+++ Devices/COC/board.h Sun Jun 08 16:30:54 2014
@@ -45,13 +45,17 @@
 #define HAS_RF_ROUTER                 // PROGMEM: 1248b  RAM: 44b
 
 #define FHTBUF_SIZE          174      //                 RAM: 174b
+//#define FHTBUF_SIZE          168      //                 RAM: 174b -6
 #define RCV_BUCKETS            4      //                 RAM: 25b * bucket
 #define RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
 #define FULL_CC1100_PA                // PROGMEM:  108b
 #define HAS_RAWSEND                   //
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
+#define HAS_ASKSIN_PLL_HELPER // noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ASKSIN
 #define HAS_ASKSIN_FUP
+//#define HAS_MS_TIMER3 // RAM: +5b Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms increment
 #define HAS_MORITZ
 #define HAS_ESA
 #define HAS_TX3
--- Devices/COC/COC.c Fri Mar 14 19:57:58 2014
+++ Devices/COC/COC.c Sun Jun 08 16:52:06 2014
@@ -35,7 +35,7 @@
 #include "i2cmaster.h"
 #include "ds1339.h"
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -133,7 +133,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -142,6 +146,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
   wdt_enable(WDTO_2S);
@@ -186,6 +200,9 @@
 #endif
 #ifdef HAS_MORITZ
     rf_moritz_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
   }
 
--- Devices/COC/makefile Tue Jun 25 08:38:20 2013
+++ Devices/COC/makefile Sat Jun 07 15:52:46 2014
@@ -100,7 +100,7 @@
 
 all:
  make TARGET=COC COCVERS=FULL mostly_clean build size
- make TARGET=COC.radio_only COCVERS=RADIO_ONLY mostly_clean build size
+ make TARGET=COC_radio_only COCVERS=RADIO_ONLY mostly_clean build size
 
 build: elf hex eep lss sym
 
@@ -125,7 +125,7 @@
 program_full: COCVERS=FULL
 program_full: do_program
 
-program_radio_only: TARGET=COC.radio_only
+program_radio_only: TARGET=COC_radio_only
 program_radio_only: COCVERS=RADIO_ONLY
 program_radio_only: do_program
 
--- Devices/CSM/board.h Fri Mar 14 19:57:58 2014
+++ Devices/CSM/board.h Sun Jun 08 20:11:17 2014
@@ -64,6 +64,9 @@
 #define HAS_RF_ROUTER                 // PROGMEM:  920b  RAM: 38b
 #define HAS_ASKSIN
 #define HAS_ASKSIN_FUP
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_MORITZ
 #define HAS_ESA
 #define HAS_INTERTECHNO
@@ -142,6 +145,26 @@
 
 #define BOARD_ID_STR            "CSM868"
 #define BOARD_ID_STR433         "CSM433"
+
+#ifdef CSMV2
+//#define CUL_HW_REVISION "CSM_V2"
+#endif
+
+#ifdef CSMV3
+//#define CUL_HW_REVISION "CSM_V3"
+#endif
+
+#ifdef CSMV4
+//#define CUL_HW_REVISION "CSM_V4"
+#endif
+
+#ifdef TUXRAIL
+//#define CUL_HW_REVISION "TUXRAIL"
+#endif
+
+#ifdef TUXRADIO
+//#define CUL_HW_REVISION "TUXRADIO"
+#endif
 
 #define HAS_UART                1
 #define UART_BAUD_RATE          38400
--- Devices/CSM/CSM.c Fri Mar 14 19:57:58 2014
+++ Devices/CSM/CSM.c Sun Jun 08 20:13:52 2014
@@ -36,7 +36,7 @@
 #include "intertechno.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -149,7 +149,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -158,6 +162,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -206,6 +220,9 @@
 #endif
 #ifdef HAS_IRRX
     ir_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
   }
 
--- Devices/CUL/board.h Fri Apr 18 20:06:04 2014
+++ Devices/CUL/board.h Mon Jun 09 15:46:40 2014
@@ -15,16 +15,18 @@
 #define HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
 #define HAS_FHT_8v                      // PROGMEM:  586b  RAM: 23b
 #define HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 
 #if defined(CUL_V3) || defined(CUL_V4)
 #  define FHTBUF_SIZE          174      //                 RAM: 174b
+//#  define FHTBUF_SIZE          168      //                 RAM: 174b -6
 #  define RCV_BUCKETS            4      //                 RAM: 25b * bucket
 #  define RFR_DEBUG                     // PROGMEM:  354b  RAM: 14b
 #  define FULL_CC1100_PA                // PROGMEM:  108b
 #  define HAS_RAWSEND                   //
 #  define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
-#  define HAS_ASKSIN
-#  define HAS_ASKSIN_FUP
+#  define HAS_ASKSIN //                 RAM:  1b +1b
+#  define HAS_ASKSIN_FUP //                 RAM:  1b
 #  define HAS_MORITZ
 #  define HAS_RWE
 #  define HAS_ESA
@@ -36,11 +38,15 @@
 #endif
 
 #if defined(CUL_V4)
+#  define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms increment
 #  define TTY_BUFSIZE           64      // RAM: TTY_BUFSIZE*4
 #endif
 
 #if defined(CUL_V3)
+//#  define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#  define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms increment
 #  define TTY_BUFSIZE          128      // RAM: TTY_BUFSIZE*4
+//#  define TTY_BUFSIZE          152     // RAM: TTY_BUFSIZE*4
 #endif
 
 
@@ -53,12 +59,15 @@
 #  define HAS_TX3
 #  define HAS_HOERMANN
 #  undef  HAS_FHT_8v
+#  undef  HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not. Not enough free Flash
 #endif
 
 #ifdef CUL_V2_HM
 #  define CUL_V2
 #  define HAS_ASKSIN
+#  define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms resolution
 #  define TTY_BUFSIZE           64
+//#  define TTY_BUFSIZE           62 // RAM: -8b
 #  define RCV_BUCKETS            2
 #  undef  HAS_RF_ROUTER
 #  undef  HAS_FHT_80b
@@ -90,6 +99,7 @@
 // No features to define below
 
 #include <avr/io.h>
+
 #include <avr/power.h>
 
 #if !defined(clock_prescale_set) && __AVR_LIBC_VERSION__  < 10701UL
--- Devices/CUL/CUL.c Sat Mar 29 07:17:22 2014
+++ Devices/CUL/CUL.c Sun Jun 08 16:51:26 2014
@@ -3,11 +3,16 @@
    Inpired by the MyUSB USBtoSerial demo, Copyright (C) Dean Camera, 2008.
 */
 
+#include <avr/io.h>
+
 #include <avr/boot.h>
 #include <avr/power.h>
 #include <avr/eeprom.h>
 #include <avr/interrupt.h>
-#include <avr/io.h>
+
+//#include <avr/io.h>
+
+
 #include <avr/pgmspace.h>
 #include <avr/wdt.h>
 
@@ -34,7 +39,7 @@
 #ifdef HAS_MEMFN
 #include "memory.h" // getfreemem
 #endif
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 #ifdef HAS_MORITZ
@@ -132,13 +137,33 @@
 
 
   // Setup the timers. Are needed for watchdog-reset
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250
+#ifdef HAS_IRRX
+  ir_init();
+  // IR uses highspeed TIMER0 for sampling
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
   TCCR0B = _BV(CS02);       
   TCCR0A = _BV(WGM01);
   TIMSK0 = _BV(OCIE0A);
 
   TCCR1A = 0;
-  TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
+  TCCR1B = _BV(CS11) | _BV(WGM12); // Timer1: 1us = 8MHz/8
+
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
 
@@ -178,5 +203,9 @@
 #ifdef HAS_RWE
     rf_rwe_task();
 #endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
+#endif
+
   }
 }
--- Devices/CUN/board.h Wed Jul 11 15:19:20 2012
+++ Devices/CUN/board.h Sat Jun 07 17:21:32 2014
@@ -102,6 +102,8 @@
 #define HAS_RAWSEND                     // PROGMEM:  198b     RAM:  4b
 #define HAS_FASTRF                      // PROGMEM:  362+106  RAM:  1b
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER0 // noansi: Timer0 for ms timestamp counter in asksin.c, 4ms resolution
+//#define HAS_MS_TIMER3 // noansi: Timer3 for ms timestamp counter in asksin.c, only if supported by CPU
 #define HAS_ESA
 #define HAS_TX3
 #define HAS_INTERTECHNO
--- Devices/CUN/CUN.c Tue Nov 27 22:12:52 2012
+++ Devices/CUN/CUN.c Sat Jun 07 18:06:15 2014
@@ -153,13 +153,33 @@
   while(tx_report);                     // reboot if the bss is not initialized
 
   // Setup the timers. Are needed for watchdog-reset
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250
+#ifdef HAS_IRRX
+  ir_init();
+  // IR uses highspeed TIMER0 for sampling
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
   TCCR0B = _BV(CS02);       
   TCCR0A = _BV(WGM01);
   TIMSK0 = _BV(OCIE0A);
 
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
+
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
 
--- Devices/CUNO/board.h Fri Mar 14 19:57:58 2014
+++ Devices/CUNO/board.h Sun Jun 08 20:20:07 2014
@@ -69,6 +69,9 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
 #define HAS_ASKSIN_FUP
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_TX3
 #define HAS_INTERTECHNO
@@ -80,6 +83,7 @@
 
 #define BOARD_ID_STR            "CUNO868"
 #define BOARD_ID_STR433         "CUNO433"
+//#define CUL_HW_REVISION "CUNO"
 
 #define HAS_UART                1
 #define UART_BAUD_RATE          38400
--- Devices/CUNO/CUNO.c Tue Nov 27 22:12:52 2012
+++ Devices/CUNO/CUNO.c Sun Jun 08 20:21:50 2014
@@ -37,7 +37,7 @@
 
 #include "i2cmaster.h"
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -147,7 +147,17 @@
 
   // Setup the timers. Are needed for watchdog-reset
 
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#ifdef HAS_IRRX
+  ir_init();
+  // IR uses highspeed TIMER0 for sampling
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
   TIMSK0 = _BV(OCIE0A);
@@ -155,6 +165,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -196,6 +216,9 @@
 #endif
 #ifdef HAS_ETHERNET
     Ethernet_Task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
   }
 
--- Devices/CUNO2/board.h Fri Mar 14 19:57:58 2014
+++ Devices/CUNO2/board.h Sun Jun 08 20:25:49 2014
@@ -66,6 +66,9 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
 #define HAS_ASKSIN_FUP
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_TX3
 #define HAS_INTERTECHNO
@@ -138,6 +141,8 @@
 #define TTY_BUFSIZE             1024
 
 #define BUSWARE_CUNO2
+
+//#define CUL_HW_REVISION "CUNO2"
 
 #ifndef eeprom_update_byte
 #define eeprom_update_byte eeprom_write_byte
--- Devices/CUNO2/CUNO2.c Sun Nov 03 00:01:38 2013
+++ Devices/CUNO2/CUNO2.c Sun Jun 08 20:23:40 2014
@@ -52,7 +52,7 @@
 
 #include "i2cmaster.h"
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -156,12 +156,16 @@
 
   // Setup the timers. Are needed for watchdog-reset
 
-#if defined (HAS_IRRX) || defined (HAS_IRTX)
+#ifdef HAS_IRRX
   ir_init();
   // IR uses highspeed TIMER0 for sampling
-  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz Fac: 125
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
 
   TCCR0B = _BV(CS02);
@@ -171,6 +175,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -249,6 +263,9 @@
 #ifdef HAS_HELIOS
     helios_task();
 #endif   
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
+#endif
   }
 
 }
--- Devices/CUR/board.h Wed Jul 11 15:19:20 2012
+++ Devices/CUR/board.h Sun Jun 08 20:46:24 2014
@@ -25,15 +25,19 @@
 #define FULL_CC1100_PA                  // PROGMEM:  100b
 #define HAS_FASTRF                      // PROGMEM:  362b  RAM:  1b
 #define HAS_RAWSEND                     // PROGMEM:   90b  RAM:  6b
-#define HAS_ASKSIN
+//#define HAS_ASKSIN // why is it here?
+//#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_TX3
 #define HAS_HOERMANN
 
 #ifdef CURV3
 #  include "board_v3.h"
+//#define CUL_HW_REVISION "CUR_V3"
 #else
 #  include "board_v2.h"
+//#define CUL_HW_REVISION "CUR_V2"
 #endif
 
 #endif
--- Devices/CUR/CUR.c Tue Nov 27 22:12:52 2012
+++ Devices/CUR/CUR.c Sun Jun 08 20:37:01 2014
@@ -40,6 +40,10 @@
 #include "fastrf.h"
 #include "rf_router.h"
 
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
+#include "rf_asksin.h"
+#endif
+
 df_chip_t df;
 
 const PROGMEM t_fntab fntab[] = {
@@ -106,7 +110,17 @@
   }
 
   // Setup the timers. Are needed for watchdog-reset
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250
+#ifdef HAS_IRRX
+  ir_init();
+  // IR uses highspeed TIMER0 for sampling
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
   TCCR0B = _BV(CS02);       
   TCCR0A = _BV(WGM01);
   TIMSK0 = _BV(OCIE0A);
@@ -150,5 +164,8 @@
     FastRF_Task();
     rf_router_task();
     JOY_Task();
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
+#endif
   }
 }
--- Devices/CUR/makefile Sun Nov 13 21:23:08 2011
+++ Devices/CUR/makefile Sun Jun 08 20:42:00 2014
@@ -22,6 +22,7 @@
  ../../clib/rf_send.c                                  \
  ../../clib/rf_receive.c                               \
  ../../clib/fht.c                                      \
+ ../../clib/rf_asksin.c                                \
  ../../clib/ttydata.c                                  \
  ../../clib/pcf8833.c                                  \
  ../../clib/menu.c                                     \
--- Devices/CUR/makefile.myusb Sun Nov 01 08:37:40 2009
+++ Devices/CUR/makefile.myusb Sun Jun 08 20:42:47 2014
@@ -22,6 +22,7 @@
  ../../clib/rf_send.c                                  \
  ../../clib/rf_receive.c                               \
  ../../clib/fht.c                                      \
+ ../../clib/rf_asksin.c                                \
  ../../clib/ttydata.c                                  \
  ../../clib/pcf8833.c                                  \
  ../../clib/menu.c                                     \
--- Devices/RFbee/board.h Thu Mar 13 23:05:46 2014
+++ Devices/RFbee/board.h Sun Jun 08 20:50:21 2014
@@ -11,6 +11,9 @@
 #define HAS_FASTRF // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
 #define HAS_ASKSIN_FUP
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #undef  HAS_ESA
 #define HAS_INTERTECHNO
 #define HAS_MORITZ
@@ -53,6 +56,7 @@
 #define LED_PIN 6
 
 #define BOARD_ID_STR "RFbee"
+//#define CUL_HW_REVISION "RFbee"
 
 #define HAS_UART 1
 #define UART_BAUD_RATE 38400
--- Devices/RFbee/RFbee.c Thu Mar 13 23:05:46 2014
+++ Devices/RFbee/RFbee.c Sun Jun 08 20:48:41 2014
@@ -40,7 +40,7 @@
 #include "intertechno.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -107,7 +107,17 @@
  eeprom_init();
 
  // Setup the timers. Are needed for watchdog-reset
- OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#ifdef HAS_IRRX
+ ir_init();
+ // IR uses highspeed TIMER0 for sampling
+ OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+ OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+ OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
  TCCR0B = _BV(CS02);
  TCCR0A = _BV(WGM01);
  TIMSK0 = _BV(OCIE0A);
@@ -115,6 +125,16 @@
  TCCR1A = 0;
  TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+ uint8_t sreg = SREG;
+ cli();
+ OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+ SREG = sreg;
+ TCCR3A = 0;
+ TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+ TIMSK3 = _BV(OCIE3A);
+#endif
+
  clock_prescale_set(clock_div_1);
 
  MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -153,6 +173,9 @@
 #endif
 #ifdef HAS_RWE
  rf_rwe_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
  }
 }
--- Devices/SCC/board.h Mon Mar 17 14:50:20 2014
+++ Devices/SCC/board.h Sun Jun 08 20:52:46 2014
@@ -49,6 +49,9 @@
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_RF_ROUTER                 // PROGMEM:  920b  RAM: 38b
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_MORITZ
 #define HAS_ESA
 #define HAS_INTERTECHNO
@@ -77,5 +80,7 @@
 #define BUSWARE_CSM
 #define BUSWARE_SCC
 #define RPI_TTY_FIX
+
+//#define CUL_HW_REVISION "SCC"
 
 #endif
--- Devices/SCC/SCC.c Mon Mar 17 14:50:20 2014
+++ Devices/SCC/SCC.c Sun Jun 08 20:54:05 2014
@@ -36,7 +36,7 @@
 #include "intertechno.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -132,7 +132,17 @@
 //  }
 
   // Setup the timers. Are needed for watchdog-reset
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#ifdef HAS_IRRX
+  ir_init();
+  // IR uses highspeed TIMER0 for sampling
+  OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
+#else
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
+#endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
   TIMSK0 = _BV(OCIE0A);
@@ -140,6 +150,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -189,6 +209,9 @@
 #endif
 #ifdef HAS_STACKING
   stacking_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
 
   }
--- Devices/TuxRadio/board.h Wed Jul 11 15:19:20 2012
+++ Devices/TuxRadio/board.h Sun Jun 08 20:59:48 2014
@@ -67,8 +67,12 @@
 #define HAS_RAWSEND                   //
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 //#define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+//#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 //#define HAS_ESA
 
 #define BUSWARE_CSM
+//#define CUL_HW_REVISION "TuxRadio"
 
 #endif
--- Devices/TuxRadio/CSM.c Tue Nov 27 22:12:52 2012
+++ Devices/TuxRadio/CSM.c Sun Jun 08 21:01:19 2014
@@ -32,7 +32,7 @@
 #include "rf_router.h"
 #include "memory.h"
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -108,7 +108,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -117,6 +121,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
   wdt_enable(WDTO_2S);
@@ -161,6 +175,9 @@
 #endif
 #ifdef HAS_IRRX
     ir_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
   }
 
--- Devices/TuxRadio2/board.h Fri Jan 11 14:08:54 2013
+++ Devices/TuxRadio2/board.h Sun Jun 08 21:04:11 2014
@@ -51,6 +51,9 @@
 #define HAS_RAWSEND                   //
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_ESA
 #define HAS_TX3
 #define HAS_INTERTECHNO
@@ -59,6 +62,8 @@
 #define HAS_MORITZ
 
 #define BUSWARE_CSM
+
+//#define CUL_HW_REVISION "TuxRadio2"
 
 #endif
 
--- Devices/TuxRadio2/CSM.c Sat Sep 21 18:10:34 2013
+++ Devices/TuxRadio2/CSM.c Sun Jun 08 21:02:41 2014
@@ -36,7 +36,7 @@
 #include "rf_moritz.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -112,7 +112,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -121,6 +125,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
   wdt_enable(WDTO_2S);
@@ -168,6 +182,9 @@
 #endif
 #ifdef HAS_MORITZ
     rf_moritz_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
 
   }
--- Devices/zCSM/board.h Fri Apr 12 16:03:32 2013
+++ Devices/zCSM/board.h Sun Jun 08 20:55:54 2014
@@ -51,6 +51,9 @@
 #define HAS_RAWSEND                   //
 #define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
 #define HAS_ASKSIN
+//#define HAS_MS_TIMER3 // RAM: +5b noansi: Timer3 for ms timestamp counter in asksin.c
+#define HAS_MS_TIMER0 // RAM: +5b noansi: Timer0 for ms timestamp counter in asksin.c, 4ms (IR 8ms) increment
+#define HAS_ASKSIN_PLL_HELPER // RAM: +1b noansi: check for PLL Lock and try recalibration, if not
 #define HAS_MORITZ
 #define HAS_ESA
 #define HAS_INTERTECHNO
@@ -64,5 +67,7 @@
 #define TTY_BUFSIZE             128
 
 #define BUSWARE_CSM
+
+//#define CUL_HW_REVISION "zCSM"
 
 #endif
--- Devices/zCSM/CSM.c Fri Apr 12 16:03:32 2013
+++ Devices/zCSM/CSM.c Sun Jun 08 20:56:56 2014
@@ -40,7 +40,7 @@
 #include "intertechno.h"
 #endif
 
-#ifdef HAS_ASKSIN
+#if defined(HAS_ASKSIN) || defined(HAS_ASKSIN_PLL_HELPER) || defined(HAS_MS_TIMER0) || defined(HAS_MS_TIMER3)
 #include "rf_asksin.h"
 #endif
 
@@ -148,7 +148,11 @@
   // IR uses highspeed TIMER0 for sampling
   OCR0A  = 1;                              // Timer0: 0.008s = 8MHz/256/2   == 15625Hz
 #else
-  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
+#if defined(HAS_MS_TIMER0) && !defined(HAS_MS_TIMER3)
+  OCR0A  = 124; // Timer0: 0.004s = 8MHz/256/125 interrupt clock
+#else
+  OCR0A  = 249; // Timer0: 0.008s = 8MHz/256/250 interrupt clock
+#endif
 #endif
   TCCR0B = _BV(CS02);
   TCCR0A = _BV(WGM01);
@@ -157,6 +161,16 @@
   TCCR1A = 0;
   TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8
 
+#ifdef HAS_MS_TIMER3
+  uint8_t sreg = SREG;
+  cli();
+  OCR3A = 999; // 999 -> Timer3: 1ms = 8MHz/8/1000 interrupt clock
+  SREG = sreg;
+  TCCR3A = 0;
+  TCCR3B = _BV(CS31) | _BV(WGM32); // Timer3: 1us = 8MHz/8 base clock
+  TIMSK3 = _BV(OCIE3A);
+#endif
+
   clock_prescale_set(clock_div_1);
 
   MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
@@ -205,6 +219,9 @@
 #endif
 #ifdef HAS_MORITZ
     rf_moritz_task();
+#endif
+#ifdef HAS_ASKSIN_PLL_HELPER
+    rf_asksin_check_PLL_task();
 #endif
 
   }
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juni 2014, 19:41:04
Hallo Rudolf,


wie Du vermutlich bemerkst, habe ich nicht nur die TimeStamp Option eingebaut, sondern auch meinen PLL lock check und recover als Task (so weit er in den Speicher passt). Den ms TimeStamp counter habe ich als board Option ebenfalls allgemein eingebaut, falls es jemand brauchen kann.

Außerdem habe ich Änderungen am cdcLUFA CDC_Task vorgenommen. Irgenwas ist meinem Gefühl nach da noch nicht richtig mit dem USB Handling oder TTY Buffer Handling.
Ich sehe es doch richtig, dass der auch im USB Interrupt ausgeführt wird? Daher einige Bemühungen, es sicherer gegen eine zweiten Interrupt bedingten Aufruf zumachen. Da hat auch schon jemand in der Richtung gearbeitet.
Zur Stabilität hat es beigetragen und hoffentlich keine Nebenwirkungen beim Empfang.
Allerdings kommt es immer noch vor, dass "unknown command" vom CUL kommt. Ich hatte in vorherigen Versionen auch den Zustand, dass merkwürdige Zeitstempel oder ganz falsche Zeichen zurück kamen, was sich alles danach anfühlt, als ob sich da irgend was überholt.

Vielleicht hat ja jemand noch einen Tip für mich. Ich sehe jedenfalls spontan nicht, was das mit der Timestamp Option zu tun haben soll, außer, dass mit jedem Empfangstelegramm 12 Bytes mehr an den USB-Host (Zentrale) gesendet werden müssen.

Die Änderung in display.c bezügich der HEX Wandlung und Wechsel von int8_t zu uint8_t hat noch ein paar bytes gebracht, was für CUL_V2 interessant sein kann.

Ich habe die Änderungen in alle Hardwarezweige mit HAS_ASKSIN eingebaut, allerdings bisher nur CUL und COC compiliert und mit CUL_V3 und COC im Test.


Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN
Beitrag von: noansi am 09 Juni 2014, 20:01:13
Hallo Rudolf,

und hier noch die Kurzbeschreibung zu den zusätzlichen A Befehlen:

- t<x>   Enable (x=1) or disable (x=0) TimeStamp mode. Messages ar sent in the form: iiiittttttttaa*

    iiii - ID= FF01
    tttttttt - TimeStamp of reception in ms (but 4ms / 8ms)
    aa* - a normal AskSin message like if TimeStamp mode is disabled

- pmm*   Request a ping answer in TimeStamp mode. mm* is send back in the message.

    The Ping puts FF02 as ID in front of the message. So the form is: iiiittttttttllmm*rr

    iiii - ID= FF02
    tttttttt - TimeStamp of reception in ms (but 4ms / 8ms)
    ll - length of mm* in bytes (so half the number of digits sent). Be carefull not to flood the buffers!
    mm* - the message sent with the ping
    rr - fixed rssi value of (-138)

   Ping is only valid, if TimeStamp mode is switched on (once with At1).

- P<x>   Disable (x=1) or enable (x=0) PLL Lock error messages.

Bei einem unbekannten A Kommando, oder wenn es gerade nicht zulässig ist, wird A?\r\n zurück geliefert. Es wird nur noch mit Ax der AskSin Modus abgeschaltet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 11 Juni 2014, 17:04:28
Hallo,

ich habe in meiner Installation (FritzBox 7390 mit CUL) die Erweiterungen der CUL Firmware von noansi / Ansgar  (Register PLLNOLOCK und Timing für CUL) zusammen mit der für das Timing erweiterteten 00_CUL.pm von Martin getestet.

Beide Features haben bei mir die Stabilität HM Kommunikation deutlich verbessert - Details siehe hier: http://forum.fhem.de/index.php/topic,23223.msg175978.html#msg175978 (http://forum.fhem.de/index.php/topic,23223.msg175978.html#msg175978)

Ich würde mich freuen, wenn die Erweiterungen in den Standard einfliessen würden.

Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 12 Juni 2014, 09:03:23
Folgende Punkte sind mir beim durchfliegen aufgefallen:
- es sind etwa 80 kb an Diffs, das ist zu viel um es zu verstehen und zu testen, bzw. falls Probleme gibt es sauber auf eine Aenderung zurueckzufuehren. Ein Patch sollte minimal sein, nur das aendern, was man erwartet, und das sollte nur eine Sache pro Patchdatei sein. Nach dem Motto: Patch1: PLL_LOCK. Patch2: AskSin Timer.
- es gibt mAn viele unnoetige Umformatierungen, Kommentar-Aenderungen, etc. Insb. sowas wie "??? Needed?" fuer neue Zeilen ist ein No-Go. Entweder weiss man, was man tut, oder nicht.
- es wird an vielen Stellen auskommentierter Code eingefuegt. Das ist selbst fuer alten Code nicht erwuenscht, fuer Historie gibt es SVN.
- Aenderungen auf Verdacht (wie in cdc/display/ringbuffer/intertechno/etc), die keine konkreten Probleme loesen, werde ich nicht uebernehmen, auch nicht, wenn sie als einzel-Patch kommen.
- mein geliebtes CUL_V2 past nicht mehr in die 12k rein (30 Bytes+). Hat mit AskSin nix am Hut, muss trotzdem leiden.
- fuer Asksin-Timer sollte man die existierende ticks Variable nehmen: 8ms Aufloesung sollten Martin reichen, es ist auf allen Geraeten gleich (debugging einfacher), es bleibt noch ein HW-Timer uebrig, falls man es wirklich braucht. Einen "ping" kann man damit auch sparen, da eine Zeitabfrage gibt es bereits, und die CPU muss 1000 Interrupts in der Sekunde weniger verarbeiten. Die Code-Aenderung ist minimal und das ist mir wichtig.
- rf_asksin_check_PLL_task wird auch dann ausgefuehrt, falls das Geraet gar nicht in HM-Modus ist. Funktioniert das ueberhaupt in SlowRF Modus?
- warum ist ein separater HAS_ASKSIN_PLL_HELPER_TX und HAS_ASKSIN_PLL_HELPER_RX notwendig?
- das Ganze rf_asksin.c ist in "HAS_ASKSIN" eingepackt. Da sind einzelne "#ifdef HAS_ASKSIN" fuer weitere includes unnoetig.

In diesem Zustand werde ich die Patches nicht uebernehmen.

Grosse Dateien (und diffs generell) sollte man als Anhang posten, dann kann man Fehler beim Copy&Paste sparen.

Gruss,
  Rudi
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 13 Juni 2014, 01:28:16
Hallo Rudolf,


danke für Deine Instruktionen.

Zitat
- es sind etwa 80 kb an Diffs, das ist zu viel um es zu verstehen und zu testen, bzw. falls Probleme gibt es sauber auf eine Aenderung zurueckzufuehren. Ein Patch sollte minimal sein, nur das aendern, was man erwartet, und das sollte nur eine Sache pro Patchdatei sein. Nach dem Motto: Patch1: PLL_LOCK. Patch2: AskSin Timer.
Ok, ich zerlege es einzelne patches.

Zitat
- es gibt mAn viele unnoetige Umformatierungen, Kommentar-Aenderungen, etc. Insb. sowas wie "??? Needed?" fuer neue Zeilen ist ein No-Go. Entweder weiss man, was man tut, oder nicht.
Die Umformatierungen erleichtern die Lesbarkeit meiner Meinung nach durch deutlichere Abgrenzungen. Das ist natürlich Geschmackssache.
Zu den Fragezeichen: Hatte ich schon welche vorgefunden (USB-Shutdown) und wenn etwas unklar ist, halte ich es für besser, es kenntlich zu machen. Ggf. lassen sich da dann zukünftig mal ein paar Bytes sparen oder jemand anderes kommt einer Problemlösung etwas näher. Bei der Bootloadervorbereitung war nicht klar, ob der Timer 3 Interrupt weiter laufen darf oder nicht, da er ja zunächst nichts gravierendes tut, respektive man auch erwarten kann, dass ein bootloader einen definierten Zustand herstellt.

Zitat
- es wird an vielen Stellen auskommentierter Code eingefuegt. Das ist selbst fuer alten Code nicht erwuenscht, fuer Historie gibt es SVN.
Ok, werf ich raus. Bei display.c hatte ich etwas mit code gespielt, in der Hoffnung noch ein paar bytes mehr raus kitzeln zu können. Der Compiler macht das da aber schon gut.
Textausgaben zu Debuggingzwecken halte ich aber für sinnvoll drin zu lassen, damit man sie bei Bedarf nochmal aktivieren kann. Nebenbei sind das auch Hinweise für Schwachstellen an denen schon mal Probleme aufgetaucht sind.

Zitat
- Aenderungen auf Verdacht (wie in cdc/display/ringbuffer/intertechno/etc), die keine konkreten Probleme loesen, werde ich nicht uebernehmen, auch nicht, wenn sie als einzel-Patch kommen.
Kann ich weg lassen.
Aber in display.c habe ich mit dem Wechsel auf uint8_t ein paar verschenkte bytes gefunden, die auch Dich in CULV2 interessieren könnten.
Und bei cdc vermute ich ein schlummerndes Interrupt Reentranz Problem in Bezug auf merkwürdige Ausgaben von "unkown command" mit Text für unbekannte Kommandos, der aus dem Ausgabepuffer stammen muss (Empfangsdaten tauchten da schon mal auf). Nur fehlenden Zeichen ließem sich mit Überlastung erklären. Aber TX-Daten im Empfangsstrom muss was anderes sein, im ungünstigsten Fall Stacküberlauf.

Zitat
- mein geliebtes CUL_V2 past nicht mehr in die 12k rein (30 Bytes+). Hat mit AskSin nix am Hut, muss trotzdem leiden.
Ich habe leider noch nicht genug verschenkte Bytes gefunden, das Ziel ist aber nicht aus den Augen verloren.

Zitat
- fuer Asksin-Timer sollte man die existierende ticks Variable nehmen: 8ms Aufloesung sollten Martin reichen, es ist auf allen Geraeten gleich (debugging einfacher), es bleibt noch ein HW-Timer uebrig, falls man es wirklich braucht. Einen "ping" kann man damit auch sparen, da eine Zeitabfrage gibt es bereits, und die CPU muss 1000 Interrupts in der Sekunde weniger verarbeiten. Die Code-Aenderung ist minimal und das ist mir wichtig.
Von Timer3 habe ich mich schon verabschiedet und schmeiss den auch wieder ganz raus.
An die laufende Timervariable habe ich auch schon gedacht und denke Martin zu einer kleinen Multiplikation überreden zu können, so dass ich mit Multiplikation/Shift die CUL auch nicht belasten muss, nur um wirklich ms auszugeben. Vorher werde ich das aber noch im "Selbstversuch" und mit Tobias, so er möchte, genauer untersuchen, ob die 8ms für die Resends nachteilig sind. 4ms Inkrement läuft jedenfalls ganz gut.

Der Ping, so wie ich ihn eingebaut habe, hat den Vorteil, Daten nach Wunsch einbauen zu können und damit auch wiedererkennbar durch den normalen Empfang über MAIN zu schicken, statt auf die Antwort zu warten. Das eröffnet zusätzliche Möglichkeiten für Zeitmessungen, insbesondere in der Umgebung mit anderen Geräten. Mit apptime sehe ich da schon einen gewissen Bedarf.  Daher werde ich ihn nicht rauswerfen, sondern per define als board Option einbauen, so dass man ihn bei Bedarf weg lassen kann.

Zitat
- rf_asksin_check_PLL_task wird auch dann ausgefuehrt, falls das Geraet gar nicht in HM-Modus ist. Funktioniert das ueberhaupt in SlowRF Modus?
PLL lock muss sein, so wie ich die Doku zum chip verstehe, sonst läuft der Oszillator nicht richtig. Das Ergebnis ist ausbleibender Empfang. Ich checke ja nur bei bestehendem RX-State, ob auch der PLL eingerastet ist und falls nicht, wird nur neu kalibriert, was keine Einstellungen verändert.
So ist genau mein Problemfall im RX Zustand und tritt auch bei Tobias auf, wie er in seinen Logs jetzt auch sehen kann. Ist der Chip in einem anderen State oder der Lock ist da, dann kostet die Prüfung nur ein paar Taktzyklen. Das stört bei meinen Slow-RF Tests bisher nicht (teste ich auf CUL433 und COC mit ELV WS Sensoren).

Zitat
- warum ist ein separater HAS_ASKSIN_PLL_HELPER_TX und HAS_ASKSIN_PLL_HELPER_RX notwendig?
Weil die TX nur für interessierte Nutzer drin geblieben ist. Derzeit ist es nicht definiert und belastet daher auch nicht den Flashspeicher. Wenn andere diese Varainte mit Lock Prüfung aber für sich entdecken, ist es nur eine Frage des mit rein compilierens. Laut chip Doku sollte man vor RX und TX auf PLL lock checken.

Zitat
- das Ganze rf_asksin.c ist in "HAS_ASKSIN" eingepackt. Da sind einzelne "#ifdef HAS_ASKSIN" fuer weitere includes unnoetig.
Das hast Du beim Überfliegen vermutlich nicht richtig gesehen, dass es in der Änderung nicht mehr komplett darin eingepackt ist, damit man Timer3, die PLLLOCK Routinen und AskSin einzeln per #defines nach Bedarf reinnehmen kann.

Zitat
Grosse Dateien (und diffs generell) sollte man als Anhang posten, dann kann man Fehler beim Copy&Paste sparen.
Und mal was zum lachen, ich hab die Option für die Dateianhänge schon in den Icons gesucht und dachte, ich dürfte nicht... und bin eben erst auf den Gedanken gekommen, die erweiterten Optionen mal auf zu klappen...


Gruß, Ansgar.
Titel: Anpassungen V1.58 PLL Lock
Beitrag von: noansi am 15 Juni 2014, 13:54:23
Hallo Rudolf,

hier der neue erste Teil zum Firmware Änderungswunsch.

Ich habe die PLL lock Funktionen nun in eine sparate Datei gepackt (cc1101_pllcheck.*). Da WinMerge da nicht mitgespielt hat sind die beiden neue Dateien in clib_PLLLOCK_new_files_not_in_diff.tgz.

In PLLLOCK_V1.58.DIFF.GZ das diff zu den Dateien, die ich in 428-trunk vom 14.6.14 10:40 vorgefunden und meine Änderung darin eingepflegt (und auf CUL V3 und COC getestet) habe. Sind leider viele Unterschiede, weil die boards angepackt werden müssen.

In culfw-code-428-trunk_my_V1.58_PLLLOCK.tgz sind nochmal alle geänderten Dateien komplett drin. Auch die Firmware HEX Files für CUL und COC.

Mit Rücksicht auf den Speicherplatz bei CUL_V2 sind die eingebauten Meldungen etwas knapper geworden.
"PLL0" besagt, dass in RX der PLL Lock beim Test nicht vorhanden war.
"PLL1" besagt, dass der Rekalibrierversuch ebenfalls nicht zu einem PLL Lock geführt hat.

Außerdem habe ich das ganze mit #defines konfigurierbar gemacht, so dass man nach Bedarf einbauen kann, was benötig wird.

Die Änderung in display.h ist ebenfalls drin, mit Rücksicht auf Deinen CUL_V2 Wunsch, um Flashspeicher zu sparen. Außerdem habe ich darin schon die 32-Bit Hex Ausgabe vorbereitet, die ich für den nächsten Step mit Timestamp brauche. Auch dies wieder mit define, um es rein nehmen zu können, wenn es gebraucht wird.

In CUL_V2 passt der PLL lock check rein (12258bytes + 8data).

Ich hoffe, das passt jetzt so.

Edit: Anhang gelöscht, da update siehe unten.

Danke und Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 15 Juni 2014, 16:18:37
Zitat
Ich habe die PLL lock Funktionen nun in eine sparate Datei gepackt (cc1101_pllcheck.*).

Das war ein gute Idee.  Eine weniger gute ist pllcheck fuer alle Modi zu aktivieren. Bisher trat das Problem nur mit HomeMatic auf, und es wurde mWn nicht mit allen anderen Protokollen getestet. Ich will nicht Code auf Verdacht ohne Grund bzw Test&Nachweis einbauen.

Zitat
Da WinMerge da nicht mitgespielt hat sind die beiden neue Dateien in clib_PLLLOCK_new_files_not_in_diff.tgz.

Apropos Windows: deine Datei ist voller CR/NL, ich hoffe, dass mein patch-Programm das ueberall erfolgreich loeschen konnte, er hat sich jedenfalls reichlich beschwert.

Die Änderung in display.h ist ebenfalls drin, mit Rücksicht auf Deinen CUL_V2 Wunsch, um Flashspeicher zu sparen.
Haette nicht drin sein sollen, nach dem Motto: "Eine Problem: Ein Patch"

Deine Aenderung in display.c spart in der Tat 8 Bytes. Ich habe eine Weile nach dem Ausloeser gesucht: es stellt sich raus dass int_8 als Laufvariable unguenstiger ist, als uint_8. Ich habe in den beiden Funktionen ein 'u' hinzugeufuegt, und 28 Bytes gespart. Danke fuer den Anstoss.

Mit dem PLL-Check ist CUL_V2 immer noch 12384+8 (==zu) gross. Evtl. kann man mit neuerem Compiler was kleineres bauen (meins ist 4.3.3), allerdings hatten neuere (4.6.x?) Probleme lauffaehigen Code fuer RFR zu bauen.


Ich habe cc1101_RX_check_PLL_wait_task jetzt ins rf_asksin_task verfrachtet (macht den Patch 30% kleiner), stoert CUL_V2 nicht, und aendert nur da was, wo es noetig war und getestet wurde.

Das Leerzeichen hinter dem \ in TuxRadio2/makefile hat mich 'ne weile lang geaergert: bitte sowas selbst testen, indem du ein make in Devices durchfuehrst.

Habe die Versionsnummer auf 1.59 geaendert mit einem CUL_V4 kurz getestet und eingecheckt.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Juni 2014, 17:35:25
Hallo Rudolf,

Zitat
Eine weniger gute ist pllcheck fuer alle Modi zu aktivieren. Bisher trat das Problem nur mit HomeMatic auf, und es wurde mWn nicht mit allen anderen Protokollen getestet. Ich will nicht Code auf Verdacht ohne Grund bzw Test&Nachweis einbauen.

Ich habe jetzt meine Problem-CUL zur CUL_WS umfunktioniert und schaue, ob ich es so konfiguriert (also ohne rfmode HomeMatic) mit loggen kann. Den Empfang stört es jedenfalls erkennbar nicht.
Ich werde berichten.


Zitat
Apropos Windows: deine Datei ist voller CR/NL, ich hoffe, dass mein patch-Programm das ueberall erfolgreich loeschen konnte, er hat sich jedenfalls reichlich beschwert.

Danke für den Hinweis. Ich nutze mittlerweile  Visual C zum Editieren. Das ist aber nicht das Problem.
WinMerge macht leider die CR/LF in die patch Datei.  :(


Zitat
Mit dem PLL-Check ist CUL_V2 immer noch 12384+8 (==zu) gross. Evtl. kann man mit neuerem Compiler was kleineres bauen (meins ist 4.3.3), allerdings hatten neuere (4.6.x?) Probleme lauffaehigen Code fuer RFR zu bauen.

Ich nutze den avr-gcc 4.7.2 . Damit kommt code raus, der anscheinend auf CUL_V3 und COC auch läuft. Und damit habe ich die genannte Größe von 12258bytes + 8data für CUL_V2 raus bekommen.

Wie äußerten sich die Compiler-Probleme, die Du hattest?


Zitat
Das Leerzeichen hinter dem \ in TuxRadio2/makefile hat mich 'ne weile lang geaergert: bitte sowas selbst testen, indem du ein make in Devices durchfuehrst.

Verflixt, entschuldige, hat mich auch geärgert und ich hatte es auch auf dem Pi getestet und geändert, aber dann wohl vergessen es in mein Änderungsverzeichnis zurück zu kopieren. Weil ich es gestet habe, ist auch das makefile in Devices geändert, weil da ein make clean fehlte.


Zitat
Habe die Versionsnummer auf 1.59 geaendert mit einem CUL_V4 kurz getestet und eingecheckt.

Dauert das etwas, bis alles auf SVN aktualisiert ist? Ich sehe Deine Änderungen nur zum Teil. In clib taucht es gar nicht auf (cc1101_pllcheck.* und auch display.* ist unverändert). Oder schlagen da die CR/LF aus dem diff zu?


Gruß und danke,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 15 Juni 2014, 17:56:08
 
Zitat
Den Empfang stört es jedenfalls erkennbar nicht.
Es geht mir eher darum, ob es hilft, und weniger, ob es stoert :)


Zitat
Wie äußerten sich die Compiler-Probleme, die Du hattest?
RFR ging nicht. Und ich hatte keine Zeit/Lust zu analysieren, woran es genau liegt.


Zitat
Ich sehe Deine Änderungen nur zum Teil.
Danke fuer den Hinweis. War wohl zu sehr im Hektik, und habe das commit im falschen Verzeichnis durchgefuehrt.
Jetzt sollte es korrigiert sein.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Juni 2014, 18:53:13
Hallo Rudolf,

es gehört zwar nicht hierher, aber mir sind da gerade noch zwei Unschärfen in cc1100.c aufgefallen.

In ccTX() steht:

  while(cnt-- && (ccStrobe( CC1100_STX ) & 0x70) != 2)
   my_delay_us(10);

und müsste lauten

  while(cnt-- && (ccStrobe( CC1100_STX ) & 0x70) != 0x20)
   my_delay_us(10);


In ccRX() steht:

  while(cnt-- && (ccStrobe( CC1100_SRX ) & 0x70) != 1)
    my_delay_us(10);

und müsste lauten

  while(cnt-- && (ccStrobe( CC1100_SRX ) & 0x70) != 0x10)
    my_delay_us(10);

Im bisherigen Zustand warten beide Routinen zuverlässig 2550µs+Schleifenrechenzeit. Aber gedacht war das wohl nicht so. Eigentlich sollten die jeweils nur so lange den Strobe schicken, bis im Status der jeweilige Zustand zurück gemeldet wird.


Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 21 Juni 2014, 11:56:53
Ich gebe dir recht, dass (EGALWAS & 0x70) != 2 ist. Ich weiss aber nicht mehr(?), warum 0x70 mit 0x20 oder 0x10 verglichen werden soll. Kannst Du mir auf die Spruenge helfen, am besten mit Hinweis auf die Doku?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Juni 2014, 18:59:45
Hallo Rudolf,


auf Seite 31 der cc1101 Doku steht es in Table 23: Status Byte Summary.

Auch die cc1100.h hat die Konstanten drin unter // Chip Status Byte, so dass der code lesbarer so aussehen kann:

in ccTX:

  while(cnt-- && (ccStrobe( CC1100_STX ) & CC1100_STATUS_STATE_BM) != CC1100_STATE_TX)
    my_delay_us(10);

in ccRX:

  while(cnt-- && (ccStrobe( CC1100_SRX ) & CC1100_STATUS_STATE_BM) != CC1100_STATE_RX)   
    my_delay_us(10);


In rf_router.c hat jemand Kommentare zu Zeiten in rf_router_ping(void) hinterlassen.
Magische Wartezeiten ohne nachvollziehbaren Kommentar habe ich auch schon an Umschaltpunkten gesehen. Wenn die (Umschalt-)Zeiten in manchen Protokollen von Bedeutung sind (was ich leider nicht weiß), dann würde eine Korrektur natürlich ggf. weitere Anpassungen zu Wartezeiten nach sich ziehen. Auf Seite 54 der cc1101 Doku gibt es eine Tabelle mit den Umschaltzeiten des cc1101 zum Vergleich.

Richtig ist es natürlich nicht ein Timing auf einem Bug aufzubauen.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Juni 2014, 20:06:27
Hallo Rudolf,

Zitat
Ich habe cc1101_RX_check_PLL_wait_task jetzt ins rf_asksin_task verfrachtet (macht den Patch 30% kleiner), stoert CUL_V2 nicht, und aendert nur da was, wo es noetig war und getestet wurde.

Ich habe nun eine längere Testlaufzeit auch mit CUL_WS und CUL verbose 2 mit meiner PLL-Problem CUL hinter mich gebracht.

Das PLL Lock Problem ist offenbar an die Umschaltung auf RX (oder auch TX) gebunden (wie auch durch AUTOCAL zu erwarten). Ohne Umschaltung zeigt sich bisher kein PLL0 Log Eintrag.

Allerdings führt das immer noch vorhandene (vermutlich) USB Problem trotz CUL_WS Konfiguration (also nur Empfang) zu folgenden Einträgen mit PLL0:

2014.06.18 01:17:09 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:17:20 2: CUL_0WS: unknown message ? (? (? is unknown) e f m l t u x is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:25:41 2: CUL_0WS: unknown message PLL0
2014.06.18 01:25:41 2: CUL_0WS: unknown message ? (PLL0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:26:03 2: CUL_0WS: unknown message ? (? (PLL0 is unknown K517741691A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:26:27 2: CUL_0WS: unknown message ? (? (? (PLL0 is un i A Z E G K41892166DF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:28:38 2: CUL_0WS: unknown message ? (? (? (? (PLL0 is2 B b C  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:28:53 2: CUL_0WS: unknown message ? (? (? (? (? (PLL0 E G M K UK2167010037 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:28:58 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:29:22 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:29:40 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:30:44 2: CUL_0WS: unknown message ? (? (? ( i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:31:49 2: CUL_0WS: unknown message ? (? (? (? ( i is unkno V W X e is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:31:52 2: CUL_0WS: unknown message ? (? (? (? (? ( i in A Z E GK517741691A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 01:31:52 2: CUL_0WS: unknown message ? (? (? (? (? (? (  K5177416937 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

oder:

2014.06.18 18:41:26 2: CUL_0WS: unknown message ? (? (? (? (?  is unk V W X e f m l t K517551 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:41:29 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:41:54 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:41:54 2: CUL_0WS: unknown message ? (? (? is unknown) U e f m l t u x is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:58:53 2: CUL_0WS: unknown message PLL0
2014.06.18 18:58:54 2: CUL_0WS: unknown message ? (PLL0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:59:18 2: CUL_0WS: unknown message ? (? (PLL0 is unknow X e f m l t u xK7116026117 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 18:59:24 2: CUL_0WS: unknown message ? (? (? (PLL0 is unkone of B is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:01:48 2: CUL_0WS: unknown message ? (? (? (? (PLL0 isZ E G M K K5175516 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:01:49 2: CUL_0WS: unknown message ? (? (? (? (? (PLL0 C F i A ZK0107525709 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:02:00 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:02:01 2: CUL_0WS: unknown message ? (? (? (? (? ( is uT V W X e K2165010037 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:02:12 2: CUL_0WS: unknown message ? (? (? (? (? (? ( 0 B b C F K7116026 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:02:12 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:02:51 2: CUL_0WS: unknown message ? (? (? (? (? ( is T V W X e K1100020022 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:03:29 2: CUL_0WS: unknown message ? (? (? (? (? (? ( 2B b C F iK61814166FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.18 19:04:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?nB b C F i K170 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

in den letzten 2 Tagen ist allerdings seit einem Neustart Ruhe, so dass es typisch bei beiden CUL_WS Culs so aussieht ohne PLL0 Eintrag:

2014.06.21 04:22:59 2: CUL_0WS: unknown message K00
2014.06.21 04:31:46 2: CUL_433: unknown message K00
2014.06.21 04:46:27 2: CUL_0WS: unknown message K00
2014.06.21 04:55:15 2: CUL_0WS: unknown message K00
2014.06.21 04:58:11 2: CUL_0WS: unknown message K00
2014.06.21 05:06:59 2: CUL_433: unknown message K00
2014.06.21 05:09:55 2: CUL_433: unknown message K00
2014.06.21 05:21:39 2: CUL_0WS: unknown message K00
2014.06.21 05:27:31 2: CUL_433: unknown message K00
2014.06.21 05:30:27 2: CUL_433: unknown message K00
2014.06.21 05:30:27 2: CUL_0WS: unknown message K00
2014.06.21 05:38:55 2: CUL_0WS: unknown message K84
2014.06.21 05:39:15 2: CUL_0WS: unknown message K00
2014.06.21 05:41:50 2: CUL_0WS: unknown message K84
2014.06.21 05:42:11 2: CUL_433: unknown message K00
2014.06.21 05:45:07 2: CUL_433: unknown message K00
2014.06.21 05:45:07 2: CUL_0WS: unknown message K00
2014.06.21 05:45:07 2: CUL_0WS: unknown message K00
2014.06.21 05:48:03 2: CUL_433: unknown message K00
2014.06.21 05:50:59 2: CUL_0WS: unknown message K00
2014.06.21 06:05:14 2: CUL_0WS: unknown message K84
2014.06.21 06:08:35 2: CUL_433: unknown message K00
2014.06.21 06:11:31 2: CUL_433: unknown message K00
2014.06.21 06:11:31 2: CUL_0WS: unknown message K00
2014.06.21 06:14:27 2: CUL_433: unknown message K00
2014.06.21 06:20:19 2: CUL_433: unknown message K00
2014.06.21 06:20:19 2: CUL_0WS: unknown message K00
2014.06.21 06:26:11 2: CUL_433: unknown message K00
2014.06.21 06:26:11 2: CUL_0WS: unknown message K00
2014.06.21 06:29:07 2: CUL_433: unknown message K00
2014.06.21 06:29:07 2: CUL_0WS: unknown message K00
2014.06.21 06:32:03 2: CUL_433: unknown message K00
2014.06.21 06:32:03 2: CUL_0WS: unknown message K00
2014.06.21 06:37:55 2: CUL_433: unknown message K00
2014.06.21 06:40:51 2: CUL_0WS: unknown message K00
2014.06.21 06:46:43 2: CUL_433: unknown message K00
2014.06.21 06:46:43 2: CUL_0WS: unknown message K00
2014.06.21 06:49:39 2: CUL_0WS: unknown message K00
2014.06.21 06:52:02 2: CUL_0WS: unknown message K84
2014.06.21 06:52:35 2: CUL_433: unknown message K00
2014.06.21 06:55:31 2: CUL_433: unknown message K00
2014.06.21 07:01:24 2: CUL_0WS: unknown message K00
2014.06.21 07:04:20 2: CUL_0WS: unknown message K00
2014.06.21 07:07:16 2: CUL_0WS: unknown message K00
2014.06.21 07:07:16 2: CUL_433: unknown message K00
2014.06.21 07:10:11 2: CUL_433: unknown message K00
2014.06.21 07:13:07 2: CUL_433: unknown message K00
2014.06.21 07:16:03 2: CUL_433: unknown message K00
2014.06.21 07:16:04 2: CUL_0WS: unknown message K00
2014.06.21 07:21:55 2: CUL_433: unknown message K00
2014.06.21 07:24:13 2: CUL_0WS: unknown message K84
2014.06.21 07:27:47 2: CUL_433: unknown message K00
2014.06.21 07:33:39 2: CUL_433: unknown message K00
2014.06.21 07:36:35 2: CUL_0WS: unknown message K00
2014.06.21 07:39:31 2: CUL_433: unknown message K00
2014.06.21 07:54:12 2: CUL_0WS: unknown message K00
2014.06.21 07:54:20 1: Error: S300TH CUL_WS Cannot decode K0700B3F8 (sanitycheck). Malformed
2014.06.21 07:57:07 2: CUL_433: unknown message K00
2014.06.21 07:57:07 2: CUL_0WS: unknown message K00
2014.06.21 08:00:03 2: CUL_433: unknown message K00
2014.06.21 08:02:59 2: CUL_433: unknown message K00
2014.06.21 08:08:51 2: CUL_433: unknown message K00
2014.06.21 08:11:47 2: CUL_433: unknown message K00
2014.06.21 08:20:36 2: CUL_0WS: unknown message K00
2014.06.21 08:26:27 2: CUL_433: unknown message K00
2014.06.21 08:29:23 2: CUL_433: unknown message K00
2014.06.21 08:38:12 2: CUL_0WS: unknown message K00
2014.06.21 08:41:07 2: CUL_433: unknown message K00

Bei RF-Routern z.B., die gelegentlich schweigen, kann der PLL-Check ggf. also auch helfen. Ich habe derzeit keine Testmöglichkeit dazu.


Da, wie in den Logs zu sehen, irgendwie Ausgangsdaten wieder in den Eingangspuffer (oder Befehlspuffer) geraten, führt ein Kxx* zu einem Sendeversuch. Damit zu einer State Umschaltung. Dabei kommt dann der PLL Check Code in der Hauptschleife doch gelegentlich zum Zug.

Auch in den Logs zu sehen, ist der Versuch, den TX-Buffer an USB zu leeren, während das bereits passiert (die Ausgabe der Befehlsliste wird davon unterbrochen).

Wo im Code es genau zu dem Problem mit den Ausgangsdaten im Eingabestrom kommt, habe ich noch nicht gefunden.
Da ich das bei COC noch nicht beobachtet habe, denke ich, dass das Problem im USB Bereich des Code liegt.

Hier noch mehr Log zum Problem:

2014.06.19 05:00:26 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:00:26 2: CUL_0WS: unknown message ? (? ( is unknown)  K2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:00:42 2: CUL_0WS: unknown message ? (? (? ( is unknown A Z K0197615 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:00:48 2: CUL_0WS: unknown message ? (? (? (? ( is unk i A Z E GK7191 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:00:55 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:00:55 2: CUL_0WS: unknown message ? (? (? ( is is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:03:10 2: CUL_0WS: unknown message ? (? (? (? ( is is T V W X e K1702710700AEC81K41814166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:03:39 2: CUL_0WS: unknown message ? (? (? (? (? ( is owK0197615806 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:03:41 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:06:05 2: CUL_0WS: unknown message ? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:06:18 2: CUL_0WS: unknown message ? (? (? (?  is unknW XK2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:06:36 2: CUL_0WS: unknown message ? (? (? (? (?  is un i A Z E G M K U K0197615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:06:45 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:09:00 2: CUL_0WS: unknown message ? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:09:28 2: CUL_0WS: unknown message ? (? (? (?  is unknW X e f m l K1700710700AEA81K7191916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:09:33 2: CUL_0WS: unknown message ? (? (? (? (?  is unknoK019761 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:09:39 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:11:51 2: CUL_0WS: unknown message ? (? (? (? (?  is u V K1700710700AEA816 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:11:55 2: CUL_0WS: unknown message ? (? (? (? (? (?  i  b C F i AlK41825166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:12:10 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:12:22 2: CUL_0WS: unknown message ? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:12:30 2: CUL_0WS: unknown message ? (? (? (? ( is unk W X e f mK0197615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:12:31 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:12:33 2: CUL_0WS: unknown message ? (? (? (? (? is unRV W K5175116818 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:14:46 2: CUL_0WS: unknown message ? (? (? (? (? (? isi F i A Z EK1799700700AEC815K1198010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:14:50 2: CUL_0WS: unknown message ? (? (? (? (? (? (?knK41814166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:15:15 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:15:16 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:15:27 2: CUL_0WS: unknown message ? (? (? (? (?  is uK V W X e K0197615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:15:28 2: CUL_0WS: unknown message ? (? (? (? (? (?  i B b C F i K5175116 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:16:56 2: CUL_0WS: unknown message ? (? (? (? (? (? (? b C F i A Z E G M K1799700700AEC814 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:17:45 2: CUL_0WS: unknown message ? (? (? (? (? (? (?wnK41814166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:18:19 2: CUL_0WS: unknown message ? (? (? (? (? (? (?ui A Z E G lK61 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:18:22 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:18:24 2: CUL_0WS: unknown message ? (? ( is u is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:19:29 2: CUL_0WS: unknown message ? (? (? ( is u is uB V W X e fK1799700 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:20:40 2: CUL_0WS: unknown message ? (? (? (? ( is u ib C F i A K41814166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:20:58 2: CUL_0WS: unknown message ? (? (? (? (? ( is  B b C F i XK2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:21:13 2: CUL_0WS: unknown message ? (? (? (? (? (? ( uf B b C F K61772167FC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:21:13 2: CUL_0WS: unknown message ? (? (? (? (? (? (? B b C F i K6177216737 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:21:17 2: CUL_0WS: unknown message ? (? (? (? (? (? (?F B b C F K5175616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:21:21 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A ZK0197615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:23:35 2: CUL_0WS: unknown message ? (? (? (? (? (? (?nB b C F iK179970 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:23:56 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A Z E G M K7191916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:24:07 2: CUL_0WS: unknown message ? (? (? (? (? (? (? one of B is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:24:11 2: CUL_0WS: unknown message ? (? (? (? (? (? (?Z E G M K UK517561671C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:24:12 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  B b C F iK5175616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:24:18 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:26:30 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e f K1799700700AEC813K41814166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:27:01 2: CUL_0WS: unknown message ? (? (? (? (? (?  is8known) Use one oK61762167FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:27:06 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  one of B b C F iK5175116 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:29:25 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:29:25 2: CUL_0WS: unknown message ? (? (? (? (? ( is T V W X e K4181416637 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:29:43 2: CUL_0WS: unknown message ? (? (? (? (? (? ( iB b C F i K1798700700AEB81K7191516414 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:29:47 2: CUL_0WS: unknown message ? (? (? (? (? (? (? nown) Use one ofxK2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:30:02 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:30:12 2: CUL_0WS: unknown message ? (? (? (? (? ( is uT V W X K0197615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:32:36 2: CUL_0WS: unknown message ? (? (? (? (? (? (  b C F i AK1798700700AEB81K7191516414 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:32:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?0oBK2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:32:49 2: CUL_0WS: unknown message ? (? (? (? (? (? (? i A Z E GK61772167FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:32:55 2: CUL_0WS: unknown message ? (? (? (? (? (? (? B b C F iK517561671A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:32:55 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:33:09 2: CUL_0WS: unknown message ? (? (? (? (? is unV W X e ftK0197615806 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:35:15 2: CUL_0WS: unknown message ? (? (? (? (? (? is B b C F iK1798700700AEB81K41814166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:35:30 2: CUL_0WS: unknown message ? (? (? (? (? (? (?obK7191916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:35:39 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:35:50 2: CUL_0WS: unknown message ? (? (? (? (?  is un V W X e f m l tK5174616738 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:38:10 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:38:23 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:38:37 2: CUL_0WS: unknown message ? (? (? (? (? is unknV W X e K6176216737 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:38:44 2: CUL_0WS: unknown message ? (? (? (? (? (? isfB b C F i A K517511681C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:39:03 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:39:49 2: CUL_0WS: unknown message ? (? (? (? (?  is u  V W X e fK1798700700AEB816 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:41:05 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:41:17 2: CUL_0WS: unknown message ? (? (? (? (?  is uo V W X e f K7190916416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:41:30 2: CUL_0WS: unknown message ? (? (? (? (? (?  inf B b C FK2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:41:38 2: CUL_0WS: unknown message ? (? (? (? (? (? (?B b C F i AK517411681C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:41:39 2: CUL_0WS: unknown message ? (? (? (? (? (? (?6 B b C F xK5174116 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:42:00 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:43:30 2: CUL_0WS: unknown message K84
2014.06.19 05:43:30 2: CUL_0WS: unknown message ? (? (? (? (? ( is KT V W X eK1798700700AEB81K84F3 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:44:10 2: CUL_0WS: unknown message ? (? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:44:10 2: CUL_0WS: unknown message ? (? (? (? (? (? is T V W X eK1198010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:44:27 2: CUL_0WS: unknown message ? (? (? (? (? (? (?B b C F i K21 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:44:33 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:44:57 2: CUL_0WS: unknown message ? (? ( is u is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:46:55 2: CUL_0WS: unknown message ? (? (? ( is u is u V K41804166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:46:55 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:47:04 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:47:07 2: CUL_0WS: unknown message ? (? (? (? (? (?  iB b C F i A Z E G K1198010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:47:54 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:47:54 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:49:50 2: CUL_0WS: unknown message ? (? (? (? (? is unknVK4180416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:49:57 2: CUL_0WS: unknown message ? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:50:04 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:50:13 2: CUL_0WS: unknown message ? (? ( is unknown) UUK61772167FB is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:50:13 2: CUL_0WS: unknown message ? (? (? ( is unknowi A Z E G K6177216736 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:50:22 2: CUL_0WS: unknown message ? (? (? (? ( is unknoB b C F itK5174616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:52:45 2: CUL_0WS: unknown message ? (? (? (? (? ( is u b C F i A Z E G K1797700700AEA81K41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:52:51 2: CUL_0WS: unknown message ? (? (? (? (? (? (  im K7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:53:16 2: CUL_0WS: unknown message ? (? (? (? (? (? (? F i A Z  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:53:48 2: CUL_0WS: unknown message ? (? (? (? (? (? (? Z E G M K K0197 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:53:48 2: CUL_0WS: unknown message ? (? (? (? (? (? (? F i A Z EK0197615836 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:55:40 2: CUL_0WS: unknown message ? (? (? (? (? (? (? BK1798700700AEB816K41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:55:57 2: CUL_0WS: unknown message ? (? (? (? (? (? (?De one of is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:56:10 2: CUL_0WS: unknown message ? (? (? (? (? (? (?Z E G M K K2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:56:11 2: CUL_0WS: unknown message ? (? (? (? (? (? (?B b C F i AK2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:56:11 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  B b C F K5174616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:56:45 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A K0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:57:36 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:58:35 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:58:38 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:59:05 2: CUL_0WS: unknown message ? (? (? (? (?  is unk  V W X K5 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:59:07 2: CUL_0WS: unknown message ? (? (? (? (? (?  ii A Z E G MRK216501 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 05:59:42 2: CUL_0WS: unknown message ? (? (? (? (? (? (?b C F i A ZK01966 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:01:31 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:01:49 2: CUL_0WS: unknown message ? (? (? (? is unkno X e f m l K61772167FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:01:50 2: CUL_0WS: unknown message ? (? (? (? (? is un  B b C F  K1198010022 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:02:00 2: CUL_0WS: unknown message ? (? (? (? (? (? is K5174616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:02:03 2: CUL_0WS: unknown message ? (? (? (? (? (? (? Z E  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:02:39 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:03:58 2: CUL_0WS: unknown message K84
2014.06.19 06:03:58 2: CUL_0WS: unknown message ? (? ( is un is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:04:25 2: CUL_0WS: unknown message ? (? (? ( i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:04:54 2: CUL_0WS: unknown message ? (? (? (? ( i is unkC V W X e is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:05:36 2: CUL_0WS: unknown message ? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:07:18 2: CUL_0WS: unknown message ? (? (? (?  is unknwW X e f m K7190916416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:07:20 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:07:49 2: CUL_0WS: unknown message ? (? (? (? (? ( is un T V W X e f m l K517461671C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:07:55 2: CUL_0WS: unknown message ? (? (? (? (? (? ( le one of B b C F K2165010 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:10:12 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:10:15 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:10:31 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:10:43 2: CUL_0WS: unknown message ? (? (? (? (? is unknVK517461671C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:11:30 2: CUL_0WS: unknown message ? (? (? (? (? (? is u i A Z EK0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:13:10 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:13:25 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK6176 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:13:38 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:13:38 2: CUL_0WS: unknown message ? (? (? ( i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:13:46 2: CUL_0WS: unknown message ? (? (? (? ( i is u V W X e f mK2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:15:59 2: CUL_0WS: unknown message ? (? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:16:05 2: CUL_0WS: unknown message ? (? (? (? (? (? isn T V W X K4180416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:16:19 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A K61762167FD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:16:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?n b C F i K2165010 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:17:24 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A ZK0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:18:36 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:18:52 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:19:13 2: CUL_0WS: unknown message ? (? (? (? (? (?  isB b C F iK617621 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:19:27 2: CUL_0WS: unknown message ? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:19:39 2: CUL_0WS: unknown message ? (? (? (?  is unknowVW X e f m l t u K216501 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:21:31 2: CUL_0WS: unknown message K84
2014.06.19 06:21:31 2: CUL_0WS: unknown message ? (? (? (? (?  is u e of B b is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:21:46 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:21:55 2: CUL_0WS: unknown message ? (? (? (? (?  is uA V W X e fK41804 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:22:07 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:22:21 2: CUL_0WS: unknown message ? (? (? (? is unkno  X e f m lK517461671A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:23:18 2: CUL_0WS: unknown message ? (? (? (? (? is un1 B b C F i A Z E K1702710700AEC813K0196615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:24:39 2: CUL_0WS: unknown message ? (? (? (? (? (? is8  K7190 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:24:50 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:25:01 2: CUL_0WS: unknown message ? (? (? ( is unknownX e f m l K61762167FE is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:25:16 2: CUL_0WS: unknown message ? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:25:22 2: CUL_0WS: unknown message ? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:25:30 2: CUL_0WS: unknown message ? (? (? (? ( is unk  W X e f K2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:25:34 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:26:15 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:27:22 2: CUL_0WS: unknown message K84
2014.06.19 06:27:22 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:27:45 2: CUL_0WS: unknown message ? (? (? (? (?  is unk  V W X e f m l t K41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:28:10 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:28:11 2: CUL_0WS: unknown message ? (? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:29:12 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:30:26 2: CUL_0WS: unknown message ? (? (? (? (? ( is tK7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:30:39 2: CUL_0WS: unknown message ? (? (? (? (? (? ( i A Z E G M K1706710700AE0816 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:30:40 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:31:05 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK517461671A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:32:09 2: CUL_0WS: unknown message ? (? (? (? (? (?  iBK019661580A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:33:11 2: CUL_0WS: unknown message ? (? (? (? (? (? (?K A Z E G MK1706710700AE0816 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:33:35 2: CUL_0WS: unknown message ? (? (? (? (? (? (? one of B bxK41814166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:33:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?f B b C F K61 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:33:43 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:33:59 2: CUL_0WS: unknown message ? (? (? is unknown) K517461671C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:34:18 2: CUL_0WS: unknown message ? (? (? (? is unkno A Z E G M K2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:34:19 2: CUL_0WS: unknown message ? (? (? (? (? is un B b C F i K2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:35:06 2: CUL_0WS: unknown message ? (? (? (? (? (? is  B b C F iEK0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:36:13 2: CUL_0WS: unknown message ? (? (? (? (? (? (?1f B b C F K1708710700AE2816K7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:36:30 2: CUL_0WS: unknown message ? (? (? (? (? (? (?koK41814166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:36:37 2: CUL_0WS: unknown message ? (? (? (? (? (? (?ei A Z E G K6 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:36:54 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:36:54 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:37:15 2: CUL_0WS: unknown message ? (? (? (? (?  is uM V W X eK2165010038 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:38:03 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:39:25 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e K1708710700AE2816K4181416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:39:31 2: CUL_0WS: unknown message ? (? (? (? (? (?  i) K61762167FC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:40:04 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:41:00 2: CUL_0WS: unknown message ? (? (? (? (? ( is uT V W X e f m l K1708710700AE281K0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:42:20 2: CUL_0WS: unknown message ? (? (? (? (? (? ( is is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:42:25 2: CUL_0WS: unknown message ? (? (? (? (? (? (? K U Y R T K6176216 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:43:01 2: CUL_0WS: unknown message ? (? (? (? (? (? (?b C F i AZK1198 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:43:06 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:43:07 2: CUL_0WS: unknown message ? (? (? ( is is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:43:57 2: CUL_0WS: unknown message ? (? (? (? ( is is unTK17 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:44:54 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:45:15 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:45:19 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:45:38 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e f K51746 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:46:02 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:46:54 2: CUL_0WS: unknown message ? (? (? (? i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:48:10 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:48:13 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:48:32 2: CUL_0WS: unknown message ? (? (? (? (? ( is BT V W X e K5174616 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:48:58 2: CUL_0WS: unknown message ? (? (? (? (? (? ( b C F i A ZK2165 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:49:51 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:50:41 2: CUL_0WS: unknown message ? (? (? ( is unknow X e f m K7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:51:05 2: CUL_0WS: unknown message ? (? (? (? ( is unk b C F i A K1710610700AEA816K41804166DC is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:51:07 2: CUL_0WS: unknown message ? (? (? (? (? ( is uk K617621 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:52:48 2: CUL_0WS: unknown message ? (? (? (? (? (? (  Z E G M KK0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:53:35 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:54:00 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:54:02 2: CUL_0WS: unknown message ? (? (? (? (?  is us V W X e K6176216737 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:54:21 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:55:45 2: CUL_0WS: unknown message ? (? (? (? (? ( is uT V W X e f m l  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:56:55 2: CUL_0WS: unknown message ? (? (? (? (? (? (  C F i A Z E G M KK41804166DE is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:56:55 2: CUL_0WS: unknown message ? (? (? (? (? (? (? oK4180416637 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:57:16 2: CUL_0WS: unknown message ? (? (? (? (? (? (?i A Z E G MK5174116818 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:58:42 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 06:59:49 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:00:10 2: CUL_0WS: unknown message ? (? (? (? (?  is u  V W X e K517461671B is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:00:42 2: CUL_0WS: unknown message ? (? (? (? (? (?  iB b C F i K2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:01:39 2: CUL_0WS: unknown message ? (? (? (? (? (? (? B b C F itK1712610700AEC81K0196615 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:02:15 2: CUL_0WS: unknown message ? (? (? (? (? (? (?n)K7189916414 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:02:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?9i A Z E G K6176216 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:02:45 2: CUL_0WS: unknown message ? (? (? (? (? (? (?b C F i A ZK41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:03:05 2: CUL_0WS: unknown message ? (? (? (? (? (? (?0 B b C F i K517461671A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:04:36 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:05:09 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e f K7189916414 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:05:37 2: CUL_0WS: unknown message ? (? (? (? (? (?  i B b C F i K61762167FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:05:40 2: CUL_0WS: unknown message ? (? (? (? (? (? (?u B b C F iK4180416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:05:59 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:07:33 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:02 2: CUL_0WS: unknown message ? (? (? (? is unkno X e f m lK7190916418 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:19 2: CUL_0WS: unknown message K84
2014.06.19 07:08:19 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:31 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e f K61762167FD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:35 2: CUL_0WS: unknown message ? (? (? (? (? (?  i  B bK41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:35 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  F i A Z EK418041 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:54 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A ZK517461671A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:08:54 2: CUL_0WS: unknown message ? (? (? (? (? (? (? B b C F i K5174616737 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:09:29 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:09:30 2: CUL_0WS: unknown message ? (? (? (? (? ( is unT V W X K2165010023 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:10:56 2: CUL_0WS: unknown message ? (? (? (? (? (? ( iB b C F i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:11:30 2: CUL_0WS: unknown message ? (? (? (? (? (? (? Z E G M K K1714610700AEE81K41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:13:27 2: CUL_0WS: unknown message ? (? (? (? (? (? (?1nown) Use one ofK0195615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:13:52 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:14:25 2: CUL_0WS: unknown message ? (? (? (? (? ( is unT V W X eK41804166DD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:14:43 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:16:24 2: CUL_0WS: unknown message ? (? (? (? (? is unV W X e f mK1718610 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:16:43 2: CUL_0WS: unknown message ? (? (? (? (? (? isb C F i A ZK7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:17:13 2: CUL_0WS: unknown message ? (? (? (? (? (? (?i B b C F itK is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:17:14 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:17:20 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:17:37 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:18:19 2: CUL_0WS: unknown message ? (? (? is u is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:19:21 2: CUL_0WS: unknown message ? (? (? (? is u is uT V W X e f m l tK0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:20:01 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:20:15 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:20:32 2: CUL_0WS: unknown message ? (? (? (? (? ( is uT V W is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:21:16 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:22:18 2: CUL_0WS: unknown message ? (? ( is is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:22:30 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:23:01 2: CUL_0WS: unknown message ? (? (? ( is unknown)VX e f m lK6176216 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:23:10 2: CUL_0WS: unknown message ? (? (? (? ( is unk b C F i A K41804166E0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:23:26 2: CUL_0WS: unknown message ? (? (? (? (? ( is  B b C F iK517411681A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:24:01 2: CUL_0WS: unknown message ? (? (? (? (? (? ( B b C F i AK1719510700AE2815 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:24:11 2: CUL_0WS: unknown message ? (? (? (? (? (? (?one of B bK2 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:24:12 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:25:15 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:29:15 2: CUL_0WS: unknown message ? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:31:09 2: CUL_0WS: unknown message ? (? ( i is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:31:10 2: CUL_0WS: unknown message ? (? (? ( i  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:31:55 2: CUL_0WS: unknown message ? (? (? (? ( i  is uT V W X e f m l K41804166E0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:34:04 2: CUL_0WS: unknown message ? (? (? (? (? ( i  ione of B b C F i K7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:34:06 2: CUL_0WS: unknown message ? (? (? (? (? (? (  K0196615807 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:34:37 2: CUL_0WS: unknown message ? (? (? (? (? (? (? A Z E G M K1724510700AEE81K61762167FD is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:34:50 2: CUL_0WS: unknown message ? (? (? (? (? (? (?n)K41804166E0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:35:04 2: CUL_0WS: unknown message ? (? (? (? (? (? (?i A Z E G K517411681A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:36:44 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:36:57 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:37:03 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:37:31 2: CUL_0WS: unknown message ? (? (? (? (? ( is eT V W X e K6176216 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:39:17 2: CUL_0WS: unknown message ? (? (? (? (? (? ( bK1724410700AED814 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:39:51 2: CUL_0WS: unknown message ? (? (? (? (? (? (?n C F i A K71909164 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:40:01 2: CUL_0WS: unknown message ? (? (? (? (? (? (? b C F i A K0196615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:40:26 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:40:40 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:40:53 2: CUL_0WS: unknown message ? (? (? (? (?  is u V W X e fK517411681C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:41:47 2: CUL_0WS: unknown message ? (? (? (? (? (?  isB b C FK2165010037 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:42:44 2: CUL_0WS: unknown message ? (? (? (? (? (? (? b C F i A Z E G M K7190916416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:43:20 2: CUL_0WS: unknown message ? (? (? (? (? (? (?6e one of B b C FKK6176216736 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:43:48 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:44:22 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:44:43 2: CUL_0WS: unknown message ? (? (? (? (?  is un V W X e fK2165010 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:45:38 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:45:54 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:46:13 2: CUL_0WS: unknown message ? (? (? (? (?  is uT V W X e K61762167FE is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:46:30 2: CUL_0WS: unknown message ? (? (? (? (? (?  iB b C F i AK41804166E1 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:48:31 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  B b C F i K7190316517 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:48:51 2: CUL_0WS: unknown message ? (? (? (? (? (? (?nf B b C F K0196615808 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:49:25 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  B b C F K4180416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:49:37 2: CUL_0WS: unknown message ? (? (? (? (? (? (? C F i A K1727310700AEF81K5174 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:50:35 2: CUL_0WS: unknown message ? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:50:35 2: CUL_0WS: unknown message ? (? (? ( is unknowX e f m l tK2165010037 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:51:48 2: CUL_0WS: unknown message ? (? (? (? ( is unkk B b C F itK019661 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:52:02 2: CUL_0WS: unknown message ? (? (? (? ( is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:52:31 2: CUL_0WS: unknown message ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:53:31 2: CUL_0WS: unknown message ? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:53:37 2: CUL_0WS: unknown message ? (? (? (? is unkno  X e f mK1198010036 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:53:37 2: CUL_0WS: unknown message ? (? (? (? (? is uns b C F i A is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:54:18 2: CUL_0WS: unknown message ? (? (? (? (? (? isA Z E G M K7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:54:45 2: CUL_0WS: unknown message ? (? (? (? (? (? (?B b K17 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:54:55 2: CUL_0WS: unknown message ? (? (? (? (? (? (? E G M K U K61762167FE is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:54:56 2: CUL_0WS: unknown message ? (? (? (? (? (? (? B b C F i K6176216736 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:55:15 2: CUL_0WS: unknown message ? (? (? (? (? (? (?s B b C F i K41804166E0 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:55:26 2: CUL_0WS: unknown message ? (? (? (? (? (? (? f B b C F K517311681C is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:56:27 2: CUL_0WS: unknown message ? (? (? (?  is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:57:12 2: CUL_0WS: unknown message ? (? (? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:57:42 2: CUL_0WS: unknown message ? (? (? (? (? is unnV W X e f K0195615805 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:57:49 2: CUL_0WS: unknown message ? (? (? (? (? (? is6 B b C F iK6176216 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:58:10 2: CUL_0WS: unknown message ? (? (? (? (? (? (?bK41804166E1 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 07:59:23 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  A Z E G M K U Y K2164010024 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 08:00:05 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  one of B b C F YK7190916415 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 08:00:43 2: CUL_0WS: unknown message ? (? (? (? (? (? (?  one of B b C F K61762167FF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 08:01:05 2: CUL_0WS: unknown message ? (? (? (? (? (? (? one of B b C F iMK4180416 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.19 08:02:19 2: CUL_0WS: unknown message ? (? (? (? (? (? (?Fe of B b C F i A K1730 is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 22 Juni 2014, 12:09:15
Zitat
auf Seite 31 der cc1101 Doku steht es in Table 23: Status Byte Summary.
Das war bei mir auf Seite 26, ich sollte meine Dokumente erneuern. Ich habs eingebaut, und getestet: CUL_V4 funktioniert, auch ein CUL V1.1 als Basis mit einem "neuen" CUL V2.1 als RFR. Habs als 1.60 eingecheckt, damit wir Probleme einfacher eingrenzen koennen.

Zitat
Allerdings führt das immer noch vorhandene (vermutlich) USB Problem trotz CUL_WS Konfiguration (also nur Empfang) zu folgenden Einträgen mit PLL0:
Ich war bisher ueberzeugt, dass diese Probleme von der anderen Seite (Linux/etc) stammen, weil da echo aktiviert ist.
Bin inziwschen nicht mehr so sicher.

Zitat
CUL_0WS: unknown message K00
Sowas ist "normal", ich (oder jemand sonst :) muesste endlich mal fuer das S300 Protokoll die Pruefung
des zweiten CRC-Nibbles einbauen, samt Minimallaenge.

Zitat
Hier noch mehr Log zum Problem:
Hilft mir nicht.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Juni 2014, 21:04:26
Hallo Rudolf,

Zitat
Ich war bisher ueberzeugt, dass diese Probleme von der anderen Seite (Linux/etc) stammen, weil da echo aktiviert ist.
Bin inzwschen nicht mehr so sicher.

Echo ist (zumindest bewust) nicht an. Sonst müsste es bei AskSin auch immer auftreten, wenn empfangene Sensordaten an den RasPi geschickt werden.

Ich habe mit CDC_Task nun einige Varianten durch, um dem Problem näher zu kommen. Aber einer Lösung hat mich das noch nicht näher gebracht.

CDC_Task fest gegen Interrupt- Reentranz zu machen, macht Sinn. Denn

Hilft aber nicht wirklich gegen das Problem.

Dafür bin ich aber noch auf folgenden Beitrag zu LUFA gestoßen, was mir vom Verhalten her ähnlich scheint und mit einem LUFA Update Besserung bringen könnte:

https://code.google.com/p/lufa-lib/issues/detail?id=21 (https://code.google.com/p/lufa-lib/issues/detail?id=21)

In der Doku zum ATmega32U4 bin ich auch schon auf das Speichermanagement des DPRAM für Endpoint Bänke gestossen. Aber ob die TX Bank mal (durch ein USB "Ereignis") freigegeben werden kann und damit ein Problem auftreten könnte, ist mir nocht nicht klar.

Da ich aber sonst bisher keinen andren Grund im Quelltext der Firmware habe finden können, bleibt mir derzeit nur der LUFA Code als Fehlerquelle übrig(, so mir denn USB-Hub und RasPi keinen Streich spielen).

Das einzige, was mir auffällt, ist, dass die CUL die nur auf CUL_WS läuft, also bis auf die Initialisierung eigentlich keine Daten mehr vom Host bekommen sollte, das Problem drastischer zeigt, als die die auf CUL_HM läuft und immer mal wieder Sendedaten vom Host bekommt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 24 Juni 2014, 00:34:57
Hallo Rudolf,

hier habe ich mal zwei markannte Log-Einträge:

2014.06.23 13:05:50 2: CUL_0: unknown message ? (7812345678123456781234567812345678123As1078A011F1103417832D0201290320FFFF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.23 16:48:59 2: CUL_0: unknown message ? (7812345678123456781234567812345678123As10B5A011F1103417832D0201230320FFFF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

die "7812345678123456781234567812345678123" müssen noch von ein Ping-Test stammen, den ich heute morgen noch losgelassen habe.

Der Ping war lang, so dass er gerade komplett in den Befehlspuffer passte:

Ap123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456

die Antwort war dann so was:

AFF02009D66223F12345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345680

Das Muster der Pingdaten hat sich also über Stunden erhalten. Und es ist die gleiche Anzahl an Bytes (37), die da im Eingabestrom vor dem eigentlichen Sendebefehl landen. Andere Log-Einträge sind nicht aufgetreten (außer einigen PLL0 Meldungen).

Die CUL ist auf CUL_HM eingestellt und sendet und empfängt regelmäßig Daten.

D.h. die TTY-Ringbuffer sind in der Zeit schon mehrfach überschrieben worden. Da kann es nicht herkommen.

Der Code für den Befehlspuffer in analyze_ttydata arbeited mit Feldoffset. Da kann sich das Muster nicht drin erhalten haben, schon gar nicht vor dem Sendebefehl.

Dann bleiben als Fehlerkandidaten auf CUL Seite nur noch die USB-Bänke übrig. Die TX-Bank wird üblicherweise bei den Empfangsdaten nicht voll genutzt. D.h. da können sich Daten von dem langen Ping erhalten. Gleiches gilt für die RX-Bank, da die Sendebefehle auch kürzer als 64 Bytes sind.
D.h. beide Bänke wären prinzipiell Kandidaten. Da bei CUL_WS aber CUL anscheinend Ausgabedaten im Empfangsbuffer landen mutmaße ich mal, dass es auch hier ehemalige Sendedaten sind.
Die 37 kann auch durch Fragmente von CR/LF verfälscht sein, da CR/LF ja in analyze_ttydata unter den Tisch fallen können.

Das ist schon alles seltsam, auch wenn es auf der Gegenseite beim USB-Hub oder RasPi passieren sollte.

Fällt Dir dazu noch was auf oder ein?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 24 Juni 2014, 08:24:57
Nicht wirklich
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 November 2014, 16:31:32
Hallo Martin,

hier eine neue Test-Version für CUL_V3 für TimeStamp.

In Sachen USB habe ich Stabilitätsverbesserungen in der Firmware erzielen können.
Allerdings hat auch mein RasPi seinen Teil zum USB-Problem beigetragen. Aktives plotfork führt zu USB Problemen auf dem RasPi, wie ich empirisch herrausgefunden habe. Plotfork auf dem RasPi also abschalten.

PLL-Lock Check ist natürlich auch drin.

Credits10ms laufen damit auch unter ASKSIN und begrenzen die Sendezeit, wie es sein sollte. Hier kanst Du die Rückmeldungen (s.u.) zur Optimierung oder Begrenzung für sendezeithungrige Geräte nutzen.

Bei den TimeStamps habe ich erweitert.
Das Codeformat hat sich geändert in FFxy, wobei y den Typ kennzeichnet und x eine grobe Auskunft über den Stand der Credits10ms liefert.

Hier die Definitionen aus dem Quellcode, die das erläutern:

#  define TS_ID_RECTIME 0xff01 // Receive TimeStamp

# ifdef HAS_ASKSIN_PING
#  define TS_ID_PING 0xff02 // Ping Receive TimeStamp
# endif

# ifdef HAS_ASKSIN_SEND_TIMESTAMP
#  define TS_ID_SENDSUCC 0xff03 // Send Success TimeStamp
#  define TS_ID_SENDFAIL 0xff04 // Send Fail TimeStamp, failed due to switch to TX, channel not free
#  define TS_ID_SENDFAIL_CREDIT 0xff05 // Send Fail TimeStamp, failed due to not enough credits
#  define TS_ID_SENDFAIL_LEN 0xff06 // Send Fail TimeStamp, failed due to message lenght error
# endif // HAS_ASKSIN_SEND_TIMESTAMP


// credit level Ids, are ored to Timestamp ID
#  define TS_ID_CREDIT_OK 0x00        // credits <= 3600
#  define TS_ID_CREDIT_HALF 0x10 // credits < 1800 (< 50% of hourly sendtime left)
#  define TS_ID_CREDIT_QUARTER 0x20 // credits < 900 (< 25% of hourly sendtime left)
#  define TS_ID_CREDIT_LOW 0x30 // credits < 360 (< 10% of hourly sendtime left)
#  define TS_ID_CREDIT_NOBURST 0x40 // credits < 37 (not enough credits for another burst message)
#  define TS_ID_CREDIT_NONE 0x50 // credits < 2 (not enough credits for another message at all)

TimeStamps kommen nun auch beim Senden mit den IDs FFx3 bis FFx6 und liefern den Zeitpunkt des Sendens (oder des Fehlers), und liefern damit etwas Feedback zum Sendeerfolg und grob für ein Credits Management.

In der angehängten Zip Datei sind sowohl Hex File für CUL_V3, als auch der Quelltext dazu und auch ein adaptiertes 00_CUL.pm enrhalten, das derzeit nur die Empfangssnachrichten weitergibt und die Sendefeedbacknachrichten ausfiltert.

Da ich wegen Problemen mir KS Sensoren auch kräftig am SlowRF Empfang und Dekodieren geändert habe, kann ich aus meinen Tests mit CUL und COC sagen, dass meine ELV KS-Wetterstationssensoren, WS2000 Repeater und ein TX3 Sensor und meine Homematic-Sensoren/Aktoren funktionieren.

Andere SlowRF Protokolle und auch der RF-Router wären von freiwilligen Testern :) noch zu testen.
Probleme mit dieser Testversion bitte hier melden, da es zum Teil erhebliche Abweichungen zum bisherigen Code gibt und mich natürlich interessiert, welche Unschärfen trotz aller Mühe ggf. noch verblieben sind und ich die auch korrigieren möchte.

Wenn die PLL Nachrichten stören, lassen sie sich mit AP1 bis um nächsten Reset abschalten.
PLL35 zeigt wiederholte Versuche der Umschaltung auf Sendebetrieb an und sind erst mal nicht bedenklich.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 01 November 2014, 23:07:04
Hallo Ansgar,

die neue Kombi aus FW und modifizierter 00_CUL.pm mit Timestamps funktioniert in meiner HM Umgebung einwandfrei. Meine Test-Suite mit den immer etwas kritischen getConfigs auf die RT-DNs läuft fehlerfrei und erstmals sogar ganz ohne Resends.

Die PLL-Lock Checks und vor allem aber die TimeStamps haben die Stabilität und das HM Timing mit CUL definitv verbessert.  Möchte ich daher nicht mehr missen :)

@Rudolf - Wann bekommen wir das im Standard?

Vielen Dank für die Arbeit, Gruß
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 01 November 2014, 23:47:56
Wenn ich einen Patch (== diff -u) sehe, dann kann ich das beurteilen.
Je groesser der Patch, desto eher kommt es hinten in meine TODO Liste.
Und wichtig: ein Patch == ein Problem.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 November 2014, 15:24:57
Hallo Rudolf,

ich habe mit Blick auf Deine übrigen Supportbemühungen größtes Verständnis für Deine Haltung und Vorgehensweise. Daher habe ich auch eine Testversion für Martin bezüglich erweiterterter TimeStamps und willige Tester für alle Änderungen gepostet.

Ich habe ein ureigenes Interesse, meine KS, TX3 und Homematic Sensoren stabil zu empfangen und mit Homematic zu meinen Aktoren stabil senden zu können. Insbesondere, da es kühler wird und alles laufen soll.
ks_send war ein nettes Spiel am Rande, was ich aber auch ändern und testen musste, wegen der Checksummenänderungen an KS.

Die Empfangs-TimeStamps haben sich bei mir positiv ausgewirkt. Und ein CUL bei mir profitiert in Sachen Stabilität deutlich von den PLL-Lock Änderungen.

Wirf bitte mal einen Blick in rf_receive.c aus der Quellcode zip. Das ist in großen Teilen geändert und umsortiert (weil das auch noch mal ein paar wenige Bytes Veränderung bewirkt hat). Auch mit einem diff -u würdest Du es nach bisheriger Erfahrung ans Ende des Endes Deiner ToDo Liste schieben oder wegen zu aufwändig ablehnen. Aber vielleicht weckt es trotzdem Dein Interesse.

Immerhin funktioniert damit der Empfang aller meiner KS Sensoren, auch der Helligkeitssensor S2500H und auch die WS2000 Repeater.
Der Helligkeitssensor funktionierte zuvor nicht, weil die Checksummenauswertung bezüglich ungerader/gerader Nibblezahl nicht sauber war (und war nach erfolglosen Antennen- und Batterieexperimenten schon kurz vor dem Mülleimer  ;)). Das machte dann wieder Anpassungen in rf_send erforderlich...
Und die WS2000 Repeater sind schon im Sendetiming (mit Oszi vor dem Sender gemessen) sehr variabel und dass schon beim Sync (und ich habe mich zuvor gewundert, warum die ELV Empfänger sehr häufig von den Repeatern was empfingen, aber CUL nur sehr selten). Daher habe ich die Sync-Detection verändert und auch ein Umtastprotokoll-Collect ergänzt, sowie eine Variation in der Timingempfindlichkekt ergänzt.
TX3 wird nun schon im Sync erkannt und das konnte ich ebenfalls testen, weil ich einen Temperatursensor dafür habe.

Wenn Du andere SlowRF Protokolle und den RFRouter testen kannst, herzlich gerne. Mir fehlt leider die Hardware dazu. Wenn Du darin Probleme siehst, mach ich mir gerne Gedanken dazu.

Da ich mich mit SlowRF nun intensiv auseinander gesetzt habe, habe ich nun auch verstanden, warum Du bei cli()/sti() empfindlich reagierst und alles geänderte, was eine Interruptabschaltung erfordert, so knapp wie möglich gehalten, um das SlowRF Empfangs-Timing minimalst zu stören.

Mit COC kann man übrigens in dieser Testversion auch mal das SlowRF Empfangstiming in Textform über ganze Messages in lesbarer Form ins Log bekommen (HAS_RF_RECEIVE_RECORD definiert und REP_LCDMON gesetzt). Mit CUL geht das mangels Speicher leider nicht.

Und ein Blick in rf_asksin.c ist angebracht, da darin die Begründung für die Creditsanwendung auf ASKSIN steht.

Zitat
ein Patch == ein Problem

Ich komme mit der Summe Deiner Wünsche und gefundener Probleme leider nicht drumherum, an vielen Schrauben zu drehen, insbesondere der Wunsch nach geringem Programmspeicherbedarf erfordert immer wieder die Suche nach ein paar Bytes, die noch für CUL_V2 raus zu kitzeln sind, respektive bedingte Compilierung, da ich für alle Ergänzungen für CUL_V2 nicht genügend freie Bytes habe finden können.

Da ich dabei jeweils meine CC1101 Änderungen verwende, benötige ich diese auch. Ebenso die Erweiterung in display, clock und die weiteren Änderungen.
Das alles in kleine Patches zu zerlegen, tut's bei mir leider nicht mehr. Das bekomme ich auch zeitlich nicht hin, respektive wäre auch unnütz, weil Du es erst in Summe verstehen kannst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: martinp876 am 02 November 2014, 16:06:16
Hallo Ansgar,

anbei meine Version des 00_CUL.pm.

ich habe deine Änderungen eingearbeitet und meine Timing-korrektur sowie die formatierten Logs bestehen lassen.
Leider hatte Rudi damals bereits die (für HM notwendigen) Änderungen verweigert - daher muss ich alles manuell nachziehen, was er ändert.

Ein grobtest deiner FW hat bei mir funktioniert. Auch die Timing-justierung scheint zu funktionieren.
Das Abschalten nach Sendezeitüberschreitung habe ich noch nicht probiert. Bekomme ich hier einen statusreport, wenn nicht gesendet wird?

Gruß Martin

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 02 November 2014, 16:21:44
Zitat
Das ist in großen Teilen geändert und umsortiert

Und genau das ist mein Problem. Ich will die Aenderungen verstehen, weil ich dafuer geradestehen muss bzw. ich support dafuer leiste. Und ich habe nicht die Zeit/Energie alles neu zu lesen, verstehen, und zu testen. Deswegen die bitte: moeglichst kurze Patches und ein Patch pro Problem. Wenn das nicht moeglich ist, dann kommt der Patch nicht rein.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: martinp876 am 02 November 2014, 19:11:48
schade
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 November 2014, 19:20:44
Hallo Martin,

bei jedem Senden kommt eine Antwort zurück.

Bei Erfolg ein A + FFx3 + TimeStamp + die an CUL gesendete Message ohne das "As". Das x gibt stets grob Info über die Credits, die noch zur Verfügung stehen, siehe auch die unteren 6 defines aus meiner letzten Erklärung dazu.

Bei Misserfolg kommt A + FFx4 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn der Kanal bis zum Timeout nicht frei war.
Oder A + FFx5 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn die Credits nicht für diese Message gereicht haben.
Oder A + FFx6 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn die zu sendene Message zu lang war, so dass in CUL der Sende-Umrechnungs-Puffer nicht reicht.

In 00_CUL.pm müsstest Du Dir ggf. noch was ergänzen, um im HM Modul zu erkennen, dass es nur Feedback war und es dann gesendeten Messages zuordnen.

Ebenfalls kommen jetzt A + FFx1 + TimeStamp + Empfangsnachricht.
Und als Antwort auf ein ApYYYYY kommt A + FFx2 + TimeStamp + YYYYY. Auch hier gibt x wieder grob Auskunft über die verfügbaren Credits.

Ich werde Deine 00_CUL.pm testen, danke!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 November 2014, 19:41:20
Hallo Rudolf,

kannst Du Dich denn mit dem Änderungsumfang des letzen PLL Änderungsvorschlags anfreunden?
Und darauf verzichten, dass es mit CUL_V2 läuft?

Wie klein die Patches sein dürfen, ist mir nicht klar. In "3-Zeilern" geht es nur mit sehr wenigen Änderungen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 03 November 2014, 09:28:54
Zitat
kannst Du Dich denn mit dem Änderungsumfang des letzen PLL Änderungsvorschlags anfreunden?
Nein, da ich fuer etwas, was mAn 5+1 Zeile erfordert, nicht 25k an Code einchecken will.


Zitat
Und darauf verzichten, dass es mit CUL_V2 läuft?
Kann dazu wenig sagen, ich weiss nicht wieviele CUL_V2 im Umlauf sind, bzw. wieviele davon fuer HM eingesetzt werden. Ich selbst habe zwar nur V2 in "produktiven" Einsatz, allerdings habe ich meine HM Geraete gegen ZWave ausgetauscht, da HM mir zu kompliziert geworden ist, und ich ZWave testen muss. Die beiden uebriggebliebenen CULs bedienen nur noch SlowRF.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 November 2014, 22:31:41
Hallo Martin,

die lange Pause hat leider etwas Informationsverlust zur Einheit der Timpstamps von 8ms gebracht.

Angehängt die Korrektur von 00_CUL.pm nebst geänderter Erkennung der Timestamp Option zum Test.

Bei mir läuft sie erst mal.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 04 November 2014, 13:43:05
Angehängt die Korrektur von 00_CUL.pm nebst geänderter Erkennung der Timestamp Option zum Test.

Hallo Ansgar, Martin,

die letzte Korrektur läuft bei mir perfekt (Testsuite 2x fehlerfrei durchlaufen). Diese Versionen (CULv3 99.65  und 00_CUL.pm) aus dem vorherigen Post werde ich erst mal so beibehalten.

Gute Arbeit, danke
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 November 2014, 21:20:03
Hallo Tobias, hallo Martin,

anghängt noch eine 00_CUL.pm Variante, die entsprechend Martins Vorschlag doch alle TimeStamps zur Delaykorrektur nutzt.

Gefühlt läuft die noch etwas besser, als die letzte.

@Tobias: Könntest Du die bitte auch nochmal testen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und Danke, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 07 November 2014, 12:27:11
Hallo Ansgar, Martin

anghängt noch eine 00_CUL.pm Variante, die entsprechend Martins Vorschlag doch alle TimeStamps zur Delaykorrektur nutzt.

Gefühlt läuft die noch etwas besser, als die letzte.
Kann ich nicht bestätigen - die vorherige Variante  (http://forum.fhem.de/index.php/topic,24436.msg214758.html#msg214758 (http://forum.fhem.de/index.php/topic,24436.msg214758.html#msg214758)) läuft bei mir besser.

set wz_Thermostat getConfig
set wz_Thermostat burstXmit

Beim getConfig auf den RT-DN gefolgt vom burstXmit habe ich jetzt reproduzierbar einen Resend und meistens (immer?) folgende Warnungen im Logfile:

2014.11.07 11:50:03 3: CUL_HM set wz_Thermostat getConfig
2014.11.07 11:50:04 3: CUL_HM set wz_Thermostat burstXmit
2014.11.07 11:50:11 1: PERL WARNING: Argument "8D" isn't numeric in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 2480.
...
2014.11.07 12:07:39 3: CUL_HM set wz_Thermostat getConfig
2014.11.07 12:07:39 3: CUL_HM set wz_Thermostat burstXmit
2014.11.07 12:07:41 1: PERL WARNING: Argument "D9" isn't numeric in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 2528.

Der hmInfo configCheck mault nach Auftritt einer obigen Warnung dann auch jeweils "missing Register list" an.
fhem> set hm configCheck

configCheck done:

 missing register list
    wz_Thermostat_Climate:      RegL_01:

Nach einem weiteren getConfig auf den entsprechenden Kanal ist dann alles wieder in Ordnung.

Gruß
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 November 2014, 22:10:02
Hallo Tobias, hallo Martin,

dann wieder angehängt die Variante mit delay Korrektur nur nach Empfangs TimeStamps.

Diesmal mit Kommentar im Quelltext zum Credits Stand in der TimeStamp.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 08 November 2014, 17:00:14
Hallo Ansgar, Martin,

ich habe jetzt mit der aktuellen Kombi (00_CUL und CULv3 FW mit Timestamps) ein Firmware Upgrade auf einen HM RT-DN versucht. Das geht aber schief, weil die 1% Regel zuschlägt. Vorher hatte ich stundenlang über die CUL keine Kommandos ausgesendet - der Stundenzähler muß also bei 0 gestartet sein.

2014-11-08 16:51:58 CUL_HM wz_Thermostat CMDs_FWupdate
2014-11-08 16:51:58 CUL_HM wz_Thermostat set_fwUpdate /opt/fhem/FHEM/firmware/RT_DN/hm_cc_rt_dn_update_V1_4_001_141020.eq3
2014-11-08 16:52:02 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f1301a00b048828274400caf1103421f220dec88647c79f8d69973b009fed97d7ac8e1add2edcf85e0aa0fef5ee690b80
2014-11-08 16:52:02 CUL myCULv3 UNKNOWNCODE 813204xx0101a001f1301a00b04c028274f00caf1103421f22044aa778ef813d0f02bac8854a9d1bec01d42ad51456f135a4c5
2014-11-08 16:52:05 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f1301a00b060428278b00caf1103421f2201b29a46f107728d54de3ce89770152ac68daf2ac6dc35ebb613382f02d1780
2014-11-08 16:52:05 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f1301a00b063a28279500caf1103421f220f98f9cb28781d18ad354bd0ec1fcbfd616609cf74c80
2014-11-08 16:52:06 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b066d28279e00caf1103421f220d02393eb7513858dd66854799d0dc533dbd58daa1e615c1
2014-11-08 16:52:06 CUL myCULv3 UNKNOWNCODE 812704xx0101a001f1301a00b0676201fa220caf1103421f220ef59c6b2aac691dc41fec2c0d53480
2014-11-08 16:52:09 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b07dd2827da00caf1103421f22083a6e5a2044ab79300eb455a11dd24e0f6b86994fb775780
2014-11-08 16:52:11 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f1301a00b08152827e500caf1103421f220a9d114dd6863e9a63cb7537e7110e236afe91542e280
2014-11-08 16:52:12 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09702827f800caf1103421f2203645e73e4fe946f1458f9b4fd9f4ba27d9131f132c0d80
2014-11-08 16:52:12 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09a328270100caf1103421f220c58b26437ee72b784a5bf9cf0a0ba5ccada165a8e7d87
2014-11-08 16:52:13 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09e028270e00caf1103421f2205dcff1b9f644c5eb5042249dfbbdb562eb3a348792e380
2014-11-08 16:52:20 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b0d752827b800caf1103421f2203c8244d3c8b6529b4226654b491aba303a68c155af4a6be
2014-11-08 16:52:22 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b0e492827de00caf1103421f220769b7145cfa33337dfe0ca4d63ad612ee58b1a8409cff8b6fb1e04b2ed4b80
2014-11-08 16:52:22 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b0e51201fe220caf1103421f220727dc5b9108609ae6fd27bd347ab
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b0ebd201ff620caf1103421f22035328f5903ab0d35a2872ebe3ada
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 813104xx0101a001f2301a00b0eea2827fc00caf1103421f220af9d0606ce251cd99c34f4df6368125acbf407c89b0756335
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b0ef3201f0020caf1103421f2200354318aa7753737eed4e283855bf4f3a26cfd37c47080
2014-11-08 16:52:24 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b0f3628270500caf1103421f220946304debe62f8564832dd7b657aee7f3fd587e48480
2014-11-08 16:52:24 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b0f6d28270f00caf1103421f220556e0e9aca89e7746b9cef8ff430a20d27fc6d1e7d80
2014-11-08 16:52:25 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b0fa528271a00caf1103421f220b9bc5ba199bb259bd8afb431c81517bd7a58e90087cc5
2014-11-08 16:52:26 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b104928273900caf1103421f22021c097ca13e168badd9423acff4268a684ecd7056a31ab2e5d5d72d87d7780
2014-11-08 16:52:26 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b107f28274300caf1103421f220233253166953ba4733511b720a384c634b2783d26a80
2014-11-08 16:52:27 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b10ea28275600caf1103421f2201e8d2b7e74bb2821753275a04e3c6721108d990c261eeb071a5032893e7f80
2014-11-08 16:52:27 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b10f3201f5a20caf1103421f2201370f65778d3243ec3aa9781c45
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b11c228277e00caf1103421f220a42bb529cdb2b00891d360288d7814dd635ba613ba9055f06172c56d469880
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b11cb201f8220caf1103421f2204dfb3435e1e9665626574ad775a
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b11f928278900caf1103421f2201cdbe03307150a08f04f6a88e4a0aa2b1285c8f22ac06
2014-11-08 16:52:30 CUL myCULv3 UNKNOWNCODE 812c04xx0101a001f2301a00b123428279500caf1103421f22051dea0a0f0b219fc24de576bdaaa317f5189544
2014-11-08 16:52:31 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b12962827a500caf1103421f2206757b16b747ab89294c96ab0e407f90d607509c11fd5af900e98d665667780
2014-11-08 16:52:31 CUL myCULv3 UNKNOWNCODE 812d04xx0101a001f2301a00b12cb2827af00caf1103421f220a8cea62ab47b8cdd3f03287c948ab7832528c08180
2014-11-08 16:52:32 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f2301a00b13362827c300caf1103421f2202586748598960c12737178327981544fd00f140524a66ad
2014-11-08 16:52:33 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b13a72827d900caf1103421f220cc0820bbe63082746b9c6ebe2a58896a1544b21123a91
2014-11-08 16:52:34 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f3301a00b14112827ec00caf1103421f220b2aa37854f8ede2c530f60888985899c30a8373a968b9
2014-11-08 16:52:35 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b148428270000caf1103421f220fffd39d1f36a51f69148b4be145f0898b3fd4a9e05d49f38f04ab74a488f80
2014-11-08 16:52:35 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b14f428271600caf1103421f220466768e3eef7b5bf590b99d716bb10c5fba9dbd528908f7dccdab695902f80
2014-11-08 16:52:36 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f3301a00b152828271f00caf1103421f22062ed0d7f0e4956dabe3c9f8f15d8291d72d547e89f4ecd80
2014-11-08 16:52:37 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b15c428273b00caf1103421f220cb819b5613d2e094b7de372514305232ba89b5b59996e398175123ce922b80
2014-11-08 16:52:38 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f3301a00b166528275900caf1103421f220091b1d039e69d19bc78e42a2eba1d07b035bb00978fa4f9
2014-11-08 16:52:39 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b16d128276d00caf1103421f2205f88bc20551010c9b29c47f11cce91800bf8b88266ea8f4faca47d49c6da80
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f4301a00b177e201f9020caf1103421f220bc435e618f649a1ade810bd0ec6
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:42 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:42 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:47 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:47 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:51 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:53:02 CUL_HM wz_Thermostat fwUpdate: fail:Block91
2014-11-08 16:53:02 CUL_HM wz_Thermostat CMDs_done_FWupdate

Gruß,
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: martinp876 am 09 November 2014, 09:18:45
Zitat
. Das geht aber schief, weil die 1% Regel zuschlägt
sollte wohl nicht.
ist die Änderung der Geschwindigkeit einkalkuliert? der update wird u.a. mit highspeed gemacht um diese Regel nicht zu verletzen.
Das muss unbedingt geändert werden.

unknown code ist ebenfalls nicht ok. Da fehlt der Kenner "A" für HM
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 November 2014, 11:01:28
Hallo Tobias, hallo Martin,

der Credits10ms Zähler wird auf 1800 (statt 900 wie zuvor) begrenzt. Es stehen also (nach entspr. Ansparzeit ohne Senden) maximal 1800 x 10ms Sendezeit zur Verfügung, um "am Stück messages" senden zu können.

Gesendet wird aber in Paketen (messages), so dass die Anzahl Pakete schon allein durch den Credits10ms counter begrenzt wird. Aber...

Vor jeder messages (Paket) wird aber auch noch eine Präambel gesendet. Ist das Burst Bit im zu sendenden Paket gesetzt, dann wird eine 360ms Präambel gesendet (zum Aufwecken). Ansonsten wird eine 10ms Präambel vor jeder message gesendet.
Für die eigentliche Message fallen immer mindestens 10ms (kleinste angebrochene Einheit) an.

@Martin: Du schaltest auf FUP Mode, nehme ich an?

D.h. mit Burst bit werden 36+1=37 credits verbraucht und ohne Burst bit 1+1=2 credits.

Wenn das Gerät mit Burst Bit bei jeder message geweckt werden muss, schlagen nach spätestens 48 messages (ohne eventuelle Acks?) die credits zu.
Wenn das Gerät nur am Anfang aufgeweckt werden muss (Burst Bit nur beim ersten Paket), dann aber wach bleibt, wären (ohne eventuelle Acks?) 881 messages möglich, bis die credits zuschlagen.
@Martin: 10_CUL_HM.pm muss das Burst Bit entsprechend setzen (oder löschen).

Da offenbar noch Pakete empfangen und bestätigt werden, schlägt die credit Begrenzung dann entsprechend früher zu.


Im FUP Modus bestimmt also nur die

Burst Zeit in ms/10 + 1

die jeweils zu verbrauchenden Credits (die eigentliche Sendenachricht steckt in dem +1).

Ohne FUP Modus sind es

(Burst Zeit in ms + zu sendende Bytes * 8bit * 0.1ms/bit) / 10 + 1

credits, die nach Berechnung in der Firmware pro message verbraucht werden (+1 für angebrochene Zeit bzw. Rundungsfehler).


@Martin: Wie wird eine Firmware gesendet? Bleibt das Gerät wach, wenn es die erste Firmware message erhalten hat?
Die UNKNOWNCODE Meldungen sagen mir erst mal nichts. Ich nehme nur an, dass es Quittungen vom Gerät sein sollen?
Die Firmware würde hier nur "A" schlabbern, wenn der TTY-Sendepuffer an den Hostrechner überläuft und damit die Daten nicht schnell genug via Schnittstelle an den Hostrechner übermittelt werden können. Ggf. müsste da noch ein busy wait rein, um bei vollem TTY-Puffer entsprechend zu warten.

In jedem Fall muss die Creditsauswertung vor und während eines Firmwareupdates in 10_CUL_HM.pm und/oder 00_CUL.pm erfolgen, was derzeit nicht implementiert ist.

Frimware Update kann ich leider mangels Hardware nicht testen.

Gruß, Ansgar.


Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 14 November 2014, 01:02:45
Hallo Martin,

angehängt eine Testversion der Firmware CUL_V3.hex und 00_CUL.pm (beides nebst Quellcode in der zip Datei).

Bitte beachte, dass ich die Definition des groben Credit10ms flags geändert habe (vgl. 00_CUL.pm Kommentare in parse), damit die ungenutzten codes bei Bedarf sinnvoller erweiterbar sind.

Tobias hat damit nun die hm_cc_rt_dn_update_V1_4_001_141020.eq3 erfolgreich geflasht und dafür etwas mehr als 900 credit10ms verbraucht.
Wenn Du also testen möchtest, dann checke bitte erst die credit10ms (1800 ist Obergrenze entsprechend 100%), bevor Du einen Flash Versuch unternimmst.

Ich habe die Präambel im FUP Modus auf 1ms reduziert, was offenbar gut geht und rechne die credits mit subcredits10ms. Damit reichen die credits für das RT_DN update.
Es sind dabei etwa 91000 Bytes übertragen worden, wenn ich mich nicht verechnet habe, Nutzdaten ca. 68000 Bytes

Nun müsstest Du für ein Update bei mangelnden Credits entweder (im Hintergrund) warten bis genug credits für ein gewünschtes Funkupdate vorhanden sind oder eine Fehlermeldung zu mangelnden credits ausgeben.

@Tobias: kannst Du bitte nochmal testen, danke!

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Es ist sind weiterhin auch meine nur teilweise getesteten Slow-RF Änderungen drin. Da sind noch unschärfen möglich.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 November 2014, 20:18:49
Hallo Martin, hallo Tobias, hallo weitere Testwillige,


anghängt eine neue Testversion für Firmware und 00_CUL.pm.

In 00_CUL.pm ist mir noch ein Fehler in Parse bezüglich der $dmsg Länge aufgefallen, was insbesondere für Nicht-ASKSIN Protokolle teilweise fatal war.

In der Firmware habe ich noch die Interrupt Reentranz für USB verbessert (denke ich jedenfalls  ;)). Die Firmware ist für CUL_V3 und COC jeweils als HEX in der zip Datei.

Edit: Anhang gelöscht, da update siehe unten.


Gruß,

Ansgar.

PS: Es ist sind weiterhin auch meine nur teilweise getesteten Slow-RF Änderungen drin. Da sind noch Unschärfen möglich.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 17 November 2014, 21:19:04
Hallo Ansgar,

auch diese letzte Kombi funktioniert in meiner HM-Umgebung perfekt.

Testfall getConfig bei  RT-DN Thermostaten: Keine pending commands, MISSING ACKs, Resends etc...
Testfall HM Firmware Update beim RT-DN: funktioniert jetzt fehlerfrei ohne LOVL, falls der credit10ms counter beim Start >= ca. 1000 ist

Gruß
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 November 2014, 23:08:08
Hallo Tobias,

danke für Deine Tests!

Da derzeit keine größeren Firmwareupdates bei eq3 zum Download zu sehen sind, ist das erst mal der worst case, der mit den Credits von 1800 durch geht.
Sieht also bisher alles gut aus.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 November 2014, 00:03:02
Hallo Rudolf,

da die Tests positiv verlaufen, mach ich mal den Anfang mit Updatewünschen.

Als erstes ein Änderungswunsch in clock.c. Die alte Zählweise hat bei den Sekunden den Haken, schon mal Sekunden zu überspringen, wenn der Prozessor länger als 8ms für einen kompletten Hauptschleifendurchlauf benötigt. Das hat auch den Nachteil, das credits10ms gelegentlich nicht hochgezählt werden.
Konkret in ASKSIN passiert so was gelegentlich beim Umschalten auf Senden, da dabei auf einen freien Sendekanal gewartet wird, was durchaus etwas dauern kann.
Daher habe ich den zyklischen Zähler in einen Intervall-Zähler geändert, siehe Code. Das sollte so weniger Sekunden verlieren und damit weniger credits vergeuden.
Wenn Dir ein Grund bekannt ist, der dagegen spricht, es so zu ändern (also lieber eine Sekunde verlieren aber dafür im Sekundentakt bleiben), ich könnte auch ohne diese Änderung leben. In meinen Testgeräten (CUL_V3 un COC) habe ich noch keine Probleme damit feststellen können (allerdings bei COC auch Onewire ungenutzt).

Außerdem ist ein Ergänzungswunsch zu einer get_timestamp Funktion, die die aktuellen Ticks Timer0-Interruptsicher liest, enthalten. Das benötige ich später, um die TimeStamps bei ASKSIN sauber auslesen zu können. Bisher kann ein Timer0 Interrupt, der ausgerechnet beim Nicht-Interrupt-Lesen der Ticks zuschlägt zu falsch gelesenen ticks-Werten führen, wenn beim Hochzählen im Interrupt Byteüberläufe auftreten.
Ich habe es aber auch in clock.c schon genutzt, wie Du am Code siehst.
Sofern HAS_GET_TIMESTAMP nicht definiert ist, bleibt das aber noch beim Alten.
HAS_GET_TIMESTAMP wäre dann noch in board.h zum testen zu definieren. Bei CUL_V2 würde es wohl (derzeit) zu Speicherproblemen führen.
Ich habe in clock.h daher vorbereitet, dass es aktiv wird, wenn später die TimeStamp per #define aktiviert wird.

DH8 kommt später mit den display Änderungswünschen, tut aber dank #ifdef derzeit auch nicht weh.

Ich hoffe, Du bist mit diesen Änderungen einverstanden.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und danke,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 November 2014, 22:53:47
Hallo Rudolf,

der nächste Änderungswunsch betrifft display.c.

Die Hex Ausgabe ist auf 32 bit Integer Zahlen mit padding "aufgebohrt", wenn HAS_DISPLAY_32BIT_HEX8 definiert ist und damit wird auch DH8 über display.h zur Verfügung gestellt. DH8 erwartet als Übergabewert dann einen Zeiger auf eine uint32_t Zahl.
Der Vollständigkeit halber kann mit HAS_DISPLAY_16BIT_HEX4 auch noch ein DH4 aktiviert werden, dass dann eine uint16_t Zahl als Übergabewert erwartet. Bei genügender Nutzung macht das Speichertechnisch Sinn.

Damit ist die clock Änderung auch mit dem noch fehlenden DH8 versorgt.

Ohne #defines bleibt es beim Alten. Wie bei clock.h sind zukünftige Timestamp Abhängigkeiten schon in der .h berücksichtigt.

Eine wesentliche Änderung betrifft die Ausgabe über USB oder Seriell. Hier habe ich ein Blockierendes Senden ergänzt, wenn der TTY Puffer voll läuft. Der Grund liegt in den letzten Tests mit den Homematic Updates. Dabei sind Zeichen der Sende TimeStamp Quittung mit CUL verloren gegangen, weshalb diese Änderung erforderlich wurde.

Ich hoffe, Dir ist kein Fall bekannt, wo das stört und Du kannst es so einbauen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 November 2014, 23:14:19
Hallo Rudolf,

eine weitere Änderung betrifft ttydata.c.

Darin ist mir aufgefallen, dass es bei COC mit dem großen TTY Puffer mit 8 bit Pufferzeiger nicht mehr zuverlässig passt. Das ist ein stiller Bug, der derzeit nur nicht auffällt, weil reguläre Kommandos nicht so lang sind. Mit dem zukünftigen "Ap" Kommando für den Ping würde der aber dumm auffallen können oder wenn derzeit irrtümlich zu lange Kommandos an COC abgesetzt werden.

Außerdem noch eine kleine Optimierung in callfn, die ein bischen schneller beim Dekodieren sein sollte.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 November 2014, 23:44:58
Hallo Rudolf,

eine weitere Änderung betrifft serial.c.

Beim Empfang über die serielle Schnittstelle wurde nach meinem Verständnis der Atmel Dokus UCSR0A und UDR0 in falscher Reihenfolge ausgelesen, so dass der Empfangsstatus nicht zum gelesenen Empfangsbyte gehört. Der Atmel Sample Code in der Doku entspricht ebenfalls meiner Änderung.

Außerdem habe ich das Lesen und das Schreiben aus/in die TTY Puffer in den Interrupt Routinen ausprogrammiert, um für Slow-RF das Empfangstiming etwas zu optimieren (COC ist dabei bei mir schlechter als CUL, was aber störtechnisch vermutlich vor allem an der Nähe zur RasPi-Platine liegt).

uart_init ist derzeit nicht ganz sauber, wenn man mal die Baudrate ändern möchte.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 November 2014, 23:55:35
Hallo Rudolf,

in ringbuffer ist mir aufgefallen, dass rb_reset nicht Interrupt fest gemacht wurde, wie die get und put routine.
Edit: nun hängt auch die Datei an.

Die restlichen Änderungen dienen der Speicheroptimierung.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Und bitte die Änderungen auf der vorhergenden Seite 3 nicht übersehen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 November 2014, 00:17:03
Hallo Rudolf,

der nächste Änderungswunsch betrifft LUFA.

Neben Speicheroptimierung habe ich es fest gegen Aufruf im Interrupt gemacht.

Da darin USB_USBTask in CDC_Task jeweils direkt vor dem Zugriff auf den IN bzw. OUT EndPoint aufgerufen wird, kann (sollte) der Aufruf aus der Hauptschleife entfernt werden.

Bei mir läuft es besser.

Haupt Übeltäter bei meinen RasPi - CUL USB Problemen war jedoch plotfork. Seit ich das aus habe, läuft USB sehr stabil (mit Aufbau von Seiten mit vielen Protokoll-Graphen konnte ich zuvor USB-Probleme gut provozieren). Außerdem habe ich an meinen Zehnfach USB Hub 2.0 die beiden CULs und meinen USB-WDE1 jeweils so gesteckt, dass für jedes der USB1.1 Geräte ein eigener Transaction-Translator zur Verfügung steht und damit die USB-Verzögerungen minimiert.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: auf die seriell und USB Optimierungen lege ich wert, damit nicht ASKSIN TimeStamp Probleme gemeldet/beklagt werden, die eigentlich versteckte Kommunikationsprobleme sind.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 25 November 2014, 23:59:40
Zitat
Als erstes ein Änderungswunsch in clock.c

Ich habe die beabsichtigten Aenderungen eingecheckt, den Patch aber nicht direkt uebernommen.

Zitat
Konkret in ASKSIN passiert so was...
Dann ist im ASKSIN was schlecht geloest. Eine Umbenennung der Variable waere dafuer aber nicht notwendig, nicht mal die Zaehlrichtung muss man aendern, falls man bereit ist mit busy-loops unter eine Sekunde auszukommen. Nach 2 Sekunden kommt eh der Watchdog.

Zitat
Bei CUL_V2 würde es wohl (derzeit) zu Speicherproblemen führen.
Deswegen, und wegen den vielen IFDEFs habe ich versucht den Code kleiner zu krieger, was schliesslich mit avr-gcc 4.8.1 in ausreichenden Masse (3.5%) gelang. Das musste ich aber eine Weile selbst testen, bevor ich es auf die Allgemeinheit loslasse. Das ist hiermit passiert, und um es besser verfolgen zu koennen, habe ich die Version auf 1.62 geaendert.

Das Einarbeiten des Patches hat etwas laenger gedauert, weil ich etwa 4 Stunden Zeit dafuer investieren musste.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 Dezember 2014, 02:00:09
Hallo Rudolf,

Zitat
Ich habe die beabsichtigten Aenderungen eingecheckt, den Patch aber nicht direkt uebernommen.

Danke für die Mühe, die Du Dir damit gemacht hast!

Deine Variante ist auch gut. Der Timerinterruptzeit tut's in jedem Fall gut.
Und etwas mehr mögliche Credits Verluste -> näher an der Norm. ;-)
Mit der Variablenänderung hätte mir der Compiler gesagt, wenn dieser Zähler bereits irgendwo anders genutzt worden wäre.

Zitat
Dann ist im ASKSIN was schlecht geloest.

Es wird halt auf den freien Kanal gewartet. In ursprünglicher Variante sogar, bis der watchdog zuschlägt. Wenn TimeStamp mal volltändig drin ist, wäre es über das Feedback auch möglich, dass fhem einen diesbezüglichen Misserfolg nach timeout mitbekommt und es nochmal versuchen kann.
Im CUL wäre es mit großem Aufwand denkbar, mit einer Statemaschine zu arbeiten, um länger warten zu können. Aber ich denke, das willst Du nicht wirklich.
Bei mir läuft der Watchdog auf 8s eben um das Problem weitgehend zu umgehen.

Ich habe für clock.c noch ein paar Kleinigkeiten und für DH8 möchte ich nochmal werben, da das später bei TimeStamp auch noch genutzt wird und sich dann erst der Progammspeicher Vorteil ergibt.
Daher habe ich display.c nochmal etwas umgebaut. Mit einem #define CUL_SAVE_PROGMEM werden darin die erweiterten Funktionen abgeschaltet, d.h. vermutlich nur für CUL_V2 wäre dieser define dann überhaupt nötig.
In stringfunc war ich auch schon aktiv. Für eine spätere Korrektur von ks_send müssen auch ungerade Anzahlen von Nibbles von Hex gewandelt werden können. daher habe ich fromhex dahingehend schon vorbereitet. Ich hoffe, das passt Speichertechnisch noch. In der Wandlung sollte es etwas schneller sein, denke ich.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 Januar 2015, 14:06:23
Hallo Testwillige,

im Anhang eine ergänzte Version von Firmware und 00_CUL.pm für ASKSIN/HM Timestamp.

Ich habe in der Firmware aus den Sendequittungen die Länge der kopierten Nachrichten entfernt, da überflüssig und es die Lesbarkeit von Rohdaten Logs erleichtert.
EDIT: Den Timeout für ASKSIN für die Umschaltung auf Senden habe ich reduziert. Nun sollte CUL max. 2s versuchen auf Senden zu schalten und dann Misserfolg zurück melden. Mit der letzten Firmwareversion war der Timeout zu lang und der Watchdog konnte zuschlagen und FHEM hat zwar den disconnect bemerkt, aber mit dem reconnect hat es nicht immer geklappt.

Außerdem habe ich in 00_CUL.pm die Rohdatenausgabe um eine Ausgabe der Timestamp in ms dezimal ergänzt. Damit ist es bezüglich Timingproblemen besser lesbar.
EDIT: Die Timestamp Log Ausgabe habe ich geändert. Die Timestamp kommt nur einmal vor und hat 8 Stellen und wird per default in hex in ms ausgegeben. Mit dem Attribut hmtsLogFormat kann man auf dec = dezimal umstellen. In Hex Ausgabe sind es 32bit und in dezimal 12bit, die ausgegeben werden.

Beispiel hex:
2015.01.03 14:53:01 4: CUL_Parse: CUL_HM868  A FF81 0023D428 0E 11 A010 17832D F11034 0212003006 -66
2015.01.03 14:53:01 4: CUL_send:  CUL_HM868               As 0A 11 8002 F11034 17832D 00
2015.01.03 14:53:02 4: CUL_Parse: CUL_HM868  A FF83 0023D4C0 0A 11 8002 F11034 17832D 00 -138
2015.01.03 14:53:02 4: CUL_Parse: CUL_HM868  A FF81 0023D540 0C 12 A010 17832D F11034 030000 -66.5

Beispiel dezimal:
2015.01.03 14:24:24 4: CUL_Parse: CUL_HM868  A FF51 00631344 0E 08 A010 17832D F11034 0212003006 -67
2015.01.03 14:24:24 4: CUL_send:  CUL_HM868               As 0A 08 8002 F11034 17832D 00
2015.01.03 14:24:24 4: CUL_Parse: CUL_HM868  A FF53 00631520 0A 08 8002 F11034 17832D 00 -138
2015.01.03 14:24:24 4: CUL_Parse: CUL_HM868  A FF51 00631648 0C 09 A010 17832D F11034 030000 -66.5

Edit: Anhang gelöscht, da update siehe unten.

Gruß

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2015, 19:14:36
Hallo Testwillige, hallo Martin,

ich habe in dieser Testversion die 00_CUL.pm dahingehend geändert, das die Sendverzögerung mit der TimeStamp Firmware automatisch hinsichtlich einer Zielverögerung von 120 - 124ms angepasst wird.

Bei mir auf RasPi scheint's zu klappen.

Gruß, Ansgar,
EDIT: geändert wegen ping bug

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Januar 2015, 15:52:08
Hallo Testwillige, hallo Martin,

eine neue Version für 00_CUL.pm steckt im Anhang. Darin habe ich mal zusätzlich den credits Stand genutzt, um bei zu geringem credits Stand die weitere Abarbeitung der HM Sende Warteschlange zu verzögern. Hilft zum Teil, da die Antwort zum Sendebefehl verzögert abgearbeitet wird.
Mit ping (Ap) wird dann der grobe credits Stand aktualisiert. Die Verzögerung unterscheidet auch zwischen Burst und Non Burst messages und verzögert entsprechend lange.

Außerdem ist ein dusseliger Bug bei der Ping Auswertung raus.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
EDIT: Log ist jetzt auf dauerhaft dezimal für die Timestamps
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2015, 17:49:51
Hallo Testwillige, hallo Martin,

eine neue Version für Firmware und 00_CUL.pm steckt im Anhang.

Die Firmware kennt nun den neuen Befehl Aw für verzögertes Senden.
Das Sende Format ist dann Aw 0d ll x*. Die 0 ist Reserve, d (Hex Nibble) die Verzögerungszeit bis zum Senden in 8ms Einheiten. ll die Anzahl der Bytes die gesendet werden sollen und x* die eigentliche Nachricht, also ab 0d das gleiche, wie bisher bei As.
Mit dieser Funktion kann man also um bis zu 15*8ms=120ms das Senden verzögern. Während der Wartezeit wird auch weiter empfangen, so etwas reinkommt, nur Befehle über die Schnittstelle werden nicht angenommen/bearbeitet.

In der zugehörigen 00_CUL.pm ist das dann genutzt, um die Sendeverzögerungen für Ack Nachrichten auf 120ms zu optimieren. Dabei wartet dann nicht mehr FHEM, wie in den vorherigen Versionen, sondern CUL, um das Senden entsprechend zu verzögern.
Wenn nicht gewartet werden muss, soll oder kann, dann wird As benutzt, ansonsten wird der Sendestring auf die passende Aw Nachricht umgesetzt.

Außerdem ist der AP für die PLL Log Ausgaben für cc1101 Problemmeldungen geändert. AP1 schaltet diese ein und AP0 schaltet sie aus. Per Default sind sie nun aus und können also per AP Befehl aktiviert werden.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 Januar 2015, 01:09:43
Hallo Testwillige, hallo Martin,

eine neue Version für 00_CUL.pm steckt im Anhang.

EDIT: Verwerfen erst mal verworfen wegen buggy HM Devices, die bei fehlendem Ack zu schnell Wiederholen.
Ergänzt zur vorherigen Version habe ich das Verwerfen einer zu sendenden Antwort, wenn FHEM zu langsam auf die vorherige Nachricht reagiert und somit keine Chance für einen rechtzeitigen Versand besteht. Bei einer Systemverzögerung von mehr als 180ms wird keine Antwort an das device gesendet, sondern die Antwort verworfen. Die 180ms kann man ggf. noch optimieren.
Das sollte Credits sparen und bei der nächsten Nachricht vom Device die Chance auf den Empfang und die dann hoffentlich rechtzeitige Antwort erhöhen.


Anhand von dhmSt (Antwortzeit von CUL auf Device Nachricht) im Log ist zu sehen, wie hmSysACKwait nach und nach auf die optimale Antworteit zum device von 120ms optimiert wird. Startwert für hmSysACKwait ist 0.1s und das wird bei meinem System auf etwa 0.09s optimiert.
Die 120ms beobachte ich auch bei Antworten von Geräten zu denen CUL sendet, so dass ich die mal als guten Wert annehme.
Sdly ist die Systemverzögerung, die leider zwischendurch mal hoch wird, so dass eine Antwort keinen Sinn macht.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 07 Januar 2015, 08:47:11
Hallo Ansgar,

super Arbeit! Bei mir ist es diese Woche etwas eng - sobald ich dazukomme, werde ich aber testen und Feedback geben.

Gruß
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 08 Januar 2015, 20:15:00

Hallo Ansgar,

habe die letzte Kombi heute mal getestet. Funktioniert im Großen und Ganzen - aber nicht ganz so reibungslos wie mit der Version von Mitte November (siehe weiter vorne im Thread). Speziell sehe ich deutlich mehr "Resends".

fhem> set hm protoEvents

protoEvents done:
    name          :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    az_Thermostat : done           | -        |47:       |1:        # -        | -        | -        | -
    az_podP6026   : done           | -        |10:       | -        # -        | -        | -        | -
    bd_Thermostat : done           | -        |33:       |1:        # -        | -        | -        | -
    dg_Thermostat : done           | -        |33:       |1:        # -        | -        | -        | -
    hm_PowerMeter : done           | -        |35:       | -        # -        | -        | -        | -
    hm_RC4_Tobi   : done           | -        |1:        | -        # -        | -        | -        | -
    ke_Pumpe      : done           | -        |21:       |3:        # -        | -        | -        | -
    ke_Switch4    : done           | -        |64:       |7:        # -        | -        | -        | -
    ku_Rollo      : done           | -        |12:       | -        # -        | -        | -        | -
    ku_Switch1    : done           | -        |8:        | -        # -        | -        | -        | -
    te_Markise    : done           | -        |13:       | -        # -        | -        | -        | -
    te_Sensor     : done           | -        |283:      | -        # -        | -        | -        | -
    tim_Rollo     : done           | -        |16:       | -        # -        | -        | -        | -
    vccu          :  -             | -        | -        | -        # -        | -        | -        | -
    wz_Sensor     : done           | -        |137:      | -        # -        | -        | -        | -
    wz_Thermostat : done           | -        |45:       |1:        # -        | -        | -        | -
    wz_vT         :  -             | -        | -        | -        # -        | -        | -        | -
================================================================================================================
    sum           0                |0         |758       |14        #0         |0         |0         |0

Anhand von dhmSt (Antwortzeit von CUL auf Device Nachricht) im Log ist zu sehen, wie hmSysACKwait nach und nach auf die optimale Antworteit zum device von 120ms optimiert wird. Startwert für hmSysACKwait ist 0.1s und das wird bei meinem System auf etwa 0.09s optimiert.
Die 120ms beobachte ich auch bei Antworten von Geräten zu denen CUL sendet, so dass ich die mal als guten Wert annehme.
Sdly ist die Systemverzögerung, die leider zwischendurch mal hoch wird, so dass eine Antwort keinen Sinn macht.

hmSysACKwait pendelt bei mir ebenfalls um 0.09s.

root@raspbmc:/opt/fhem/log# grep hmSysACKwait fhem-2015-01.log
2015.01.08 19:58:25 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:58:25 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:58:27 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.092
2015.01.08 19:58:27 4: CUL_parse: myCULv3  dhmSt:1360 hmSysACKwait:0.092
2015.01.08 19:58:28 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:58:28 4: CUL_parse: myCULv3  dhmSt:176 hmSysACKwait:0.092
2015.01.08 19:58:53 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:01 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:02 4: CUL_parse: myCULv3  dhmSt:176 hmSysACKwait:0.092
2015.01.08 19:59:02 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:02 4: CUL_parse: myCULv3  dhmSt:168 hmSysACKwait:0.092
2015.01.08 19:59:03 4: CUL_parse: myCULv3  dhmSt:184 hmSysACKwait:0.092
2015.01.08 19:59:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:04 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:12 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:25 4: CUL_parse: myCULv3  dhmSt:248 hmSysACKwait:0.092
2015.01.08 19:59:26 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 19:59:28 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.09
2015.01.08 19:59:28 4: CUL_parse: myCULv3  dhmSt:1696 hmSysACKwait:0.09
2015.01.08 19:59:29 4: CUL_parse: myCULv3  dhmSt:328 hmSysACKwait:0.09
2015.01.08 19:59:29 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:29 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:29 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:30 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:30 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:30 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 19:59:30 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.094
2015.01.08 19:59:33 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 19:59:33 4: CUL_parse: myCULv3  dhmSt:232 hmSysACKwait:0.092
2015.01.08 19:59:37 4: CUL_parse: myCULv3  dhmSt:80 hmSysACKwait:0.092
2015.01.08 19:59:39 4: CUL_parse: myCULv3  dhmSt:40 hmSysACKwait:0.092
2015.01.08 19:59:41 4: CUL_parse: myCULv3  dhmSt:2848 hmSysACKwait:0.092
2015.01.08 20:00:17 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:00:24 4: CUL_parse: myCULv3  dhmSt:1936 hmSysACKwait:0.092
2015.01.08 20:01:04 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.096
2015.01.08 20:01:04 4: CUL_parse: myCULv3  dhmSt:312 hmSysACKwait:0.096
2015.01.08 20:01:07 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.094
2015.01.08 20:01:07 4: CUL_parse: myCULv3  dhmSt:192 hmSysACKwait:0.094
2015.01.08 20:01:09 4: CUL_parse: myCULv3  dhmSt:48 hmSysACKwait:0.094
2015.01.08 20:01:09 4: CUL_parse: myCULv3  dhmSt:24 hmSysACKwait:0.094
2015.01.08 20:01:09 4: CUL_parse: myCULv3  dhmSt:328 hmSysACKwait:0.094
2015.01.08 20:01:09 4: CUL_parse: myCULv3  dhmSt:224 hmSysACKwait:0.094
2015.01.08 20:01:10 4: CUL_parse: myCULv3  dhmSt:280 hmSysACKwait:0.094
2015.01.08 20:01:10 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:01:10 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 20:01:48 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:02:38 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.094
2015.01.08 20:02:38 4: CUL_parse: myCULv3  dhmSt:336 hmSysACKwait:0.094
2015.01.08 20:02:38 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:02:38 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 20:02:39 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:02:39 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:02:39 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.096
2015.01.08 20:02:39 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.096
2015.01.08 20:02:40 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.094
2015.01.08 20:02:40 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:02:40 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:02:40 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:02:41 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 20:02:42 4: CUL_parse: myCULv3  dhmSt:88 hmSysACKwait:0.092
2015.01.08 20:02:43 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:02:46 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.09
2015.01.08 20:02:48 4: CUL_parse: myCULv3  dhmSt:56 hmSysACKwait:0.09
2015.01.08 20:02:49 4: CUL_parse: myCULv3  dhmSt:3368 hmSysACKwait:0.09
2015.01.08 20:03:01 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:03:01 4: CUL_parse: myCULv3  dhmSt:544 hmSysACKwait:0.09
2015.01.08 20:03:02 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.088
2015.01.08 20:03:02 4: CUL_parse: myCULv3  dhmSt:1048 hmSysACKwait:0.088
2015.01.08 20:03:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.088
2015.01.08 20:03:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.088
2015.01.08 20:03:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.088
2015.01.08 20:03:03 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.088
2015.01.08 20:03:04 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.088
2015.01.08 20:03:04 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.092
2015.01.08 20:03:04 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:03:04 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:03:07 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.09
2015.01.08 20:03:08 4: CUL_parse: myCULv3  dhmSt:280 hmSysACKwait:0.09
2015.01.08 20:03:08 4: CUL_parse: myCULv3  dhmSt:96 hmSysACKwait:0.09
2015.01.08 20:03:08 4: CUL_parse: myCULv3  dhmSt:32 hmSysACKwait:0.09
2015.01.08 20:03:11 4: CUL_parse: myCULv3  dhmSt:40 hmSysACKwait:0.09
2015.01.08 20:03:12 4: CUL_parse: myCULv3  dhmSt:48 hmSysACKwait:0.09
2015.01.08 20:03:12 4: CUL_parse: myCULv3  dhmSt:3232 hmSysACKwait:0.09
2015.01.08 20:03:12 4: CUL_parse: myCULv3  dhmSt:1312 hmSysACKwait:0.09
2015.01.08 20:04:13 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:04:20 4: CUL_parse: myCULv3  dhmSt:2432 hmSysACKwait:0.09
2015.01.08 20:04:25 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:04:27 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:04:40 4: CUL_parse: myCULv3  dhmSt:104 hmSysACKwait:0.094
2015.01.08 20:04:40 4: CUL_parse: myCULv3  dhmSt:448 hmSysACKwait:0.094
2015.01.08 20:04:41 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 20:04:41 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:04:41 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:07 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:07 4: CUL_parse: myCULv3  dhmSt:616 hmSysACKwait:0.092
2015.01.08 20:05:08 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:08 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:10 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:05:10 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.09
2015.01.08 20:05:10 4: CUL_parse: myCULv3  dhmSt:32 hmSysACKwait:0.09
2015.01.08 20:05:10 4: CUL_parse: myCULv3  dhmSt:48 hmSysACKwait:0.09
2015.01.08 20:05:11 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:11 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:11 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:05:11 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:12 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:12 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:31 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.094
2015.01.08 20:05:31 4: CUL_parse: myCULv3  dhmSt:312 hmSysACKwait:0.094
2015.01.08 20:05:33 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.092
2015.01.08 20:05:33 4: CUL_parse: myCULv3  dhmSt:1232 hmSysACKwait:0.092
2015.01.08 20:05:33 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:05:33 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:34 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:34 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:34 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:34 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:35 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.09
2015.01.08 20:05:35 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.094
2015.01.08 20:05:37 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.092
2015.01.08 20:05:38 4: CUL_parse: myCULv3  dhmSt:176 hmSysACKwait:0.092
2015.01.08 20:05:38 4: CUL_parse: myCULv3  dhmSt:56 hmSysACKwait:0.092
2015.01.08 20:05:38 4: CUL_parse: myCULv3  dhmSt:24 hmSysACKwait:0.092
2015.01.08 20:05:38 4: CUL_parse: myCULv3  dhmSt:96 hmSysACKwait:0.092
2015.01.08 20:05:38 4: CUL_parse: myCULv3  dhmSt:32 hmSysACKwait:0.092
2015.01.08 20:05:39 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:39 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:05:41 4: CUL_parse: myCULv3  dhmSt:136 hmSysACKwait:0.09
2015.01.08 20:05:41 4: CUL_parse: myCULv3  dhmSt:1952 hmSysACKwait:0.09
2015.01.08 20:05:41 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09
2015.01.08 20:05:42 4: CUL_parse: myCULv3  dhmSt:112 hmSysACKwait:0.094
2015.01.08 20:05:42 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.094
2015.01.08 20:06:47 4: CUL_parse: myCULv3  dhmSt:144 hmSysACKwait:0.092
2015.01.08 20:06:50 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:06:53 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:07:00 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:09:31 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:10:08 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:11:46 4: CUL_parse: myCULv3  dhmSt:120 hmSysACKwait:0.092
2015.01.08 20:13:10 4: CUL_parse: myCULv3  dhmSt:128 hmSysACKwait:0.09

Gruß
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 10 Januar 2015, 12:10:43
Hallo Tobias, hallo Martin.

danke für den Test!

angehängt eine neue Version.

Diesmal mit einem send at in der Firmware. Die neuen 00_CUL.pm und Firmware müssen zusammen benutzt werden.

00_CUL.pm ist auch aufgeräumter.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 11 Januar 2015, 20:53:02
Hallo Ansgar, Martin,

die Version 71b funktioniert gefühlt noch besser - auch wenn bei 2x Durchlauf meiner kleinen Testsuite wieder ein paar Resends dabei sind.

protoEvents done:
    name          :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    az_Thermostat : done           | -        |60:       | -        # -        | -        | -        | -
    az_podP6026   : done           | -        |20:       | -        # -        | -        | -        | -
    bd_Thermostat : done           | -        |82:       |3:        # -        | -        | -        | -
    dg_Thermostat : done           | -        |61:       |1:        # -        | -        | -        | -
    hm_PowerMeter : Info_Cleared   | -        | -        | -        # -        | -        | -        | -
    hm_RC4_Tobi   : Info_Cleared   | -        | -        | -        # -        | -        | -        | -
    ke_Pumpe      : done           | -        |21:       | -        # -        | -        | -        | -
    ke_Switch4    : done           | -        |105:      |5:        # -        | -        | -        | -
    ku_Rollo      : done           | -        |22:       | -        # -        | -        | -        | -
    ku_Switch1    : done           | -        |24:       | -        # -        | -        | -        | -
    te_Markise    : done           | -        |22:       | -        # -        | -        | -        | -
    te_Sensor     : done           | -        |8:        | -        # -        | -        | -        | -
    tim_Rollo     : done           | -        |22:       | -        # -        | -        | -        | -
    vccu          : Info_Cleared   | -        | -        | -        # -        | -        | -        | -
    wz_Sensor     : done           | -        |9:        | -        # -        | -        | -        | -
    wz_Thermostat : done           | -        |76:       |1:        # -        | -        | -        | -
    wz_vT         : Info_Cleared   | -        | -        | -        # -        | -        | -        | -
================================================================================================================
    sum           0                |0         |532       |10        #0         |0         |0         |0

Ich hänge mal das verbose4 Log zum CUL während des Tests an, falls Interesse besteht.

Viele Grüße
Tobias
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Januar 2015, 01:00:00
Hallo Tobias, hallo Martin, hallo Testwillige,

im Anhang eine neue Version zum Testen. Firmware und 00_CUL.pm müssen unbedingt zusammen benutzt werden!

Zum Einsatz kommt wieder der neu creierte Aa (send at) Befehl. Er hat das Format AaTTTTm*.
TTTT ist der Sendezeitpunkt als 16bit Hex Zahl in 8ms Einheiten. Der Sendezeitpunkt bezieht sich auf die unteren 16 Bit des CUL internen 8ms Tickcounters. Der Sendezeitpunkt darf nicht weiter als etwa 7s vom aktuellen Tickcounterstand entfernt liegen. Die 7s sollten ausreichend sein, um auch mit einem stockenden System keine Probleme zu bekommen. Ist der Sendezeitpunkt verpasst, dann wird sofort gesendet (so weit das mit den 16 Bit erkennbar ist, als schön die 7s einhalten...).  Normalerweise liegt der Sendezeitpunkt etwa 100ms vom letzten Tickcounter Stand entfernt, wenn der Befehl zum Einsatz kommt. Der Watchdog ist auf 8s eingestellt, der würde CUL ggf. wieder in die Realität zwingen.  ;)
*m ist die eigentliche Sendenachricht, wie von As bekannt (Asm*).

Bis zum Erreichen des Sendezeitpunkts wird weiter auf ASKSIN empfangen und empfangene Nachrichten von CUL an den Host weiter gereicht. Jedoch werden Kommandos erst nach dem Senden weiter von CUL verarbeitet.
Die grobe Credits Info, die mit den Timestamps übergeben wird, ist auch geändert, siehe Code. Ergänzt habe ich nach der Tickcounter Stand noch zwei Nibbles, die bei der Sendequittung die Wartezeit zum freien Kanal (CCA) in 8ms Einheiten zurück meldet.

In 00_CUL.pm habe ich die HM Änderungen noch mal kräftig aufgeräumt und verschlankt. Weniger ist hier mehr, wie sich gezeigt hat.
Die HM Änderungen sind auch so weit möglich in separate Funktionen gepackt.
@Martin: Kommt Dir das so entgegen?
@Rudolf: kommt Dir das so entgegen?

Außerdem habe ich so weit erkennbar machbar auf Referenzenübergabe bei Funktionsaufrufen umgestellt. Das bringt noch etwas an Geschwindigkeit. Leider nutzen auch andere Module 00_CUL.pm Funktionen, so dass das nicht nebenwirkungsfrei komplett durchgezogen werden kann.
Mit einem anderen Modul habe ich das mal gemacht und bei den kritischen Funktionen ist dabei bis zu Faktor 2 raus gekommen.
Geht natürlich etwas auf Kosten der Lesbarkeit und erfordert Acht darauf, die Quelle nicht zu überschreiben.

Weiterhin wird nun auch bei ASKSIN "TRANSMIT LIMIT EXCEEDED" getriggert, wenn das Sendezeitlimit erreicht wurde (und deswegen nicht gesendet werden konnte).

@Tobias: Danke für den Test! Sieht doch gar nicht so schlecht aus. Wundern tut mich noch "Can't connect to socket!" das da eingestreut ist. Leider ohne Angabe der Quelle. Eventuell bräuchtest Du mal ein Update, da Rudolf an deviceio etwas geändert hat.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tpm88 am 15 Januar 2015, 08:31:25

@Tobias: Danke für den Test! Sieht doch gar nicht so schlecht aus. Wundern tut mich noch "Can't connect to socket!" das da eingestreut ist. Leider ohne Angabe der Quelle. Eventuell bräuchtest Du mal ein Update, da Rudolf an deviceio etwas geändert hat.

Hallo Ansgar,

das "Can't connect to socket!" wird vom LW12 Modul (zur Ansteuerung von RGB LED Streifen) jede Minute erzeugt, wenn es den LED Controller im Netz nicht erreichen kann. Ich habe schon überlegt, das während der Tests stillzulegen - andererseits wollte ich auch keine zu "sterile Laborumgebung" schaffen, da wir bei der Optimierung des CUL HM Timings wohl auch die "reale" übrige Modulwelt von FHEM nicht außen vorlassen sollten.

Zum Zeitpunkt des letzten Tests war die FHEM Installation eigentlich tagesaktuell. Sobald ich dazukomme, werde ich meine Tests mit der neuen Kombi auch wieder durchlaufen lassen.

Gruß
Tobias

PS: Es sieht übrigens nicht nur "gar nicht so schlecht" sondern IMHO bereits _SEHR GUT_ aus.  :)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 20 Januar 2015, 22:01:19
Hallo Ansgar,

Die folgenden Beobachtungen beziehen sich auf culfw-code-459-trunk_lufa_rf_cr_sd_72.zip, Hardware CUL V3.4, in FHEM als CUL433 definiert. Ich verwende den CUL433 ausschließlich für den Empfang von WS2000 Daten, also 433 MHz OOK.

1. Wenn ich die "raw RSSI" Daten sehen möchte

    set CUL433 raw Xa7
    dann werden die nicht angezeigt. Für die Fehlersuche bei einem OOK-Protokoll wäre das aber sehr hilfreich. Ist das ein gewünschtes Verhalten?

2. Einige von CUL433 an FHEM gesendete Pakete werden verworfen. Beispiel:

    2015.01.20 11:49:41 2: CUL433: unknown message p 9  784  384  368  864 10  5 5 DE 8A5DE8539E90  288  240                                                                                                                                   

    Das Datenpaket 8A5DE8539E90 (von einem ASH 2000) lautet in binärer Darstellung

    10001     01001     01110     11110     10000     10100     11100     11110     10010
                        ↑

    Ich habe die Daten in Nibbles (4 Daten- plus jeweils ein Stoppbit) gruppiert, so wie sie vom WS2000-Protokoll verwendet werden. Jede Gruppe muss mit einem Stoppbit (= 1) abgeschlossen werden. Offensichtlich ist an an der markierten Stelle nicht erfüllt. Es zeigt sich, dass man ein Bit (das Bit vor dem markierten Bit) verwerfen muss, um ein gültiges und sinnvolles Paket zu erhalten:

10001     01001     01101     11101     00001     01001     11001     11101     00100
1         2         6         7         0         2         3         7         4
Type      Adr       7.6                           73.3                          Check1

    Ich beschreibe das deshalb so ausführlich, weil das bei fast der Hälfte der Pakete passiert. Mit anderen Worten: Die Filterung der Rohwerte lässt von Zeit zu Zeit ein paar Störungen durch, die dann als zusätzliche Bits erscheinen und das Paket zerstören. Die Störungen treten unabhängig von der Entfernung zwischen Sender und Empfänger auf. Ich würde das gern mit den RSSI Daten konkretisieren. Aber, wie gesagt, ...

    Des weiteren habe ich den Eindruck, dass die Prüfsumme nicht übertragen wird. Wird der vom ASH2000 nicht gesendet oder wird der im CUL verworfen?

3. Der S2000R (Regensensor) sendet Daten, die sich leicht vom Protokoll (http://www.dc3yc.homepage.t-online.de/protocol.htm (http://www.dc3yc.homepage.t-online.de/protocol.htm)) unterscheiden. Oder der CUL empfängt sie anders.

    Beispiel:

    2015.01.20 14:21:50 2: CUL433: unknown message p 9  752  384  352  864 10  4 2 44 4FD610F780  384  240
    Schlüsselt man das Datenpaket wie oben beschrieben auf, so erhält man:

    01001     11111     01011     00001     00001     11101     11100     00000
2         f         a         0         0         Check1    Check2

    Die Adresse sollte eigentlich niemals f sein können. Vermutlich liegt hier das Problem im Reverse-Engineering des Protokolls. Auch das Protokoll des S2001-ID unterscheidet sich von der Beschreibung (nur zur Info).

    Im Ergebnis ist das Problem, dass FHEM im autocreate Modus

define autocreate autocreate                                                                                                                                                                                                                                                   
attr autocreate autosave 1                                                                                                                                                                                                                                                     
attr autocreate filelog ./log/%NAME-%Y.log                                                                                                                                                                                                                                     

    im Laufe der Zeit einige Hörmann-Geräte erzeugt, von Regensensor jedoch keine Spur:

-rw-r--r-- 1 fhem dialout        0 Jan 20 11:13 CUL_HOERMANN_4FC210DF20-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:12 CUL_HOERMANN_4FC210DF90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:11 CUL_HOERMANN_4FC210EF90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 20:40 CUL_HOERMANN_4FCE10C790-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 17:56 CUL_HOERMANN_4FCE10D390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      102 Jan 20 21:51 CUL_HOERMANN_4FCE10E390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout       51 Jan 20 21:45 CUL_HOERMANN_4FCF086390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:22 CUL_HOERMANN_4FD210FFA0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:13 CUL_HOERMANN_4FD610F7D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:23 CUL_HOERMANN_4FD9087FD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      102 Jan 20 11:22 CUL_HOERMANN_4FE1086F90-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout      153 Jan 20 21:53 CUL_HOERMANN_4FE7086390-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:23 CUL_HOERMANN_4FE9087FD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 12:00 CUL_HOERMANN_4FED0877D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:35 CUL_HOERMANN_4FF610B7A0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 14:33 CUL_HOERMANN_4FF610B7D0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 15:07 CUL_HOERMANN_4FFB085BD0-2015.log                                                                                                                                                                                               
-rw-r--r-- 1 fhem dialout        0 Jan 20 11:15 CUL_HOERMANN_67E1086F90-2015.log                                                                                                                                                                                               

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Januar 2015, 00:07:18
Hallo Hermann,

erst mal danke für den Test.

Zitat
Wenn ich die "raw RSSI" Daten sehen möchte

Meinst Du das was bei Xa7 wegen Bit 7 kommen sollte, dann ja, weil ich das im Code bei der Ergänzung des Keying Protokolls raus genommen hatte, da mit Bit5 ohnehin die RSSI (Register)-Werte als Hex Wert kommen (das DE im Beispiel unten), die dann nur entsprechend umgerechnet werden müssen. Grund 1 war, Speicherplatz für CUL_V2 zu sparen. Grund 2 ist, dass man bei COC damit die Ausgabe des einzelbit Empfangstimings einer ganzen Nachricht aktivieren kann und damit richtig sehen kann, wie gut oder schlecht die Daten bezüglich Timing empfangen werden und dann ist die Ausgabe dieses Wertes vor der eigentlichen Nachricht etwas störend.
Könnte ich bei Bedarf bei CUL_V3 aber wieder mit rein nehmen, da der nicht genug Pufferspeicher für die bit-Timing Ausgabe hat.
Die Umrechung in dem Quell-Code wäre dann:

      rssi = (rssi >= 128 ? rssi-128 : rssi+128);    // Swap
      if(rssi < 64)                                  // Drop low and high 25%
        rssi = 0;
      else if(rssi >= 192)
        rssi = 15;
      else
        rssi = (rssi-80)>>3;
      DC('a'+rssi); // ouput data char

... was aber ohne Probleme FHEM beim Empfang in 00_CUL.pm machen und ausgeben kann. Für K... Nachrichten, die kommen, macht es so was auch für die RSSI Werte.


Zitat
Einige von CUL433 an FHEM gesendete Pakete werden verworfen. Beispiel:

Der Empfang des KS Protokolls prüft auf die Stopbits und die Checksummen. Wenn da was nicht stimmt, dann wird das Paket in CUL verworfen, also keine K... Message an FHEM gesendet. Die Rohdatenbitausgabe, die Du akiviert hast, aber doch. Mit der macht aber FHEM nichts.

Zitat
Es zeigt sich, dass man ein Bit (das Bit vor dem markierten Bit) verwerfen muss, um ein gültiges und sinnvolles Paket zu erhalten
Schön analysiert. Wenn es auch einem sinnvollen Messwert entsprechend den Umgebungsbedingungen entsprochen hat.
Ich beobachte bei mir, dass sich die Sendedaten der Einzelsensoren von Zeit zu Zeit überlagern und dann Unsinn kommt. Außerdem sendet noch irgendwas aus der Nachbarschaft regelmäßig und stört schon mal. Und ein TX3 Sensor quasselt auch häufig dazwischen.
Aber das Timing ist ohnehin schon auf der Senderseite nicht so doll, wie ich an einem WS2000 Repeater an der Signalquelle für den Sender messen konnte, von daher ist der Empfang schwierig. Die Empfangstimingauswertung ist ein Kompromiss, respektvie, wenn beim Sync das keying erkannt wird und es dann schief geht, dann ist das Empfangspaket leider zu schlecht. Ich bin eigentlich ganz froh mit dem was bei mir durch kommt. "Sens" habe ich bei mir übrigens auf 8 bei CUL eingestellt, vielleicht hilft Dir das noch.

Zitat
Die Filterung der Rohwerte lässt von Zeit zu Zeit ein paar Störungen durch
Die Flanken kommen so in der Firmware vom Empfänger des CUL an. Würde man speziell auf das KS Protokoll abzielen, dann wäre da eventuell noch was zu machen, aber dann fliegen die übrigen empfangbaren Protokolle teilweise wieder raus. Der Auswertungsansatzt, wie ich ihn im Quelltext vorgefunden hatte ist da schon ziemlich clever und flexibel gewählt.

Zitat
Der S2000R (Regensensor) sendet Daten
...

Du must auch noch die 4 und die 2 beachten. Es sind 4 bytes + 2 bits = 34 bits empfangen worden, also musst Du die 0000 am Ende streichen. Das fehlende Stopbit beim jeweils letzten Nibble wird auch noch bei der Prüfung "ergänzt" (was auch noch scheitern kann).
Nach XOR-Check und Summe würde Protokoll V1.2 hier passen.
V1.1 sendet die Summe nicht (und das habe ich in der Firmware ergänzt, dass auch das noch als K... Message bis FHEM durch kommt.)
Sendet der immer f als Adresse? Oder nur wenn es regnet? Leider habe ich den Sensor nicht, um damit mehr nachvollziehen zu können. Das wäre aber ohnehin eine Frage der nachgeschalteten FHEM Auswertungen in CUL_WS.
Kam denn die K... Message dazu rüber? Denn dann wäre in der CUL Firmware dabei alles ok gewesen. Aktiviere verbose 4 für den CUL, um die K... messages im LOG zu sehen.

Die 10 davor sagt übrigens, dass 10 sync bits empfangen wurden, bevor es mit der message los ging.

Zitat
Im Ergebnis ist das Problem, dass FHEM im autocreate Modus
...

Das ist leider nur dadurch zu vermeiden, dass Du die Sensoren einmal dazu einträgst (oder eintragen lässt) und dann Autocreate deaktivierst und den Müll wieder aus der Config entfernst. Hörmann ist auch das am wenigsten in CUL weiter geprüfte bzw. gefilterte Protokoll. Mit mehr Infos dazu könnte man hier eventuell mehr raus werfen.

Man könnte die Timing Prüfung in CUL noch schärfer programmieren, aber dann kommen auch deutlich weniger gültige Pakete durch. Das will ich jedenfalls nicht und habe das für meine Wettersensoren auch durch.

Also bis auf den Regensensor siehst Du nun alle Sensoren in FHEM?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 21 Januar 2015, 13:00:38
Hallo Ansgar,

danke für die zeitnahe und informative Antwort, die mich ein gutes Stück vorangebracht hat.

Zum Bit 7 (von Xa7). Ist CUL_V2 noch ein Thema? Ich bin zwar kein Freund von bedingter Übersetzung. Aber: wenn man schon den CUL_V2 Zombie pflegen möchte, kann man nicht einzelne Funktionen in bedingter Übersetzung einklammern?

Die Überprüfung der Rohdaten hatte ich so erwartet. Gut, dass die Rohdatenausgabe vorher zuschlägt, so dass man das Problem überhaupt bemerkt.

Zitat
Wenn es auch einem sinnvollen Messwert entsprechend den Umgebungsbedingungen entsprochen hat.

Klar, das hatte ich bei dem Beispiel und bei weiteren Beispielen natürlich sichergestellt, sonst wäre die Bitfummelei sinnlos gewesen. Noch ein Beispiel zweier aufeinanderfolgender Messungen:

2015-01-20 13:35:17 8A4BD0E73DE0

 1 0 0 0|1 0 1 0|0 1 0 0|1 0 1 1|1 1 0 1|0 0 0 0|1 1 1 0|0 1 1 1|0 0 1 1|1 1 0 1|1 1 1 0|0 0 0 0

 10001     01001     00101     11101     00001     11001     11001     11101     11100     00000
 1         2         4         7         0         3         3         7         7         0
 Type      Adr,0     7.4                           73.3                          Check1

2015-01-20 13:38:13 8B25F439CF78

 1 0 0 0|1 0 1 1|0 0 1 0|0 1 0 1|1 1 1 1|0 1 0 0|0 0 1 1|1 0 0 1|1 1 0 0|1 1 1 1|0 1 1 1|1 0 0 0

 10001     01100     10010     11111     01000     01110     01110     01111     01111     000
             ↑
           remove

 10001     01001     00101     11110     10000     11100     11100     11110     11110     00000
                                  ↑
                                remove

 10001     01001     00101     11101     00001     11001     11001     11101     11100     00000
 1         2         4         7         0         3         3         7         7         0
 Type      Adr,0     7.4                           73.3                          Check1

Die Symptome sind, dass niemals ein Bit hinzugefügt werden muss, dass fast immer 1-Bits (= keine 0-Bits) entfernt werden müssen und dass manchmal auch mehrere Bits entfernt werden  müssen.

Zitat
Ich beobachte bei mir, dass sich die Sendedaten der Einzelsensoren von Zeit zu Zeit überlagern und dann Unsinn kommt. Außerdem sendet noch irgendwas aus der Nachbarschaft regelmäßig und stört schon mal.

Beide Erklärungen scheiden bei mir aus. Der nächste Nachbar wohnt 60 m weit entfernt und ich habe lediglich 5 WS2000 Geräte (im 433 MHz Bereich). Und da die in einen streng vorgegebenen und mir bekanntem Zeitraster senden, kann das beschriebene Problem nicht durch Kollisionen erzeugt worden sein.

Ich kenne die rohen OOK Signale vom Scope. Da wird man schnell zum Fan von FM. Und wenn das noch für verschiedene Quellen funktionieren soll, dann wird es endgültig zum Problem. sens steht bei mir auf 4 dB. Nachdem ich es auf 8 dB gesetzt hatte, hat sich Folgendes geändert:

 1 Ich kann jetzt einen sehr schwachen Sensor (RSSI -97.5 dB) empfangen, der vom FTH2000 (ELV Produkt) nicht empfangen wird.

 2 Zwei andere Sensoren (RSSI -56 dB, RSSI -60 dB, RSSI -70 dB) hatten mit sens=4 dB etwa 6 erfolgreiche Übertragungen pro Stunde. Mit sens=8 dB sind es etwa 15.

 3 Die anderen Sensoren (RSSI -87 dB) werden nach wie vor gut empfangen: etwa 15 erfolgreiche Übertragungen pro Stunde.

Fazit: Für WS2000 (= SlowRF) sollte sens auf 8 dB gesetzt werden. Die wenigen verworfenen Pakete haben immer noch "zu viele Einsen".

Zitat
Sendet der immer f als Adresse? Oder nur wenn es regnet?

Derzeit befindet sich der Sensor bei mir im Arbeitszimmer. Es regnet hier drinnen nicht. ;) Für den Sensor erzeuge ich Regen, indem ich das Gerät vorsichtig hin und her kippe. Dann zählt er wie erwartet, aber an der Adresse ändert das nichts.

Zitat
Aktiviere verbose 4 für den CUL, um die K... messages im LOG zu sehen.

Das bringt Klarheit. Ein "normaler" ASH2000 sieht so aus:

2015.01.21 11:40:06 4: CUL_Parse: CUL433 K51894079D1 -97.5                                                                                                                                                                                                                     
2015.01.21 11:40:06 4: CUL_Parse: CUL433 p 9  784  416  288  896 10  6 1 D1 8D6630967DFF80  320  240

Der Regensensor (S2000R-1) sieht so aus:

2015.01.21 11:38:44 4: CUL_Parse: CUL433 KF20E017                                                                                                                                                                                                                             
2015.01.21 11:38:44 4: CUL_Parse: CUL433 p 9  800  432  336  848  9  4 2 17 4FDE10E780  256  240

Hier fehlt der RSSI.

Zitat
... und den Müll wieder aus der Config entfernst

Klar, mach ich ohnehin. fhem.cfg  >:( und autocreate  >:( sind wesentliche Schwachstellen von fhem:

 1 In der Datei sind dynamische (z.B. actStatus) und statische (z.B. define) Einträge vermischt. Das erschwert die händische Pflege der Datei. Vgl. z.B. die Einführung der Verzeichnisse /etc und /var in unixoiden Systemen.

 2 FHEM verändert die Datei von Zeit zu Zeit so (trailing white space), dass ein händischer Vergleich erschwert wird.

Zitat
Also bis auf den Regensensor siehst Du nun alle Sensoren in FHEM?

Jau. Aber es steht noch der S 2000 W aus.

Viele Grüße

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 21 Januar 2015, 18:16:11
Hallo Ansgar,

vom "S 2000 W" (Windsensor) empfängt der CUL nach dem Einschalten:

2015.01.21 15:55:17 4: CUL_Parse: CUL433 K73005027E4 -88                                                                                                                                                                                                                       
2015.01.21 15:55:17 4: CUL_Parse: CUL433 p 9  896  304  416  752  9  6 1 E4 CF4210D7A92C00  368  240                                                                                                                                                                           

Das sieht erst einmal ganz nett aus. Auch wenn man sich die Daten näher ansieht, bleibt der gute Eindruck:

2015-01-21 15:55:17 CF4210D7A92C00

 1 1 0 0|1 1 1 1|0 1 0 0|0 0 1 0|0 0 0 1|0 0 0 0|1 1 0 1|0 1 1 1|1 0 1 0|1 0 0 1|0 0 1 0|1 1 0 0|0 0 0 0|0 0 0 0

 11001     11101     00001     00001     00001     10101     11101     01001     00101     10000
 3         7         0         0         0         5         7         2         4         1
 Type      Adr,0     000 (velocity)                275 (direction)               Check1    Check2

2015-01-21 16:26:33 CF421084B9CC80

 1 1 0 0|1 1 1 1|0 1 0 0|0 0 1 0|0 0 0 1|0 0 0 0|1 0 0 0|0 1 0 0|1 0 1 1|1 0 0 1|1 1 0 0|1 1 0 0|1 0 0 0|0 0 0 0

 11001     11101     00001     00001     00001     00001     00101     11001     11001     10010
 3         7         0         0         0         0         4         3         3         9
 Type      Adr,0     000 (velocity)                340 (direction)               Check1    Check2

Bei der zweiten Übertragung hatte ich die Windfahne um etwa 90 Grad verdreht.

Es sieht so aus, als wäre der CUL aus dem Schneider. Liege ich da richtig?

fhem erzeugt mit "autocreate" die üblichen Hörmann Protokolldateien und versaut auch gleich die fhem.cfg. Kann ich was sinnvolles in die fhem.cfg eintragen?

Viele Grüße

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Januar 2015, 23:58:33
Hallo Hermann,

Zitat
kann man nicht einzelne Funktionen in bedingter Übersetzung einklammern?

Das ist an der Stelle sogar so, aber nicht in Deinem Sinne.  ;)

Da mit Rohdatenausgabe auch der RSSI rüber kommt und mit voller Auflösung, macht es aus meiner Sicht mehr Sinn, die Rohdatenausgabe bezüglich RSSI und Umrechnung in 00_CUL.pm auszuwerten und im Log auszugeben. Aber nicht mehr heute Abend.

Zitat
Klar, das hatte ich bei dem Beispiel und bei weiteren Beispielen natürlich sichergestellt

Gut, denn ab und zu reicht bei mir die Checksummenabsicherung nicht, um fehlerhafte Daten raus zu werfen. Deswegen muss ich fragen.

Zitat
Die Symptome sind, dass niemals ein Bit hinzugefügt werden muss, dass fast immer 1-Bits (= keine 0-Bits) entfernt werden müssen und dass manchmal auch mehrere Bits entfernt werden  müssen.

Danke für den Hinweis. Nun das könnte auf ein Problem beim Keying Collect hindeuten, bzw. auch bei den Einstellungen des Receivers. Demnach müssten kurze Pulse vom Receiver kommen, die dann als bit missinterpretiert werden. (mit Flankeninterrupt werden die Rohsignaldaten vom Receiver ausgewertet)
Mit der alten Auswertung würden die Pakete dann direkt verworfen, wegen ganz unpassendem Timing im Vergleich zum Sync Timing und den letzen empfangenen Bits. Keying schaut nur danach, ob lowtime > hightime oder umgekehrt ist. Das würde in diesem Falle kurze High Pulse, also Spikes bedeuten.
Die Gesammtlänge könnte ich da auch prüfen, um das (ganze Paket) raus zu werfen. Aber das Paket wäre halt trotzdem verloren, weil vorher schon der Timer genullt wird, um möglichst genau die Zeit messen zu können und gleichzeitig den Interrupt Timeout für Paket Ende neu loslaufen zu lassen.
Also erst mal die Quelle der kurzen Pulse aufdecken und eliminieren wäre günstiger. Denn die Art der Auswertung hat für die WS Sensoren bei mir zu einer deutlichen Verbesserung beim Empfangserfolg geführt.

Zitat
Ich kenne die rohen OOK Signale vom Scope

Wenn Du da einen Empfänger hast und mit dem Scope zuschauen kanst, könntest Du da mal schauen, ob die Sensoren da schon mal Mist in die Sendepulse einbauen?
Wenn die es nicht sind, dann müssten man einen tiefen Blick in die Receiver Doku werfen, um zu schauen, ob da noch was an den Registereinstellungen zu optimieren wäre (möglicherweise natürlich mit Einfluss auf andere Protokolle mit kürzerem Timing).
Aber vielleicht geht es auch einfacher. Teste bitte mal sens 12. Der Ansatz mit 8 war ja schon gut.

Zitat
Es regnet hier drinnen nicht. ;)

Gut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

Zitat
Hier fehlt der RSSI.

Ich schätze mal, Du benutzt nicht meine 00_CUL.pm aus der zip Datei. Der RSSI hängt noch nicht ausgewertet hinten dran. Die original 00_CUL.pm kann nicht mit ungeraden Anzahlen von Nibbles.

Zitat
Es sieht so aus, als wäre der CUL aus dem Schneider. Liege ich da richtig?
V1.2 und sieht gut aus.  :) Und wenn Du noch Wind in Deine Bude bringst, noch besser.  ;D

Zitat
fhem erzeugt mit "autocreate" die üblichen Hörmann Protokolldateien und versaut auch gleich die fhem.cfg. Kann ich was sinnvolles in die fhem.cfg eintragen?

####################################################################
# automatische Sensordetektion, nur Kommentar entfernen, wenn neue Sensoren entdeckt werden sollen
####################################################################

#define autocreate autocreate
#attr autocreate autosave 1
#attr autocreate device_room %TYPE
#attr autocreate filelog /opt/fhem/log/%NAME-%Y.log
#attr autocreate weblink 1
#attr autocreate weblink_room NeueSensoren

############################
# CUL WS 433.92 MHz
############################

define CUL_WS433 CUL /dev/ttyACM1@38400 0000
attr CUL_WS433 room Receiver
attr CUL_WS433 verbose 2

#################################
# CUL WS 433.92MHz Sensoren
#################################

define CUL_WS4_bla3 CUL_WS 3
attr CUL_WS4_T_bla3 IODev CUL_WS433
attr CUL_WS4_T_bla3 room Sensoren_WS4

define CUL_WS4_blub7 CUL_WS 8
attr CUL_WS4_blub7 IODev CUL_WS433
attr CUL_WS4_blub7 room Sensoren_WS4

Und die anderen Sensoren mit Code = Adresse+1 entsprechend.
Bei Adresse 7wird gesammelt, was auf Adresse 7 von den verschiedenen Sensoren rein kommt.

Wenn Du gerne viel Log siehst, dann geht auch verbose 4 oder 5. Aber mach das nur, wenn Du die Logs auf eine Festplatte schreibst. Ich habe mir schon nach einem viertel Jahr den ersten USB-Stick zerschossen, auf den ich die FHME Logs geschrieben habe (zu viele Schreibzugriffe -> möglich Flash Schreibzyklen zu schnell erschöpft).

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 19:54:26
Hallo Ansgar,

ich beantworte deine Hinweise mal Punkt für Punkt.

Zitat
Ich schätze mal, Du benutzt nicht meine 00_CUL.pm aus der zip Datei.

So war es. Ich hatte ganz übersehen, dass in culfw-code-459-trunk_lufa_rf_cr_sd_72.zip noch eine 00_CUL.pm oberhalb des Unterverzeichnisses war. Leider wird mein fhem-2015-01.log jetzt geflutet mit

2015.01.22 19:43:54 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:54 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:57 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:43:57 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:44:12 1: PERL WARNING: Use of uninitialized value $hmSioDly in subtraction (-) at ./FHEM/00_CUL.pm line 1190.
2015.01.22 19:44:12 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/00_CUL.pm line 1190.

Dadurch wird mein  log sehr unübersichtlich. Lässt sich das abstellen?

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 20:15:47
Hallo Ansgar,

Zitat
V1.2 und sieht gut aus.  :) Und wenn Du noch Wind in Deine Bude bringst, noch besser.  ;D

ich habe den Windsensor ausgewildert. Heute weht fast kein Lüftchen, aber dennoch meldet der Sensor sinnvolle Daten. Z.B.:

2015.01.22 19:34:04 4: CUL_Parse: CUL433 K73040058F4 -80                                                                                                                                                                                                                       
2015.01.22 19:34:04 2: CUL433: unknown message p 9  832  352  336  848  9  6 1 F4 CF4A108475BD80  384  240

Der Datensatz  übersetzt sich in Geschwindigkeit 4 (= vermutlich 0.4 km/h Windgeschwindigkeit), Richtung 180 (= Süd), Schwankungsbreite der Richtung 1 (= ±22.5°). Die RSSI ist jetzt auch im Log.

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 20:24:26
Hallo Ansgar,

Zitat
Gut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

Der Regensensor ist flammneu, frisch aus der Verpackung und ohne Staub.;D Er hat keinen Feuchtesensor. Er hat "nur" die Wippe. Ich habe ihn mal nach draußen gestellt aber auf den Regen muss ich noch ein paar Tage warten.

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Januar 2015, 20:40:58
Hallo Hermann,

Zitat
Dadurch wird mein  log sehr unübersichtlich. Lässt sich das abstellen?

... ich hab da doch was gelesen... Ja, indem Du den HM CUL auch auf meine Firmware Version flashst.

Denn selbst wenn ich den Logeintrag abstelle, das alte Warten habe ich raus genommen, da CUL bei mir wartet. Und dann würde HM nicht gesendet, da CUL in alter Version den Befehl nicht versteht.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 20:43:05
Hallo Ansgar,

Zitat
Teste bitte mal sens 12. Der Ansatz mit 8 war ja schon gut.

Okay.

2015.01.22 19:41:42 3: Setting AGCCTRL0 (1D) to 92 / 12 dB

Ich muss mir das jetzt erst einmal einen Tag laufen lassen, denn die Empfangssituation verändert sich periodisch im Tagesverlauf.

Eines interssiert mich aber jetzt schon. Seit ich sense geändert habe, treten im Protokoll in schöner Regelmäßigkeit Zeilen der Art

2015.01.22 20:00:06 4: CUL_Parse: CUL433  264418 A FF02 00134616 00 01 CE -138
2015.01.22 20:05:39 4: CUL_Parse: CUL433  073141 A FF02 00467640 00 01 CE -138
2015.01.22 20:11:12 4: CUL_Parse: CUL433  406152 A FF02 00800664 00 01 CE -138
2015.01.22 20:16:45 4: CUL_Parse: CUL433  214875 A FF02 01133688 00 01 CE -138
2015.01.22 20:22:18 4: CUL_Parse: CUL433  023598 A FF02 01466712 00 01 CE -138
2015.01.22 20:27:51 4: CUL_Parse: CUL433  356610 A FF02 01799736 00 01 CE -138                                                                     
2015.01.22 20:33:24 4: CUL_Parse: CUL433  165333 A FF02 02132760 00 01 CE -138

Die Zeilen unterscheiden sich wesentlich von den anderen "CUL_Parse"-Zeilen. Was bedeuten die Einträge?

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 20:48:12
Hallo Ansgar,

Zitat
indem Du den HM CUL auch auf meine Firmware Version flashst

HM läuft bei mir auf einem CUNO, auf dem CUL läuft ausschließlich SlowRF. Kann ich die Meldungen ignorieren?

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 21:05:11
Hallo Ansgar,

Zitat
Gut, denn ab und zu reicht bei mir die Checksummenabsicherung nicht, um fehlerhafte Daten raus zu werfen. Deswegen muss ich fragen.

ich habe mal bei einigen WS2000 Paketen die XOR und die SUM nachgerechnet. Die XOR stimmt immer, die SUM stimmt fast nie. Beispiele:

2015-01-21 18:30:11 8D6230E623EF00 (K51813081 D3, RSSI -96.5)

 1 0 0 0|1 1 0 1|0 1 1 0|0 0 1 0|0 0 1 1|0 0 0 0|1 1 1 0|0 1 1 0|0 0 1 0|0 0 1 1|1 1 1 0|1 1 1 1|0 0 0 0


 10001     10101     10001     00011     00001     11001     10001     00011     11101     1110!
 1         5         1         8         0         3         1         8         7         7
 Type      Adr,0     8.1                           81.3                          XOR       SUM      xor=7 sum=b

2015-01-22 01:11:31 8D4630E67D9F00 (K51883079 D4 -96)

 1 0 0 0|1 1 0 1|0 1 0 0|0 1 1 0|0 0 1 1|0 0 0 0|1 1 1 0|0 1 1 0|0 1 1 1|1 1 0 1|1 0 0 1|1 1 1 1|0 0 0 0|0 0 0 0

 10001     10101     00011     00011     00001     11001     10011     11101     10011     1110!
 1         5         8         8         0         3         9         7         9         7
 Type      Adr       8.8                           79.3                          XOR       SUM      xor=9 sum=9

2015-01-22 01:17:20 8D6630867EEF80 (D1 -97.5)

 1 0 0 0|1 1 0 1|0 1 1 0|0 1 1 0|0 0 1 1|0 0 0 0|1 0 0 0|0 1 1 0|0 1 1 1|1 1 1 0|1 1 1 0|1 1 1 1|1 0 0 0|0 0 0 0

 10001     10101     10011     00011     00001     00001     10011     11110     11101     11110
                                                                          ↑
                                                                        remove

 10001     10101     10011     00011     00001     00001     10011     11101     11011     1110!
 1         5         9         8         0         0         9         7         b         7
 Type      Adr,0     8.9                           79.0                          XOR       SUM      xor=b sum=7

Ich habe deshalb den Sensor mit der Adresse 5 ausgewählt, weil ich ihn (= sein Programm) kenne. Darüber hinaus habe ich seine Signale sehr gründlich geprüft. Ich behaupte mal, dass es nicht sein kann, dass er fast immer (mit einer Häufigkeit von 15/16) falsche SUMmen sendet. Empfängt der CUL überhaupt die SUMme? Oder überschreibt er sie?

Zitat
Das fehlende Stopbit beim jeweils letzten Nibble wird auch noch bei der Prüfung "ergänzt" (was auch noch scheitern kann).

Das verstehe ich nicht. Das letzte Stoppbit wird doch wie alle anderen Bits vorher empfangen. Warum erfordert das eine Sonderbehandlung?

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Januar 2015, 21:12:12
Hallo Hermann,


Zitat
aber auf den Regen muss ich noch ein paar Tage warten.

Ist es schon so kalt, dass Wasser aus einem Glas direkt beim reinschütten in den Trichter gefriert?  ;)


Zitat
treten im Protokoll in schöner Regelmäßigkeit Zeilen der Art

Das sind HM Pings aus den Änderungen für HM in Firmware und 00_CUL.pm. Damit messe/aktualisiere ich die IO Zeiten um HM Antwort delays zu optimieren.
Die sollten eigentlich nur bei HM angefordert werden, aber da habe ich noch eine Unschärfe in 00_CUL.pm, so dass die Pings auch bei anderen Protokollen periodisch angefordert werden.


Zitat
HM läuft bei mir auf einem CUNO

Und hängt mit am System und läuft über 00_CUL.pm? Das gibt dann wohl erst mal einen Versionskonflikt. Bei HM würde es dann bei Dir jetzt nicht mehr wirklich laufen?!?
Da müsste ich dann mal einen Mix-bau von 00_CUL.pm machen.

Zitat
die SUM stimmt fast nie
XOR mit in die Summ und +5

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 21:46:38
Hallo Ansgar,

danke für die Hinweise. Die haben einige Fragen beantwortet.

Zitat
Und hängt mit am System und läuft über 00_CUL.pm? Das gibt dann wohl erst mal einen Versionskonflikt. Bei HM würde es dann bei Dir jetzt nicht mehr wirklich laufen?!?

das Problem hatte ich glatt übersehen. Denn bis heute hatte ich lediglich den CUL433 neu geflasht. Klar, der CUNO verwendet das gleiche 00_CUL.pm. Und seit etwas mehr als einer Stunde ist HM tot. Schade. Dann werde ich zunächst wieder die "alte" 00_CUL.pm restaurieren, denn die einzig sichtbare Verbesserung ist derzeit bei mir, dass die RSSI beim Regensensor mit der neuen 00_CUL.pm korrekt angezeigt wird.

Zitat
Ist es schon so kalt, dass Wasser aus einem Glas direkt beim reinschütten in den Trichter gefriert?

Das würde schon durchlaufen und dabei die Wippe genau so bewegen, wie ich es vorher durch Neigen des Gehäuses gemacht habe. Von der Wippe läuft es dann direkt durch Öffnungen im Gehäuse auf den Boden. Ich kann mir nicht vorstellen, dass dabei irgendetwas Unvorhergesehenes passiert. Deshalb ist meine Motivation, Wasser in den Trichter zu giessen, recht klein. Zumal sich das "Problem" ohne mein Zutun erledigt.

Zitat
XOR mit in die Summ und +5

Oops, ist das peinlich. :-[

    nib2fifo_ (crc_);
    nib2fifo_ ((sum_ + 5u) & 0xf);

Wenn man bedenkt, dass crc_ und sum_ durch nib2fifo() weiter gerechnet werden, hätte ich meine Zeilen verstehen müssen.

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Januar 2015, 22:33:49
Hallo Hermann,

Zitat
dass die RSSI beim Regensensor mit der neuen 00_CUL.pm korrekt angezeigt wird.

Dann wirf einen Blick in CUL_Parse und bau Dir die RSSI Anzeige richtig ein, wenn sie Dir so viel hilft.

Alternativ kannst Du Dir natürlich auch die Firmware anschauen und bei CUNO die nötigen Anpassungen ergänzen, damit Du die Firmware auch auf CUNO laufen lassen kannst.  :)


Zitat
, weil ich ihn (= sein Programm) kenne

Hast Du Dir einen eigenen Sensor gebaut und/oder eine eigene Firmware für einen WS Sensor geschrieben?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 22 Januar 2015, 23:16:22
Hallo Ansgar,

Zitat
Hast Du Dir einen eigenen Sensor gebaut und/oder eine eigene Firmware für einen WS Sensor geschrieben?

einen eigenen Sensor auf Basis eines Cortex M0+. Ich war über den SHT75 (Feuchte-/Temperatursensor) gestolpert und der versprach in dem Bereich, der in der Bauphysik interessant ist (Luftfeuchtigkeiten zwischen 85 und 100%: Gefahr der Kondenat-/ Schimmelbildung) wesentlich höhere Genauigkeiten (± 1.8 %) als die "üblichen" Sensoren. Die Schaltung kann auch den HYT 271 auslesen, der ist genau so gut. Die Genauigkeit im Bereich 50 % ist nicht relevant, da passiert nichts. In der Tat ist es so, dass der SHT75 derzeit 80% anzeigt, der ASH 2000 liegt bei 71.5% und ein HomeMatic HM-WDS10-TH-O zeigt 74 %. Der SHT75 zeigt den richtigen Wert an. Im Übrigen waren zwei der ASH2000 ausgefallen und ich wollte sie ersetzen.

Ein Nebenziel war die Verringerung des Stromverbrauchs.

Ich bin gerade dabei, den Sensor auf HM umzustellen. WS2000 ist Altlast.

Gruß

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 23 Januar 2015, 22:29:04
Hallo Hermann,

im Anhang eine neue Firmwareversion für CUL_V3. Teste bitte zusammen mit 00_CUL.pm in der original Fassung statt meiner, damit Du kein Problem mit CUNO und HM bekommst.

Ich habe mal den Versuch einer Spike Filterung eingebaut. Mal schauen, ob es gegen die überflüssigen bits hilft. Alles, was kürzer als 80µs high ist sollte nun nicht mehr durch kommen.
Bitte sens auch wieder auf 8 setzen.

Zu dumm, dass wir die Einzelpulszeiten nicht aufzeichnen können, um zu einer sinnvollen Filterzeit zu kommen. Länger kollidiert auch mit einem anderen Protokoll.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 24 Januar 2015, 12:51:11
Hallo Ansgar,

vielen Dank für die Spezialfirmware. Ich habe sie auf den CUL433 geflascht und die 00_CUL-pm restauriert.

Jetzt heißt es erst einmal beobachten und die Spezialversion mit der Standardversion für sens =4,8,12 zu vergleichen. Da die Empfangssituation im Tagesrhythmus schwankt, muss ich für eine belastbare Aussage wohl einige Tage Daten sammeln, um sie nachher auszuwerten. Ich melde mich dann.

Nochmals vielen Dank

Hermann
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 02 Februar 2015, 11:03:29
Zitat
Gut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

Inzwischen hat es geregnet. Ob Sonne oder Regen, die Adresse des Regensensors bleibt immer auf 15. Auf dem Board befinden sich vier Lötbrücken, die zur Adresseinstellung dienen könnten. Das würde alles erklären.





Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hermannk am 03 Februar 2015, 09:24:00
Zitat
bleibt immer auf 15

Der Vollständigkeit halber habe ich die Funktion der Lötbrücken der Regenmesserplatine beschriftet. Die rechte Lötbrücke ändert weder die Adressierung noch ändert sie das Erscheinungsbild der Übertragung, wie sie von CUL im X27-Modus dargestellt wird. Um es noch einmal klarzustellen: Die Adresse lässt sich im Bereich zwischen 8 und 15 wählen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Februar 2015, 00:27:07
Hallo Hermann,

angehängt findest Du eine neue Version zum Testen von/mit SlowRF.

In der Firmware habe ich noch an der Filterung gefeilt. Eventuell ist es jetzt etwas scharf.

Beim X kommt nun auch bei Bit 7 der RSSI, wie ursprünglich.

Dafür habe ich eine Timing Ausgabe der ersten 15 Daten- und Stopbits ergänzt. Die ist aktivierbar mit einer zusätzlichen 1 nach den bisherigen Codes, z.B. X211. Ausgegeben werden die ermittelten Timings für Low und High Bit und anschließend die Bit Timings, alle mit 16 zu multiplizieren.

Beispiel (allerdings noch die Ausgabe eines Syncs):
2015.02.01 17:00:20.822 2: CUL_0: unknown message C:51 23 21 54|51;25|51;24|51;25|51;24|51;24|51;24|51;25|51;25|21;54
2015.02.01 17:00:20.832 2: CUL_0: unknown message C|22;54|51;24|52;23|53;22|22;54|22;54#

Sollte CUL etwas überlastet sein und mehr als ein "bucket" genutzt werden, dann kann diese Timinginfo nicht gesammelt werden, bis das letzte "bucket" komplett mit Timingausgabe an den Host gesendet wurde, also dabei auf Fehlinterpretationsmöglichkeiten achten.

Wenn die beigepackte 00_CUL.pm genutzt wird (die Du wegen CUNO HM noch nicht nutzen kannst), dann wird das auch umgerechnet in us und in eine Logzeile gepackt, Beispiel:
2015.02.05 23:51:12.811 4: CUL_Parse: CUL_0 C:832 352 352 848 |352;848|848;368|832;368|848;368|352;848|848;368|832;368|848;368|848;368|352;848|352;848|848;368|352;848|864;352|368;848

Damit kannst Du also die Empfangstimings mit Deinen Sendetimings vergleichen.

Außerdem ist die BITs Ausgabe geändert, Beispiel:
2015.02.05 23:51:12.807 4: CUL_Parse: CUL_0 p 6  832  352  352  848  9  6 1 2C  52 886A1494B9AD80  368  176   0   0

Die 2C und 52 sind jeweils die RSSI Ausgabe, wobei die 52 als -52dB zu interpretieren sind. Am Ende hängen noch Anzahl Ansprechen Glitch Filter und Anzahl Ansprechen Pulszeitlimitunterschreitungsfilter (Spikefilter) an. Es werden dabei Low und High Zeit gefiltert/überwacht.

In der beigepackten 14_CUL_WS.pm ist der Regensensor nun drin (sofern ich nicht was übersehen habe). Testen kann ich es mangels Sensor leider nicht.

Wie sind Deine bisherigen Erfahrungen mit der letzten Firmware 99.73?

EDIT: Ich habe nun auch mal die Änderungen, insbesondere auch für Homematic Timestamp, bei CUNO und CUNO2 eingebaut und jeweils ein Firmware HEX File compiliert. Bei CUNO habe ich auf die Einzelbittimingausgabe ganz verzichtet, da ich die Speicherauslastung nicht kenne.
Da ich aber die Hardware nicht habe, kann ich leider nicht sagen, ob damit Komplikationen auftreten können. Mit Ethernet habe ich bisher gar keine Erfahrungen sammeln können.
Also in jedem Fall vor einem Test den vorherigen Firmwarestand und natürlich ein USB-Kabel bereit halten, um ggf. wieder zurück zu kommen!
00_CUL.pm ist nun angepasst, so dass alter Firmware Stand ohne Timestamp und Timestamp fähige Firmware genutzt werden können.

EDIT2: Eine Korrektur im Anhang für die Firmware, da ein Fehler bei der V1.1 Ausgabe wegen eines ungünstig verbliebenen ";" aufgefallen ist. Ich denke, nun sollte es richtig gehen. Danke Hermann.
Außerdem macht 14_CUL_WS.pm nun ein wenig Statistik zu den Empfangszeiten, die mit list <Sensorname> unter helper einzusehen ist.

EDIT3: Ich hab in der Firmware den Reboot (raw B00 oder raw e) deutlich verlängert (8s über den Watchdog). Damit klappt nun auch Disconnect/Reconnect. Zuvor mit schnellem Reboot ist es auf meinem RasPi beim Disconnect geblieben, und nur durch Reboot RasPi oder manuelles USB Ab- und Anmelden war ein Reconnect hin zu bekommen.
In 14_CUL_WS.pm habe ich beim Parsen aufgeräumt (hoffentlich nicht zu viel) und die Empfangsstatistik auf den RSSI ausgeweitet. Und...
In 00_CUL.pm kann man diese Statistik über "get dispWSStat" bequem für diesem CUL zugeordneten WS Sensoren anzeigen und über "set clearWSStat" auch bequem löschen. Bei "get ccconf" wird nun auch die AGC Einstellung und eingestellte Datenrate angezeigt. Beispiel (das nicht eine optimale Einstellung sein muss):

CUL_0 ccconf => freq:868.350MHz bWidth:325kHz rAmpl:42dB sens:8dB drate:6.868kBit/s agcprio:1 agcwait:16 agchyst:1

drate -> Datenrate (für SlowRF Empfang relevant für die übrigen Einstellungen und vermutlich auch die zeitliche Auflösung mit der der Pegel 0/1 übermittelt wird)
agcprio -> 0=LNA 2 Verstärkung wird vor LNA Verstärkung verringert, 1=LNA Verstärkung wird vor LNA 2 Verstärkung verringert (AGCCTRL1: AGC_LNA_PRIORITY)
agcwait -> Anzahl Kanal Filter Samples nach denen erneut AGC aktiv wird (AGCCTRL0: WAIT_TIME)
agchyst -> AGC Hysterese Einstellung (AGCCTRL0: HYST_LEVEL)

Diese Parameter können für SlowRF dann auch mit set jeweils bequem angepasst werden. Damit lässt sich hoffentlich noch eine bessere Einstellung für den SlowRF Empfang finden als bisher, vgl. auch cc1101 DN022 Design Note und cc1101 Doku. Jede Änderung geht über das EEPROM des AVR Controllers (>100000 Schreibzyklen laut Spec), wie auch die übrigen Einstellungen.

Edit5: kleine Korrektur in 14_CUL_WS.pm für die Statusausgabe Windsensor. Es fehlte jeweil ein Leerzeichen zwischen den Werten.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Tobias am 28 März 2015, 07:37:39
ohne jetzt alles gelesen zu haben, ist mit dieser Erweiterung jetzt auch HM auf einem CUNO sauber möglich?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 April 2015, 12:38:41
Hallo Tobias,

da ich mittlerweile mit einem CUNO2 testen kann, kann ich sagen, dass es über Netzwerk noch nicht sauber geht. Da gibt es noch ungeklärte Disconnects.
Über USB Anbindung sollte es gehen, sofern der CPU Takt nicht nach dem Mond geht. Die dafür nötige Korrektur ist im letzten Beitrag nicht drin.

Allerdings bin ich derzeit noch mit SlowRF beschäftigt. Da sehe ich noch rätselhafte Empfangsaussetzter (alle Sensoren), die sich teilweise erst nach mehreren Stunden erholen. Und dabei verhält sich nicht jedes Gerät gleich?!? Mache haben das Problem, manche empfangen durchgehend.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Fritz R. am 07 April 2015, 09:01:57
Hallo,

ist es denkbar die Firmware auch für den nanoCUL zu bauen. Leider bin ich nicht so fit, dass ich das selber übernehmen könnte (würd ich aber mit Unterstützung probieren)
Konkret geht es mir darum das alte WS2000 Protokoll V1.1 mit einen nanoCUL empfangen zu können, die V1.2 gehen schon.
Was müsste ich von der Firmware hier alles in die nanoCUL Version übernehmen? Oder ist es einfacher diese Firmware für den nanoCUL passend zu machen?

Hab ich das richtig gesehen, dass es jetzt 3 verschiedene Zweige der Firmware für CUL gibt ?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 April 2015, 23:56:55
Hallo Fritz und Testwillige,

ich habe mal aus dem TRUNK 499 nanoCUL genommen und angepasst, so dass es mit meinen Änderungen compilierbar ist. Mangels Hardware kann ich aber nicht testen, ob es läuft, insbesondere, wie es mit dem freien Speicher aussieht. Das makefile und board.h sind für atmega328p konzipiert. Für die ältere Version mit kleinerem Prozessor sind Anpassungen nozwendig.
EDIT 1: Korrektur für NanoCUL. Es fehlte der uart_task, in der Hauptschleife. Deswegen konnte nichts mit der Kommunikation gehen.

Weiterhin habe ich SCC (STACKABLE CC) angepasst und getestet.

CUNO2 ist ebenfalls angepasst und getestet. Es sind mir nur gelegentliche Disconnects mit Reconnect aufgefallen. Der Ethernet Treiber ist noch Baustelle, denke ich.
CUNO ist ebenfalls dabei, aber mangels Hardware ungetestet.

Und natürlich ist CUL_V3 aktualisiert.

Die RF Tests beziehen sich auf SlowRF WS Sensoren mit Sendetest, TX3 Empfang und ASKSIN Empfang/Senden. Andere Protokolle kann ich nicht testen.

Wichtig: 00_CUL.pm, 16_STACKABLE_CC.pm werden für den ASKSIN Timestamp benötigt. 14_CUL_WS.pm ist angepasst/korrigiert für die WS-Sensor Auswertung. DevIo.pm enthält eine kleine Änderung zur Timeout Behandlung bei Disconnects.
Ob es mit dem aktuellen FHEM Versionsstand harmoniert, habe ich nicht getestet. Also erst die vorhandenen Dateien im FHEM Verzeichnis sichern und dann erst austauschen und testen.

Für ASKSIN Timestamp ist in 00_CUL.pm ein Scew-Faktor für die Zeitmessung ergänzt, der mit Pings in zunehmenden Abständen ermittelt wird. Hintergrund ist, dass die Taktfrequenz der CULs deutlich schwanken kann. 0.6% Abweichung zum Host ist keine Seltenheit (nur meine ersten Testlinge waren deutlich besser im Takt, daher ist mir das erst später störend aufgefallen. Martin kennt das Thema schon...).

Für Slow_RFgibt es nun auch eine Empfangs Statistik für die Sensoren. Das hilft ungemein für die Empfangsparameteroptimierung. Hermann hat mich auf den Gedanken gebracht, dass mal einzubauen. Beim Receiver (CUL) mit dispWSStat anzuzeigen und mit clrWSStat kann die Statistik gelöscht werden. Kann auch per Atrribut als Webkommando konfiguriert werden, ebenso wie ccconf, credit10ms und uptime.
Beispiel: attr CUL_0 webCmd credit10ms:uptime:ccconf:dispWSStat:clrWSStat

Die Umschaltung der RF-Modi habe ich in der Firmware umgebaut. So ist es möglich, in ASKSIN normal zu Emfangen und zu Senden und dann mal eben ein K-Kommando abzusetzen, um eine WS Testnachricht auf den Weg zu schicken. Die Firmware schaltet dann wieder zurück auf den vorherigen Empfangsmodus. Diese Variante habe ich jedenfalls erfolgreich getestet. (Natürlich ist während dieses Sendens kein Empfang möglich, so dass es natürlich ein gewisses Störverhalten gibt).

Wer mit REP_LCDMON (Bit 7 beim X Kommando) die RSSI-Ausgabe benötigt, muss sie mit #define HAS_RSSI_DISPLAY_NONLCD in board.h rein compilieren. Ich habe das rausgenommen und auch den pll-check auf alle 8s umgestellt, um nur noch selten während des Empfangs Transceiver Register abzufragen und damit den Empfang weniger zu stören.

Aufgefallen ist mir, dass einzelne meiner Testlinge schon mal im SlowRF lange Empfangsaussetzter (über 2 Stunden habe ich schon beobachtet) haben. Das fängt dann von alleine wieder (nein, nicht durch den Watchdog). Bisher habe ich aber keine Ursache dafür finden können (auch nicht im Code, aber vielleicht überseh ich da noch was). Da ich aber mehrere gleichzeitig auf Empfang der selben Sensoren habe und es nur bei bestimmten CULs/SCCs und nicht gleichzeitig Auftritt, hat es nichts mit den Sendern zu tun und es ist auch nichts Systematisches. Den Empfang erneut zu aktivieren hilft nicht und ein Reset des cc1101 Chips ebenfalls nicht. Nur die Empfangsparameter scheinen einen Einfluss zu haben (rAmpl, agcwait, agchyst).
Dafür gibt es dann einen Log Eintrag mit Komplettregisterausgabe, wenn länger nichts empfangen wird (hat aber auch keine neue Erkenntnis gebracht).
Der weitere zusätzliche Parameter dcBlockingoff funktioniert in SlowRF nur mit Einstellung 0, bei 1 habe ich noch nichts Empfangen können, vermutlich mache ich da was falsch.

@Hermann: Siehst Du auch diese längeren Empfangsaussetzer?

EDIT2: Korrektur für nextSend in 00_CUL.pm und 16_STACKABLE_CC.pm, um mit 10_CUL_HM.pm zu harmonieren.
Ausserdem ist in der Firmware für CUL_V3 die Initialisierung, sowie der B00 und B01 im Watchdog Timing geändert, um einen sicherern reconnect beim Ansprechen des Watchdog zu erreichen. Bei CUL_V3 kann der Watchdog Reset mit Raw BFF getestet werden, um das zu kompilieren dient der #define HAS_WATCHDOG_TEST.
Weiterhin ist in der Firmware das C Kommando um C0 erweitert und liefert mit "raw CC0" dann Cixxxxxxxx einen 32-bit Hex-Zähler für die seit Start aufgetretenen Interrupts von cc1101 (ISR(CC1100_INTVECT)). Das ist nützlich für SlowRF, wenn man Empfangsparameter sucht. Im aktualisierten 00_CUL.pm wird der zyklisch im Minutentakt abgefragt und daraus ein Reading "Ints_per_sec" beim CUL generiert. Unverhältnismässig viele Interrupts/s deuten auf instabile Empfangsparameter (AGC schwankt zu stark, sens ungünstig...) oder umgekehrt auf zu konservative Paramter.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Fritz R. am 08 April 2015, 10:42:22
So, erster Test mit nanoCul leider nicht erfolgreich.

1. Versuch mit WinAVR (auf Windows 7)  selber zu kompilieren (Schnittstelle im makefile geändert) gibt folgende Fehler

Compiling C: nanoCUL.c
cc1.exe: error: unrecognized command line option "-maccumulate-args"
cc1.exe: error: unrecognized command line option "-mstrict-X"
make.exe: *** [nanoCUL.o] Error 1

Leider fehlt mir hier das Wissen, es handelt sich um Fehlermeldungen im Bereich Setzten von Kompilereigenschaften ?
In der letzten von mir selber kompilierten Version für nanoCul waren diese Zeilen nicht drin (und einige andere naturlich)

2. Versuch mitgeliefertes hex File direkt draufbügeln.

Funktioniert ohne Fehlermeldung, aber die LED am nanoCul die normalerweise nur beim programmieren flackert, hört nicht mehr auf zu flackern. Kurz ausgesteckt und wieder eingesteckt. Flackern weg und Sende LED blinkt im Sekundentakt. Soweit OK. Gehe ich aber mit einem Konsolenprogramm drauf kommt zwar
ReadyNanoCulleider reagiert das Ding dann aber auf keine Eingaben. Ich weis nicht ob mit der Firmware auf "V" auch die Versionsnummer kommen sollte etc.
In FHEM eingebunden geht der Status auf opened aber dann geht auch nichts mehr.

Teste erst mal weiter, werde berichten.

Edit. Auskommentieren der beiden Fehlermeldungen bringt einen auch nicht weiter aber:
es scheint die cpufunc.h zu fehlen

Edit2: so testweise wieder die V1.63 draufgebügelt (499-trunk) . Geht wieder. Allerdings scheint es normal zu sein dass das Flackern der LED nicht aufhört, war mir vorher nicht aufgefallen. Jetzt kommt über Terminal kein ReadyNanoCul mehr, dafür kommt nach Eingabe von "V" die Version etc.
Kann das sein, dass mit dem zip-File was  altes gepackt wurde, bei mir steht da culfw-code 459... als Unterverzeichnis?

Edit3: evtl. auch ein Problem in meinem FHEM, die V1.63 bleibt jetzt auch auch opened stehen, erst nach shutdown kommt initialized. Probiere das morgen nochmal mit der .hex
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 April 2015, 21:34:08
Hallo Willi,

danke für das Feedback un Asche über mein Haupt, siehe Edit 1 im letzten Betrag. Da konnte ausser "ReadyNanoCUL" nichts kommen, weil keine Kommandos bearbeitet wurden. Lad es bitte nochmal runter.

Die LED sollte einfach nur vor sich hin blinken. Das ist die Default Einstellung. Das EEPROM wird bei Versionsnummerwechsel immer komplett neu mit Defaults beschrieben.
Mit dem LED Kommando kann man das Blinken abschalten, wenn es stört.

Die beiden Compiler Optionen sind im Makefile auch mit Kommentar beschrieben (ich benutze gcc).
Wenn der Compiler sie nicht versteht, dann Kommentier sie einfach mit einem "#" am Zeilenanfang aus.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 12 April 2015, 18:33:40
Hallo zusammen,

nur damit es bemerkt wird, mein letzter Beitrag mit Anhang http://forum.fhem.de/index.php/topic,24436.msg283515.html#msg283515 (http://forum.fhem.de/index.php/topic,24436.msg283515.html#msg283515) ist aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Fritz R. am 16 April 2015, 22:29:18
Hi,

sorry für die verspätete Antwort, war leider als Standpersonal auf der Hannovermesse eingeteilt. Ausser Kugelschreibersammlern nichts gewesen.
Danke für die Überarbeitung.
So ich hab jetzt mal die hex drauf, Konsolenfuktion sieht gut aus. FHEM meldet initialised.

Edit:

Ich habe scheinbar noch ein paar Probleme mit den alten Sensoren:

so habe ich im Log viele Eintrage mit

CUL_WS_Parse: CUL_WS_1 Error: temp/hum Cannot decode K01AA0A00 (sanitycheck). MalformedWas kann das sein ?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 April 2015, 17:24:33
Hallo Fritz,

erste Frage, empfängst Du nun überhaupt Deine Sensoren? Hast Du schon Werte gesehen?

Zitat
Was kann das sein ?
Offenbar hast Du Bitfehler beim Empfang. Gelegentlich habe ich auch diese verkrüppelten Pakete im Log, in CUL_WS habe ich die Sinnhaftigkeitsprüfung noch etwas verfeinert und von da kommen diese Log Einträge. Die Checksummenprüfung, die schon in CUL läuft, ist zu schwach, um solche fehlerhaft empfangenen Daten auszufiltern, erst recht bei Protokoll V1.1.

Was geholfen hat, ist die Empfangssitutation durch Optimierung der Antenne zu verbessern und an den Empfangsparametern für SlowRF zu spielen.

Das Reading Ints_per_sec gibt ggf. einen Hinweis auf viele kurze (Stör-)Pulse vom Empfangsbaustein. Bei guter Einstellung sind es dann bei mir etwa 20 Interrupts pro Sekunde (bei einer 868er CUL). "Kurzzeitig" gehen die aber auch mal auf 1000 hoch.
Viele Interrupts bedeuten entweder, dass viel Rauschen empfangen wird oder die AGC Regelschleife zu heftig schwankt/instabil läuft. Dann gibt es in der Doku zum cc1101 Tranceiver für den gewählet Empfangsmodus noch Spikes, die unregelmäßig auf dem Signal auftauchen können. Eventuell kommen die bei nanoCUL wegen der höheren Taktfrequenz besser durch?!?
Wie häufig die sein können wird von TI aber nicht genauer angegeben. Nur die Länge passt +/- gerade noch so in die Eingangdfilterung des Atmel rein. Ein Tiefpassfilter soll helfen, die los zu werden. In der Firmware habe ich aber auch eine Filterung drin, die funktionieren sollte, wenn die nur gelegentlich mal kommen.

Das Reading TO_Ints_per_sec gibt an, wie viele Empfangspakete pro Sekunde CUL intern zur Auswertung kommen, sprich überhaupt als Datenpakete in Frage kommen. Hängt natürlich von der Anzahl der Sensoren ab, aber muss schon deutlich unter 1 liegen (je nach Typ und Adresse senden die nur ja alle etwa 170s ein Paket).

Eine Beispielhafte Einstellung meiner 433er CUL:
CUL_WS433 ccconf => freq:433.920MHz bWidth:325kHz rAmpl:40dB sens:8dB drate:1.637kBit/s agcprio:0 agcwait:32 agchyst:1 dcBlockingoff:0Die 433er CUL rennt mit etwas 200 Interrupts pro Sekunde. Die habe ich noch nicht ruhiger bekommen können, ohne auch deutlich Empfangspakete zu verlieren.
Leider musst Du mit den Parametern spielen, um das zu optimieren. Scheint Empfängerabhängig zu sein. Die goldene Einstellung habe ich noch nicht finden können.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 April 2015, 19:13:22
Hallo Martin und Testwillige,

ich habe nochmal für ASKSIN TimeStamp umgebaut.

Die Sendetimestamp von der Firmware bezieht sich nun auf den Start des Sendens der Präambel. (War bisher das Ende des Sendens)
Damit ist die Zeitaussage näher (fast gleich) an nextSend, wie es bei HMLAN verwendet wird (104ms ist das Optimierungsziel in 00_CUL.pm, ist durch 8 teilbar, wegen der Tick Auflösung).
Somit sollte es weniger problematisch sein, HMLAN und CUL in einem System Empfangen und Senden lassen zu können, das gemeinsam genutzte nextSend nun gleichen Wertebereich und (hoffentlich) auch gleiche Bedeutung hat.

Außerdem wird die Verzögerung nun für den Aa Befehl und Aw Befehl getrennt optimiert. Das macht Sinn wegen der unterschiedlichen Interface Anbindungen der verschiedenen CUL Varianten.
Diese Optimierung und Verwendung dieser Befehle setzt aber erst nach einigen Minuten ein, bis ein einigermaßen sinnvoller Scewfaktor für die beiden Uhrzeiten HOST-CUL ermittelt ist.

Das bedeutet auch, dass nicht nur die Firmware, sondern auch die .pm Dateien in FHEM ausgetauscht werden müssen (wie immer, erst Backup machen!)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Fritz R. am 21 April 2015, 21:30:24
@noansi :

Sorry, Antwort übersehen. Ja ich empfange Sensoren aber komischerweise nicht alle. Es sieht so aus, dass die mit V1.1 scheinbar nicht alle auftauchen.

Der Sensor der folgende Fehlermeldung liefert, ist auch ein alter. Hier scheint es probleme mit der Luftfeuchtigkeit zu geben, die Temperatur wird sauber empfangen.

CUL_WS_1 Error: temp/hum Cannot decode K01AA0A00 (sanitycheck). Malformed
Ein anderer Innensensor mit Luftdruck (WS2000ID) taucht leider überhaupt nicht auf.

Ich hatte Probleme, dass mein nanoCul immer nach 1-2 Tagen auf disconnected gewechselt hat und nur durch abstecken und neu einstecken wieder lief. Jetzt habe ich festgestellt, dass der Test-Pin des USB Chips nicht wie vorgesehen auf Masse gelegt war. Seit ich das geändert habe scheint das behoben zu sein.

Wie würdest Du herangehen, um die fehlenden Sensoren zu empfangen? Senden tun sie, das sehe ich an der originalen Anzeige.

Werde nachher mal Deine neue Version draufspielen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 April 2015, 23:06:56
Hallo Fritz und Testwillige,

erst mal eine Aktualisierung 00_CUL.pm, da mir für ASKSIN Timestamp noch ein Rundungsproblem störend aufgefallen ist. Das führte je nach Gangunterschid der Uhren CUL/HOST dazu, dass die Timing Optimierung nicht zum Ziel kommen konnte.


Zitat
Der Sensor der folgende Fehlermeldung liefert, ist auch ein alter

Zeigt der Sensor denn auch mal sinnvolle Werte?
Ist der nah dran oder weiter weg? Fals nicht probiert, dann ändere mal die Position, sprich erst mal in den gleichen Raum, wie CUL.

Zitat
Ein anderer Innensensor mit Luftdruck (WS2000ID) taucht leider überhaupt nicht auf.
Der kommt auf Code 8 rein, falls Du nicht die Adresse verstellt hast.
Richte den mal von Hand in der fhem.cfg ein. Automatische Erkennung und Einrichtung habe ich noch nicht getestet, respektive wegen anderem Müll, der reinkommt auch deaktiviert, um nicht laufend komische neue Sensoren wieder rauswerfen zu müssen.

Zitat
Wie würdest Du herangehen, um die fehlenden Sensoren zu empfangen? Senden tun sie, das sehe ich an der originalen Anzeige.
Richte auch die mal händisch in der fhem.cfg ein und schau was dann kommt.

Und erst mal mit guten Empfangsvorraussetzungen starten, also gleicher Raum, aber nicht direkt am CUL dran.
Dann wirst Du wohl die Empfangsparameter noch optimieren müssen, denke ich. Laufen sollte es auch noch mit V1.1 Protokoll, wenn ich es nicht irgendwie inzwischen vermukst haben sollte. Aber an dem Code war ich nicht mehr dran und in der board.h für nanoCUL ist es auch nicht abgeschaltet.

Wenn dass nicht hilft, müsstest Du mit verbose 4 bei dem nanoCUL die Rohdaten mal ins log schreiben. Dann können wir eventuell sehen, ob da noch was auf bit Ebnen schief geht.
Die 00_CUL.pm und 14_CUL_WS.pm von mir benutzt Du auch in aktueller Form?!?

Gruss, Ansgar.

EDIT1: Ich habe Firmware und 00_CUL.pm aktualisiert. Bei CUNO2 habe ich einen Fehler bei der Kommunikation über USB behoben. Das gleiche dürfte auch für CUNO gelten, auch wenn ich es nicht testen kann.
Ich habe die Ready Meldung nach Reboot für die seriell Varianten noch etwas abgewandelt und in 00_CUL.pm wird diese nun ausgewertet, so dass nach einem Watchdog Reset auch initialisiert wird.
Ausserdem ist die Optimierung des Aw Timings geändert.
Bei STACKABLE_CC funktionieren nun auch die Notifies, so dass sich auch bei diesen die Ints_per_Sec aufzeichnen lassen.

EDIT2: Für SlowRF habe ich eine Empfangs Timeout Reaktion ergänzt.

EDIT3: Bei ASKSIN habe ich den 360ms Burst auf 8ms abrundend umgestellt. Also 352-360ms
            Bei SlowRF ist der Sync Start verbessert und auch das BitTiming logging verbessert.
            CUN, CUNO und CCD habe ich mal angepasst, ist aber mangels Hardware noch gänzlich ungetestet.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Fritz R. am 22 April 2015, 22:08:17
Hallo,

vielen Dank für die Rückmeldung.
Ich habe jetzt die Version aus dem letzten Post drauf und die 3 Dateien in FHEM getauscht (hatte ich vorher auch gemacht)

Ich hab jeztz den Sensor der die Fehlermeldung liefert 0,5m vom nanoCul platziert. Komischerweise kamen die Temperaturwerte immer an, aber die Feuchtigkeitswerte lösten wohl die Fehlermeldung aus. Nur ganz am Anfang sehe ich im Log beide Werte, dann nur noch die Temperatur. Auch in STATE steht nur die Temperatur. Mal sehen wie es sich jetzt entwickelt.

Zitat
Richte auch die mal händisch in der fhem.cfg ein und schau was dann kommt.
Das war ein Top Hinweis, funktioniert, wird als WS7000 angezeigt, Werte sind plausibel. Automatische Einrichtung scheint hier nicht zu erfolgen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 23 April 2015, 22:12:57
Hallo Fritz,

Zitat
temp/hum Cannot decode K01AA0A00 (sanitycheck). Malformed
Zur Erläuterung, stören tut sich 14_CUL_WS.pm an den "A"s in der Message. Denn da dürfern nur dezimal Ziffern bei einem Temp/Hum Sensorkommen. Der Sensor hat die Adresse 0, also den Code 1 (sofern da nicht schon das Bit Drama seinen Lauf genommen hat.

Wenn Du noch schreiben kannst, was der Sensor eigentlich liefern sollte, z.B. ein zuvor/danach richtig empfangenes Wertepaar, könnte man eventuell daraus etwas ableiten, was bei dem Sensor an falschen Bits empfangen wird. Mehr Infos liefert aber das Rohdaten Log.

Was wird denn beim NanoCUL bei den Readings "Ints_per_sec" und "TO_Ints_per_sec" so angezeigt?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Mai 2015, 22:55:31
Hallo Fritz und Testwillige,

die Software in der letzten Nachricht http://forum.fhem.de/index.php/topic,24436.msg288122.html#msg288122 (http://forum.fhem.de/index.php/topic,24436.msg288122.html#msg288122) ist aktualisiert.

freq:868.300MHz bWidth:232kHz rAmpl:38dB sens:12dB drate:3.273kBit/s agcprio:0 agcwait:32 agchyst:2 dcBlockingoff:0
bzw.
freq:433.870MHz bWidth:232kHz rAmpl:38dB sens:12dB drate:3.273kBit/s agcprio:0 agcwait:32 agchyst:2 dcBlockingoff:0

scheint eine brauchbare Einstellung für die Wetterstationssensoren zu sein. Damit wird das Timing der empfangenen Signale besser aufgelöst.
Mit Verringerung der Bandbreite macht sich bei mir eine Absenkung der Frequenz um 50kHz (von der Sensorsendefrequenz) positiv bemerkbar. Die Sensoren streuen anscheinend, so dass eine stärkere Verringerung der Bandbreite wieder zu Empfangsverlust einzelner Sensoren führt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: phantom am 31 Mai 2015, 17:16:09
Hallo,

auch ich verwende einen CUL433 mit CUL_WS (modified) und diversen WS2000-Wettersensoren. Leider ist der Empfang verglichen mit der ELV-WS2000PC-Wetterstation recht unzuverlässig, da viele Telegramme der Sensoren nicht empfangen werden.

Könnte die Spezial-Firmware helfen, dieses Probleme in den Griff zu bekommen, oder sind es eher die CUL-Parameter bWidth, etc. ... ?

Zudem kommen immer mal wieder diese Meldungen im Log vor:
2015.05.30 01:46:50 5: CUL/RAW: /K001F
2015.05.30 01:46:50 4: CUL_Parse: CUL433 K001F -58.5
2015.05.30 01:46:50 2: CUL433: unknown message K00

Da komme ich als Newbie im Moment nicht weiter...

An den kommenden Feiertagen werde ich mal die Firmware CUL_V3_99_75_14 testen, evtl. kommt dann auch der alte Sensor mit V1.1-Protokoll an (dies ist nicht die K00-message).

DIRK
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juni 2015, 06:41:15
Hallo Dirk,

Zitat
oder sind es eher die CUL-Parameter bWidth, etc. ... ?
Ich würde sagen es beginnt mit der Antenne, geht über die Einstell-Parameter und setzt sich fort über die Firmware.  ;)

So habe ich mich jedenfalls vorgetastet.

Bei den Parametern wirst Du wohl mit der Standardfirmware mit sens = 8 (oder 12) gegenüber sens = 4 eine Verbesserung feststellen.
Ich habe noch Parameter ergänzt, weil noch mehr Parameter Einfluss auf den Empfang haben, was es aber auch nicht einfacher macht, gute zu finden.

Die Standardfirmware vesteht kein V1.1 Protokoll und beim V1.2 Protokoll hängt es an der Anzahl der Nibbles (gerade oder ungerade), ob Sie verstanden werden können oder nicht (oder es zufällig trotzdem passt).

Zitat
Zudem kommen immer mal wieder diese Meldungen im Log vor
Das ist mehr oder minder normal. Die Datentelegramme sind vom Protokoll her schon so schwach mit Checksumme abgesichert, dass Mehrfachbitfehler (oder verkrüppelte Telegramme) noch eine zu große Chance haben, um durchzukommen.
CUL und CUL_WS versuchen mit weiteren Prüfungen da noch was Unsinniges raus zu filtern.

Versuchs halt mal, aber sicher Dir vorher die Dateien, die Du austauschst.

Die zusätzliche Anzeige der Interrupts/s hat sich bei mir als Indikator für zu hohe rampl Werte gezeigt. Wenn die deutlich 3-Stellig oder 4-Stellig sind, dann ist rampl zu hoch (oder auch sens zu gering) und es wird auf viel Rauschen schon ein Empfangsversuch unternommen. rampl Schritt für Schritt senken (und mind. 2 Minuten warten, um den Effekt auch in den Interrupts zu sehen). Wenn die Interrupts gerade 2-Stellig oder niedrig 2-Stellig sind, dann passt dieser Parameter schon gut.

Die rampl=42 in der Standardfirmware scheinen die AGC Regelung nach oben hin zu begrenzen und dadurch etwas zu stabilisieren. Optimal ist es deswegen aber noch nicht zwingend.

Die Datenrate mit drate höher zu wählen, als die Bitrate des Senders, macht sich ebenfalls positiv bemerkbar. Die 1.5kbit der Standard Firmware scheinen noch zu niedrig zu sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 16 September 2015, 20:04:25
Wie geht es in dem Thema weiter? Ist es geplant, dass die Entwicklung in den Haupt-Zweig einfließen wird?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 16 September 2015, 20:23:18
Ich hab das z.Zt. nicht vor, da die Aenderungen gross sind. Vom culfw gibts mWn auch 2 weitere forks: a-culfw mit Unterstuetzung diverser 433MHz Protokolle, und eine ARM Variante.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: bjoernh am 16 September 2015, 21:01:56
Ich hab das z.Zt. nicht vor, da die Aenderungen gross sind. Vom culfw gibts mWn auch 2 weitere forks: a-culfw mit Unterstuetzung diverser 433MHz Protokolle, und eine ARM Variante.
Die ARM Variante ist inzwischen in der a-culfw enthalten. Es gibt also so wie ich es sehen nur diese zwei Varianten.
Wie geht es in dem Thema weiter? Ist es geplant, dass die Entwicklung in den Haupt-Zweig einfließen wird?
Wenn Du möchtest kannst Du oder jemand anderes gerne bei der a-culfw mithelfen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 30 September 2015, 23:27:36
Hallo Martin,

hier eine neue Version zum Testen des HM Updates, da sich in der letzten Version mit dem Umbau der RF-Modus Umschaltung ein Bug bei der FUP Umschaltung eingeschlichen hat, so das bei aktivem ASKSIN mit AR nicht auf die hohe Datenrate umgeschaltet wurde.
Erst mal nur das HEX File für CUL_V3 im zip. Für Source und Co. muss ich etwas weiter ausholen.

Gruß, Ansgar,

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Oktober 2015, 17:47:17
Hallo Martin und Testwillige,

anbei eine neue Version der Firmware und angepasster Module zum testen.

Da ich schon länger kein FHEM update mehr fahren kann, beruhen die Moduländerungen in FHEM module changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Datein machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft.

In der Firmware ist ASKSIN geringfügig geändert, dafür mehr in 00_CUL.pm, da ich das Messen des ScewFaktors Systemuhr zu CUL Uhr noch verbessert habe und der gemessene scF jetzt auch als Reading einen Neustart "überlebt".

Stacking ist optimiert. Daten, die zum nächsten aufgesteckten Stacking Modul weiter geschickt werden müssen, werden sofort beim Zeichen Empfang weiter geschickt, statt erst komplett empfangen zu werden, um dann erst weiter geschickt zu werden. Für HM hat das den Vorteil einer geringeren Sendeverzögerung bei weiter oben aufgestecktem Modul. Jedes Modul mehr sollte so in der Regel nur mit zwei Zeichen mehr Übertragungsverzögerung zu Buche schlagen.
Rückwärts geht das leider nicht, so dass beim Empfang weiterhin die Übertragungszeit von Modul zu Modul bis zum Raspi voll zu schlägt. Bei einer z.B. 32 Byte Nachricht sind das ca. 7,5ms pro Modul, also nicht zu vernachlässigen bezüglich sensiblem Timing.

Den 'e' Befehl habe ich besser abgesichert, damit nicht ein "einfalscherBefehl\r\n" die EEPROM Werte wieder zurück setzt, wie das bei der Timestamp Versionserkennung gelegentlich passiert ist, vermutlich wegen Pufferüberlauf.
Die Timestamp Versionserkennung habe ich auch überarbeitet, da der Löschversuch des Empfangspuffers nicht immer ausreichte. Gerade Empfangene Daten eines noch aktiven Empfangsmodus konnten da stören.

Da ich in der Firmware SlowRF auf 8us und damit auch den Timer1 auf 8us durchlaufend umgestellt habe, haben sich neue Wartefunktionen ergeben, die den Timerwert abfragen.

Mit X251 werden bei SlowRf nun auch Bit-Timing Daten mit Empfangsdaten übertragen, angehängt als _+HEX Werte. 00_CUL.pm nimmt das dann wieder auseinander. Zusammen mit dem WS, TX und KS300 Modul werden damit BitTiming Statistiken bei CUL und den Sensoren geführt (abschaltbar über Atrribut DontShowRawTiming = 1). Mit list CUL_NAME bzw. list Sensor_NAME kann man sich das dann ansehen, insbesondere Histogrammwerte für Bitlänge, Highzeit und Lowzeit.
Das ist interessant, wenn man an der Datenrate dreht, um den Empfang zu optimieren.

SlowRf läuft auf einem geänderten Match basiertem Algorithmus für den Ähnlichkeitsvergleich der Bits. Ich habe mit drate >1500, sens 12, agcwait 16 - 32, bessere Erfahrungen machen können, als mit den default Einstellungen.
Wenn die Interrupts/s hoch sind, weil vermutlich das Grundrauschen als Pegelwechsel interpretiert wird, scheint es ganz gut zu sein, AgcMaxDVGA zu erhöhen. Jeder Empfänger verhält sich da etwas anders. Das Reading Ints_per_sec zeigt es an.

Das Reading IntCalcStat zeigt die Rechenzeit der SlowRf Interrupt Routine in µs an. Die darf nicht länger, als das kürzest auszuwertende Bittiming sein und ist daher für die Programmierung interessant.

Ausserdem habe ich mit dem 'J' Befehl noch ein TX3 Senden eingebaut, z.B. "JA07E723720".

EDIT: Noch eine wesentliche Ergänzung. Bei CUL_V3 (USB Atmel) lässt sich nun eine USB-Seriennummer in der board.h konfigurieren. Damit kann man die CULs unter Linux unterscheiden. Mein Raspi hat die blöde Eigenschaft, die USB-Ports meines 10-fach USB-Hubs bei Warmstart in umgekehrter Reihenfolge zu erkennen, wie beim Kaltstart. Damit werden die beiden angeschlossenen CULs vertauscht. 433MHz und 868MHz sind nun mal sehr unterschiedlich, daher fällt das extrem störend auf. Ebenso, wenn man 2 gleiche Betreibt und deren Aufstellort empfangsoptimiert ist.
In der "99-usb-serial.rules" ist dann ein Beispiel, wie man das mit der Seriennummer für das immer gleiche Verlinken zu gleiche Portnamen nutzen kann. Die gehört nach /etc/udev/rules.d. Ein Blick da hinein offenbart die Portnamen, denen die jeweilgen CUL Seriennumern zugeordnet werden.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Dezember 2015, 15:40:08
Hallo Martin und Testwillige,

anbei eine neue Version der Firmware und angepasster Module zum testen.

Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM_module_changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

Insbesondere habe ich den SPI Zugriff etwas beschleunigt und eine kleine SPI-API gebaut. Das hat dann auch für CC1101 zu neuen internen Funktionen zur Programmierung der Register geführt.

Für die Netzwerk Varianten habe ich den Ethersex Treiber und UIP überarbeitet. Das hat noch etwas mehr Geschwindigkeit gebracht (deutlich verringerte Ping Zeiten) und vor allem Stabilität der Netzwerkverbindung, da ich dabei auch auf diverse Merkwürdigkeiten und Bugs gestoßen bin. CUNO2, CUNO und CUN sind auf Ethersex ein-/umgestellt.
Der ENC28J60 Treiber hat(te) auch zumindest einen Bug beim Phy Register Zugriff. Ist auch überarbeitet, jedoch völlig ungetestet.

Um dem Compiler weniger Chancen für Quatsch zu lassen (auch wenn der gcc schon ganz guten Code baut), habe ich insbesondere einige SPI Rountinen in Assembler Funktionen/Defines gebaut. Somit ist derzeit eine Begrenzung auf die AVR Mega Familie gegeben.

Die Tabelle mit Befehlen ist nach ttydata.c gewandert, wo sie sinngemäß hingehört, wie ich meine und wird über die board.h defines jeweils angepasst. So passiert eine Doppelbelegung mit gleichem Buchstaben ('E') nicht so leicht.
Damit SPI devices keinen Startblödsinn abbekommen, ist am Anfang von main.c eine Initialisierung aller SPI CS Signale eingebaut.

Getestet habe ich mit CUL V3, COC, SCC, CUNO2 (hex File in culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip enthalten) und meiner beigefügten Änderungen an alten FHEM CUL Modulen. Ohne die Moduländerungen geht es nicht. Es gilt das, was ich in vorherigen Beiträgen schon geschrieben habe.

EDIT: Um etwas Flash-Speicheplatz zu sparen, habe ich mal die Funktionsroutionen ein klein wenig angepasst. Bisher ist bei Kommandos immer der Zeiger auf das komplette Kommando an das Funktionmodul übergebn worden. Das ist aber ungünstig, weil erstens redundant (das Modul "weiss" ja, was es ist) und zweitens damit unötige Zeigeradditionen nötig werden, die nur zum Teil durch den ld Befehl des Prozessors abgefangen werden können. Das steckt in culfw-code-459-trunk_lufa_rf_cr_sd_75_63.zip neben weiteren kleinen Korrekturen drin.
Schade, dass in den Modulen nicht so eine schöne Systematik, wie bei den Hauptkommandos umgesetzt wurde. Sonst könnte man uint8_t callfn(char *buf) aus ttydata.c um einen Tabellenzeiger ergänzen und dann auch in den Modulen mit Sprungtabellen arbeiten. Das könnte noch weiteren Speicherplatz bringen, blöderweise aber auch eine Absage and die Kompatibilität zu bisherigen CUL Befehlen.
Ich kann mangels Hardware nicht alle Befehle testen. Daher ist es möglich, das es dabei mit dieser Version noch Problme bei der Kommandointerpretation gibt.
Die culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip arbeitet aber noch nach dem alten Strickmuster.
EDIT2: Immehin habe ich mit Funktionseinschränkungen CUL_V2, CUL_V2_HM und CUL_V2_MAX wieder bezüglich Speicher compilierbar bekommen, mangels Hardware natürlich ungestestet.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und ein frohes Fest, Ansgar.

PS: Ich habe noch ein paar Module anderer Art in das FHEM_module_changed.zip gepackt.

25_IPIO88_Telnet.pm  spricht ELV IPIO88 per Telnet an.
88_IPWE_Telnet.pm     spricht ELV IPWE 1 per Telnet an.
70_USBWX.pm              ist verbessert und spricht ELV USB-WX an.
98_IntervalTimer.pm     erlaubt die Einrichtung von Interval Timern. Nett zum Senden von Testpacketen an CUL.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 31 Dezember 2015, 13:22:50
Halo zusammen,

habe die Firmware auf Empfehlung von Martin wegen diesem Problem hier
http://forum.fhem.de/index.php/topic,43675.msg382258.html (http://forum.fhem.de/index.php/topic,43675.msg382258.html) installiert.
Kann man mit dieser Firmware kein IT-send mehr durchführen?

Folgendes findet sich nach dem IT-Schaltversuch im Log:

015.12.31 13:16:53 2: IT set Schalter_Teich_LED on
2015.12.31 13:16:58 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2015.12.31 13:16:58 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:16:58 3: Setting CUL_0 baudrate to 9600
2015.12.31 13:16:58 1: /dev/ttyACM0 reappeared (CUL_0)
2015.12.31 13:16:59 1: CUL_0 is VERSION_TS, V 99.75 CUL868, CUL_V3.4
2015.12.31 13:16:59 3: CUL_0: Possible commands: ABCEFGJKMRTUVWXYZbefilmtux
2015.12.31 13:16:59 2: IT set Schalter_Teich_LED on
2015.12.31 13:17:02 2: IT IODev device didn't answer is command correctly:   raw => AFF0100043AC9000C13867030E294000000006E4AFE
2015.12.31 13:17:05 2: IT set Schalter_Teich_LED off
2015.12.31 13:17:10 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2015.12.31 13:17:10 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:17:10 2: IT set Schalter_Teich_LED off
2015.12.31 13:17:10 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:17:11 3: Setting CUL_0 baudrate to 9600
2015.12.31 13:17:11 1: /dev/ttyACM0 reappeared (CUL_0)
2015.12.31 13:17:11 1: CUL_0 is VERSION_TS, V 99.75 CUL868, CUL_V3.4
2015.12.31 13:17:11 3: CUL_0: Possible commands: ABCEFGJKMRTUVWXYZbefilmtux

Darüber hinaus hatte ich noch folgende FM:

015.12.31 13:02:34 3: CUL_send:  CUL_0  id:311A51 dDly:80
2015.12.31 13:02:34 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:96
2015.12.31 13:10:46 3: CUL_send:  CUL_0  id:311A51 dDly:77
2015.12.31 13:10:46 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:104
2015.12.31 13:11:29 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2015.12.31 13:11:29 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!
2015.12.31 13:15:48 3: CUL_send:  CUL_0  id:311A51 dDly:85
2015.12.31 13:15:48 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:104

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 31 Dezember 2015, 21:35:25
Hallo Ambiman,

hast Du die Firmware aus culfw-code-459-trunk_lufa_rf_cr_sd_75_63.zip installiert?
Da ist mir bei der letzten Umstellung der Kommandointerpretation it_func leider durch die Lappen gegangen und daher wird damit IT sicher nicht gesendet. Das werde ich noch korrigieren.

Geht es mit der aus culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip?

Ich habe leider kein IT device um Testen zu können und bin daher auf möglichst aussagekräftiges Feedback dazu angewiesen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 Januar 2016, 01:08:55
Hallo Ambiman,

hier mal eine neue Version zum Testen, ob IT jetzt klappt. Für das Senden ist jetzt auch IT-V3 drin, aber noch nicht für den Empfang.

Ich habe noch ungetestete Änderungen bezüglich Netzwerk darin, also bei CUNO2 kann es noch zu Netzwerkproblemen kommen.

Gruß und frohes Neues,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 01 Januar 2016, 19:46:38
Hallo Ansgar,

besten Dank - Firmware geflashed on deine FHEM Module wieder installiert - das IT-Schalten funktioniert jetzt wie gewünscht :-).
Folgende FM erhalte ich jedoch noch im Log - woher kommen diese ?

016.01.01 19:45:00 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2016.01.01 19:45:00 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!
2016.01.01 19:45:04 2: IT set Schalter_Teich_LED off
2016.01.01 19:45:06 2: IT set Schalter_Teich_LED on
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 01 Januar 2016, 20:06:27
Zusatz:

Beim einem set on-for-timer 2 bei einem HM-LC-SW1-BA-PCB mit AES-Signatur erhalte ich folgende Meldung - das eigentliche Schalten funktioniert jedoch:

2016.01.01 20:04:12 3: CUL_HM set Alarmgeber_Piezo_Flur on-for-timer 2
2016.01.01 20:04:12 3: CUL_send:  CUL_0  id:3C9821 dDly:84
2016.01.01 20:04:13 2: CUL_ParseTsHM CUL_0 illegal message received: AFF2300024F8A001902A00327D0E23C98211c934e1906380d1dc2d65a9897a75e6780
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 01 Januar 2016, 20:59:57
Die anderen Meldungen tauchen scheinbar sporadisch auf:

2016.01.01 20:56:15 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2016.01.01 20:56:15 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 Januar 2016, 00:36:11
Hallo Ambiman,

prima, dass IT jetzt bei Dir funktioniert.  :) Den Empfang von IT-V3 muss ich noch einbauen, damit das komplett so tut, wie die normale Firmware.

Zu den Meldungen (da hilft ein Blick in den Code, wenn C geläufig ist):
 - ERR:ASKSINSFRX -> cc1101 Transiever Überlauf des Empfangspuffers in ASKSIN (HM Mode)
 - ERR:ASKSINIDLERX -> cc1101 Transiever in IDLE nach RX statt wieder RX, direkt nach vorheriger Meldung aber nur ein "Folgefehler"

Also erst mal nicht so schlimm, da offenbar Daten zu kurz aufeinander empfangen wurden und nicht rechtzeitig auf CUL vom cc1101 abgeholt werden konnten. Hängt auch an der Anzahl der Devices, die senden.

Zitat
2016.01.01 20:04:13 2: CUL_ParseTsHM CUL_0 illegal message received: AFF2300024F8A001902A00327D0E23C98211c934e1906380d1dc2d65a9897a75e6780
Hier ist was merkwürdiges passiert, da kleine Hex Ziffern in/an einer HM Nachricht kommen. Die kommen aber vermutlich nicht von CUL und nicht von meinem Code, so weit ich das sehe?!?

Bist Du schon bei FHEM 5.7 ? Dazu kann ich nicht sagen ob meine Modul Varianten Probleme bereiten können.
Bei AES war ich noch nicht. Und meine 00_CUL.pm Variante kennt das noch nicht. Von daher kann das mit AES zusammen hängen.

Benutzt Du CUL_V3 oder CUNO2?
Möglich wäre hier noch ein Puffer Problem (bei CUNO2 kann das u.U. passieren) so dass ein Teil einer Nachricht ankommt, dann etwas fehlt und wieder was anderes nicht vollständig kommt und daher auch der LF dazwischen fehlt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 04 Januar 2016, 19:07:58
Hallo Ansgar,


die illegal message Events tauchen nun häufiger auf - anbei ein kleiner Auszug aus dem Log:

AFF1301E9D122001932A00327D0E238F2A9e88df545d8493df70f1d7aa791ae219180
2016.01.04 19:03:59 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:03:59 3: CUL_send:  CUL_0  id:38F2A9 dDly:84
2016.01.04 19:03:59 3: CUL_ParseTsHM: CUL_0  id:38F2A9 dhmSt:104
2016.01.04 19:03:59 3: CUL_send:  CUL_0  id:38F2A9 dDly:79
2016.01.04 19:03:59 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D163001933A00327D0E238F2A9edb1b08e6fe0d8eb1dce2be5a40ec9de80
2016.01.04 19:03:59 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:01 3: CUL_send:  CUL_0  id:3CDBBB dDly:82
2016.01.04 19:04:01 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:01 3: CUL_send:  CUL_0  id:3CDBBB dDly:86
2016.01.04 19:04:01 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:85
2016.01.04 19:04:02 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D2A4001916A00327D0E23CDBBB9a8a9b5b6f590553fa4278c8c0b4afac80
2016.01.04 19:04:02 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:83
2016.01.04 19:04:02 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:79
2016.01.04 19:04:02 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D2E5001917A00327D0E23CDBBB2358c63e883dbc21447f792d11972f6380
2016.01.04 19:04:02 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:82
2016.01.04 19:04:02 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:03 3: CUL_send:  CUL_0  id:3CDBBB dDly:86
2016.01.04 19:04:03 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D327001918A00327D0E23CDBBBe90c45aabb468896bbe12a59aa40263f80
2016.01.04 19:04:03 3: CUL_0: Unknown code :CUL_0, help me!


Ja, ich nutze bereits FHEM 5.7 - anbei noch einige Infos zu meinen Versionen:


   TYPE       CUL
   VERSION    V 99.75 CUL868
   VERSION_HW CUL_V3.4


File             Rev   Last Change

fhem.pl          10298 2015-12-29 19:08:19Z rudolfkoenig 
00_CUL.pm         6526 2014-09-09 15:12:39Z thomyd
10_CUL_HM.pm     10265 2015-12-26 10:47:19Z martinp876

Ich vermute es hängt mit den AES-Signaturen von Homematic zusammen?

Viele Grüße,

ambiman
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2016, 21:01:27
Hallo Ambiman,

probier bitte mal die angehängte 00_CUL.pm

Damit verschwindet zumindest die "illegal message received" Fehlermeldung, weil die Kleinbuchstaben bei meinem Timestamp perl Code erlaubt werden.
Es sind alles Sendequittungen mit Sendetimestamp in Deinen Logs. Die kommen nach dem Senden mit Sendezeitstempel im Original wieder zurück von CUL.
Es werden wohl von AES Nachrichten mit Kleinbuchstaben im HEX Code an CUL gesendet, denke ich. Damit kommt CUL zurecht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ambiman am 07 Januar 2016, 12:56:35
Hallo Ansgar,

es gibt scheinbar noch ein Problem mit IT(v3):

Ich habe gestern ein paar Intertechno ITR-1500 im SET erworben und wollte dieses anlernen wie im Wiki (das bezieht sich jedoch auf ITv1) beschrieben, also IT-Code auswählen und dann in der Lernphase schalten - leider erfolglos :-(

Also habe ich mir die letzte Version der aculfw besorgt (a-culfw_1.20.01_build_176_master) und auf meinen CUL868 die CUL_V3_433MHZ Firmware geflashed (die 868er Version schaltet die Frequenz scheinbar nicht um) und anschließend den CUL statisch auf 433.92Mhz im RFMode SlowRF gesetzt und autocreate aktiviert. Den Knopf an der Original Intertechno-Fernbedienung gedrückt und schon war das IT-Device  (als ITv3) in FHEM zu sehen.

Nun da ich die IT-Definition hatte dachte ich, dass ich deine Firmware wieder verwenden kann um die Dose zu schalten - leider hat dies nicht funktioniert :-(

Anbei einige Logs mit beiden Firmwares:

Deine Firmware:


2016.01.07 12:11:20 2: IT set WZ_Stehlampe on
2016.01.07 12:11:20 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:11:22 2: IT set WZ_Stehlampe off
2016.01.07 12:11:22 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000
2016.01.07 12:11:24 2: IT set WZ_Stehlampe on
2016.01.07 12:11:24 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:11:26 2: IT set WZ_Stehlampe off
2016.01.07 12:11:26 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000


A-CULFW:


2016.01.07 12:16:22 2: IT set WZ_Stehlampe off
2016.01.07 12:16:22 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000
2016.01.07 12:16:23 2: IT set WZ_Stehlampe on
2016.01.07 12:16:23 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:16:24 2: IT set WZ_Stehlampe off
2016.01.07 12:16:24 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000


Im Moment nutze ich somit die aculfw in der 433er Variante, da damit scheinbar ITv1/v3 und Homematic funktioniert - zumindest bisher.

Wäre klasse, wenn deine Firmware das ebenfalls unterstützen würde, da du - wenn ich es richtig verstanden habe - einige Verbesserungen bzgl. Timing und HM implementiert hast.

Wie oft kann man den CUL eigentlich flashen, bis der EEPROM kaputt ist ?

Viele Grüße,

ambiman
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 Januar 2016, 22:34:02
Hallo Ambiman,

blöd, wenn man keine Hardware zum selber Testen hat.  :(

Danke für den Log Auszug. Das hat mich einem Problem näher gebracht. IT_V3 ist wohl an 32 Tri-State Bits zu erkennen und nicht an 31, wie ich dem aktuellen CUL FW Code anhand eines falschen Kommentares glaubte entnehmen zu können.
Deswegen wurde sicherlich mit falschem Timing (aber richtiger Frequenz) gesendet.

Da ich nun einen Blick in den A-CULFW code genommen habe, muss ich die IT_V3 Unterschiede auch mal durchgehen, um das entsprechend umzusetzen, was bei Dir sendetechnisch funktioniert. Das dauert noch etwas.

Zitat
Wie oft kann man den CUL eigentlich flashen, bis der EEPROM kaputt ist ?
10000 Lösch-/Schreibzyklen gibt Atmel im Datenblatt an.

Zitat
einige Verbesserungen bzgl. Timing und HM
Für HM habe ich die Möglichkeit 8ms genauen Sendetimings eingebaut. Und auf FHEM Seite das Ausmessen der IO-Timings, um das Antwortiming zu verbessern. Das klappt auch gut, sofern FHEM nicht zu lange "rumbummelt" und die Sendebefehle rechtzeitig raus schickt (und man keinen HM-Repeater verwendet. Das ist Baustelle, sofern lösbar).

Aber die Änderungen an der Firmware gehen mittlerweile noch wesentlich weiter. SlowRF Empfang ist umgeschrieben. USB-, Seriell-, Stacking- und Netzwerk Kommunikation sind umgeschrieben und stabilisiert.
Die CC1101 Transceiver Programmierung ist umgeschrieben und korrigiert bei Problemen mit der Frequenzsynthesizer Kalibrierung. Usw.
Mein Ziel ist, das was läuft (insbesondere mit meiner verfügbaren Hardware) auch wirklich zuverlässig funktionierend umzusetzen und dann andere Protokolle zu ergänzen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Januar 2016, 19:59:59
Hallo Ambiman,

angehängt eine neue Version zum Testen.

Ich hoffe, Intertechno_V3 Senden klappt nun auch. Home Easy habe ich auch mit in die Firmware eingebaut, so wie ich es in der A-Firmware vom Timing her gesehen habe, als ich dort nach IT_V3 geschaut habe. Ich hoffe beides klappt, da ich die mangels Hardware nicht testen kann.
Für Intertechno_V1 habe ich noch Funkschalter als Testopbjekte ausgraben können. Die funktionieren.

Wegen Flashspeicher Knappheit ist jedoch RF Mbus bei CUl_V3 nicht enhalten. Kann jedcoh mit Änderung der board.h unter Verzicht auf anderes umkonfiguriert und neu compiliert werden. Ich hoffe, ich finde noch ein paar Bytes, um das wieder rein zu bekommen.

Außerdem habe ich den ASKSIN Task überarbeitet und denke, damit noch weniger Empfangspakete zu verlieren.
Dabei nutze ich auch einen ungenutzten Eingang/Ausgang als schnelles Speicherflag. Daher muss gegen Schaltplan und/oder Hardware geprüft werden, ob der auch wirklich ungenutzt ist. Für CUL, COC, SCC und CUNO2 kann ich das mit Plänen von der Busware Seite und verfügbarer Hardware, nicht jedoch für andere Hardware.

Bei CUL_V3.hex ist rf_mbus wegen Flash-Speichermangel nicht enthalten. Ich hoffe, mir fallen noch genügend Speicheroptimierungen auf, um das wieder ändern zu können. Natürlich besteht die Möglichkeit des neu Compilierens mit geänderter Protokoll-Zusammensetzung.

Für die Paketversandprotokolle wie auch RF-Router habe in rf_credits.c eine credits Brechnungsfunktion mit Subcredits ergänzt. Als Ansatz für eine Creditsberechnungsvereinheitlichung (und auf der Suche nach verschwendetem Flash Speicher).

In 00_CUL.pm werden nun auch die eingebauten ASKSIN Fehlermeldungen abgefangen und bei verbose=2 ausgegeben.

Für den SPI Zugriff habe ich einige Assembler Routinen zum Buffer Lesen/Schreiben des CC1101 und auch des ENC28J60 ergänzt. Diese berücksichtigen das Timing beim SPI-Zugriff um etwas schnelleren Zugriff zu ermöglichen. Beim Ping zu CONO2 hat sich damit eine deutliche Verbesserung in der Antwortzeit ergeben. Ethernet bei CUNO2 läuft bei mir nun auch stabil.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM_module_changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

PS2: WICHTIG! Bei RF-Router scheint in der Firmware oder in CUL/STACKABLE noch was schief zu laufen. Ein Versuch mit RF-Router hat bei mir zu einem fast hängenden FHEM und neu startendem SCC geführt. Also bitte den nicht testen.
Nur durch ein Abschalten von RF-Router in 00_CUL.pm DoInit habe ich beiden CULs wieder zu normaler Reaktion bewegen können.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 24 Januar 2016, 22:18:44
Hallo Testwillige,

angehängt eine neue Version zum Testen.

Bei der letzten Version hat sich in der Firmware ein Fehler eingeschlichen, der bei RF-Router und FastRF zu einer Endlosschleife geführt hat, was wiederum watchdog Neustarts von CUL bewirkte. Das ist behoben. Richtig testen konnte ich beide jedoch nicht. Aber FHEM wird nicht mehr dadurch blockiert.
Au0erdem hatte ich modifizierte DevIo.pm nicht beigepackt.

Ich hoffe, Intertechno_V3 Senden klappt nun auch. Home Easy habe ich auch mit in die Firmware eingebaut, so wie ich es in der A-Firmware vom Timing her gesehen habe, als ich dort nach IT_V3 geschaut habe. Ich hoffe beides klappt, da ich die mangels Hardware nicht testen kann.
Für Intertechno_V1 habe ich noch Funkschalter als Testobjekte ausgraben können. Die funktionieren.

Wegen Flashspeicher Knappheit ist jedoch RF Mbus bei CUl_V3 nicht enhalten. Kann jedcoh mit Änderung der board.h unter Verzicht auf anderes umkonfiguriert und neu compiliert werden. Ich hoffe, ich finde noch ein paar Bytes, um das wieder rein zu bekommen.

Außerdem habe ich den ASKSIN Task überarbeitet und denke, damit noch weniger Empfangspakete zu verlieren.
Dabei nutze ich auch einen ungenutzten Eingang/Ausgang als schnelles Speicherflag. Daher muss gegen Schaltplan und/oder Hardware geprüft werden, ob der auch wirklich ungenutzt ist. Für CUL, COC, SCC und CUNO2 kann ich das mit Plänen von der Busware Seite und verfügbarer Hardware, nicht jedoch für andere Hardware.

Bei CUL_V3.hex ist rf_mbus wegen Flash-Speichermangel nicht enthalten. Ich hoffe, mir fallen noch genügend Speicheroptimierungen auf, um das wieder ändern zu können. Natürlich besteht die Möglichkeit des neu Compilierens mit geänderter Protokoll-Zusammensetzung.

Für die Paketversandprotokolle wie auch RF-Router habe in rf_credits.c eine credits Brechnungsfunktion mit Subcredits ergänzt. Als Ansatz für eine Creditsberechnungsvereinheitlichung (und auf der Suche nach verschwendetem Flash Speicher).

In 00_CUL.pm werden nun auch die eingebauten ASKSIN Fehlermeldungen abgefangen und bei verbose=2 ausgegeben.

Für den SPI Zugriff habe ich einige Assembler Routinen zum Buffer Lesen/Schreiben des CC1101 und auch des ENC28J60 ergänzt. Diese berücksichtigen das Timing beim SPI-Zugriff um etwas schnelleren Zugriff zu ermöglichen. Beim Ping zu CONO2 hat sich damit eine deutliche Verbesserung in der Antwortzeit ergeben. Ethernet bei CUNO2 läuft bei mir nun auch stabil.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM Modulen auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden! Mit FHEM 5.7 kann ich gar nicht testen, ob es zu Problemen kommt.
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 Februar 2016, 23:32:16
Hallo Testwilige,

angehängt eine Aktualisierung von 00_CUL.pm für meine Testversion. Sie filtert Messages von HM-Repeater aus, um das Verzögerungstiming nicht zu stören.
HM-Repeater wird somit erst mal nicht unterstützt. Knackpunkt ist die Repeater Verzögerung, die ein sehr knappes Verzögerungstiming zu erfordern scheint.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM Modulen auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden! Mit FHEM 5.7 kann ich gar nicht testen, ob es zu Problemen kommt.
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: linuzer am 01 März 2016, 10:26:14
Hallo Ansgar und alle anderen fleißigen Entwickler hier,

ich bin in einem anderen thread (http://forum.fhem.de/index.php/topic,50044.msg417887.html#msg417887) darauf  hingewiesen worden, diese culfw mit den Timinganpassungen zu probieren, um meine pairing-Probleme zu lösen. Das würde ich auch gerne ausprobieren, bin aber etwas verwirrt, von wo ich jetzt alle relevanten Dateien zusammen bekomme und wie genau ich die Firmware flashen muss.
Ich habe die Anweisungen in diesem (http://forum.fhem.de/index.php/topic,31421.msg239101.html#msg239101) Thread befolgt, was aber leider nicht geklappt hat. Ausserdem kenne ich diesen (CUL_am_Raspberry_Pi_flashen (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen)) Wiki-Artikel, mit dem ich bereits die a-culfw von sourceforge (https://sourceforge.net/p/culfw/code/HEAD/tree/) installiert habe.

Wie muss ich jetzt vorgehen, um diese Timing-Firmware zu installieren?
Sorry, wenn die Frage sehr newbie-haft klingt, aber ich würde mich sehr über einen Tipp freuen!

Edit:
Ich glaube, ich habe es jetzt selbst geschafft, mein CUL zeigt mir das Reading:
VERSION    V 99.78 CUL868Ist es das, was er zeigen sollte?
Die anderen Dateien habe ich im FHEM-Verzeichnis ersetzt... Aber sehe ich das richtig, dass die bei einem Fhem-Update wieder überschrieben werden?

Viele Grüße,
linuzer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 März 2016, 19:58:07
Hallo Linuzer,

Zitat
Ich glaube, ich habe es jetzt selbst geschafft,
ja, hast Du.  :)

Zitat
Aber sehe ich das richtig, dass die bei einem Fhem-Update wieder überschrieben werden?
Das siehst Du richtig, leider.

Daher musst Du das mit dem Kopieren nach jedem FHEM-Update wiederholen und es kann natürlich auch passieren, das meine *,pm Varianten mit der jeweils aktuellen FHEM Version nicht mehr harmonieren.
Update habe ich schon lange nicht mehr benutzt, da ich solche Überraschungen nicht gebrauchen kann.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Mr. P am 02 März 2016, 13:26:12
Das siehst Du richtig, leider.
Naja... seht euch doch mal in der commandref das Attribut: exclude_from_update an. Ich glaube, das könnte euch gefallen. ;-)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 März 2016, 21:17:32
Hallo Mr. P,

danke für den Hinweis! Die Funktionsvielfalt von FHEM ist doch immer wieder überwältigend.  :)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Mr. P am 08 März 2016, 08:52:02
Hej Ansgar,

bin ebenfalls immer wieder überrascht. :-)
Titel: Anpassung für MaxCube?Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Hans5546 am 06 April 2016, 18:02:24
Hallo Fritz und Testwillige,

ich habe mal aus dem TRUNK 499 nanoCUL genommen und angepasst, so dass es mit meinen Änderungen compilierbar ist. Mangels Hardware ...

Gruß, Ansgar.

Hallo Ansgar!

Ich habe die oben genannte Firmware CUL_V3_99_75_3 auf meinen NanoCul mit 433 Mhz-Modul geflasht. Sie läuft auch prima und empfängt in meiner CCU2 mit CuxD auf die WS2000-Sensoren mir Protokoll 1.1 :-)

Nun habe ich das Problem, dass ich an einem entfernteren Standort ein Max-Cube mit a-culw werkelt. Dort habe ich ebenfalls ein 433 Mhz-Modul eingelötet und ihn auf 433 Mhz konfiguriert - er läuft, aber empfängt nur WS2000-Sensoren mit Protokoll 1.2

Ich würde nun gerne Deine angepasste asksin.c in die a-culw integrieren (wäre das die einzig nötige Änderung?), um auch dort die alten Sensoren zu empfangen. Wie zu erwarten war, funktioniert das aber nicht so einfach... Und der Quelltext ist doch einfach zu komplex, um ihn zu überschauen.
Hast Du eine Idee, wie ich das dort integrieren kann? Kompilieren der ARM-Firmware läuft problemlos (nach ewigem Ausprobieren...)

Vielen Dank!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 April 2016, 19:50:54
Hallo Hans,

bezüglich

Zitat
WS2000-Sensoren mit Protokoll 1.1

bist Du mit asksin.c an der falschen Baustelle. asksin.c betrifft nur Timestamp für HM.

WS2000 Sensorempfang steckt in rf_receive.c. Und dort suchst Du nach HAS_NO_WS2000_V1_1_SUPPORT, um die Ergänzungen bezüglich 1.1 Protokoll zu finden. Problem war die "unvollständige" Checksumme im Vergleich zu 1.2. Das musst Du sinngemäß in die a-culfw ergänzen.

Im Prinzip würde es zur Vereinfachung auch reichen, statt der Checksumme z.B. eine 0 zu ergänzen, da  14_CUL_WS.pm die Checksumme nicht prüft, aber auf die korrekte Zahl der Nibbles prüft.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Hans5546 am 08 April 2016, 14:27:50
Hallo Ansgar,

einfach den entsprechenden Bereich reinkopieren klappt (natürlich) nicht... und entsprechend umschreiben, damit es zum Rest der rf_receive.c vom a-culw passt, kann ich leider nicht :-(

Ich nehme nicht an, dass Du dafür Zeit und Lust hast, oder? Im Gegenzug könnte ich nur anbieten, die Firmware dann für den Max Cube zu kompilieren und zum Download zur Verfügung zu stellen... Wobei der Anwendungsfall "433 Mhz Cuno aus Max Cube" mit "WS2000 Protokoll 1.1" schon recht exotisch sein dürfte ;-)

EDIT um 20:57: Hallo nochmal,
meine Alternative, an der ich gerade am Basteln bin, ist ein per ser2net angebundener nanoCUL an einem WRT54GL-Router mit DD-WRT drauf.
Im CuxD (würde ebenso in FHEM gehen, da definiert wie ein CUNO) wird der Cul auch schon erkannt und er reagiert auf Terminal-Befehle, ich habe allerdings noch kein Funkmodul angeschlossen, das mache ich gleich mal.
Ist zwar wesentlich größer als ein MaxCube @ 433Mhz aber mittels des WRT54GLs könnte ich den nanoCUL sogar per WLAN ins Netzwerk einbinden ;-)

EDIT 2: Der WRT54GL hat übrigens zwei serielle Schnittstellen. Man könnte also parallel auch noch einen 868Mhz Cul anschließen oder dergleichen.

EDIT 3: So, mein "Selbstbau CUNO" mit Deiner auf einen nanoCUL geflashten Firmware läuft und empfängt fleißig 433 Mhz Signale - und das im Netzwerk mit einem per WLAN angebundenen WRT54GL :-) Super, der wird morgen in Betrieb genommen und ich kann hoffentlich alle "alten" Sensoren empfangen :-)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 April 2016, 18:52:54
Hallo Hans,

Zitat
einfach den entsprechenden Bereich reinkopieren klappt (natürlich) nicht... und entsprechend umschreiben, damit es zum Rest der rf_receive.c vom a-culw passt, kann ich leider nicht :-(
Das war das mit dem "sinngemäß". Ich hatte da noch einiges mehr geändert. U.A. erinnere mich auch noch an die Anzahl der Nibbles, die sich je nach Sensortyp (nicht Protokollversion) unterscheidet. Das muss auch angepasst werden. Die Checksummenberechnung hatte ich auch angepackt. Das ist leider mehr als ein bischen Arbeit an der A-CULFW, zumal man jeweils intensiv über die Funktion grübeln muss, da die Kommentare im Quelltext schwach sind.

Aber wie ich sehe, arbeitest Du an einer schneller umzusetzenden Alternativlösung. :-)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Pythonf am 18 April 2016, 14:11:13
Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?

Grüße
Fabian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 April 2016, 21:52:33
Hallo Fabian,


Zitat
Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?
Wie schon angedeutet, mit Hirnschmalz und einiger Zeit (die ich derzeit leider nicht habe) sicherlich.

Ich sehe die Frage allerdings ohnehin eher im a-culfw thread.

Der Quellcode steht ja für beide Varianten zur Verfügung, um sich Anregungen dafür zu holen.
Timestamp ist für HM und damit für viele interessant.
1.1 Protokoll Support für alte ELV Wetterstationssensoren für weniger User, ebenso wie Wind, Helligkeit und Regen für alte WS2000 Wetterstationen in 1.1 oder 1.2 Protokoll. Der Kunststoff hält leider nicht ewig an der Sonne.


Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: bjoernh am 18 April 2016, 21:58:25
Hallo Fabian,

Wie schon angedeutet, mit Hirnschmalz und einiger Zeit (die ich derzeit leider nicht habe) sicherlich.

Ich sehe die Frage allerdings ohnehin eher im a-culfw thread.

Der Quellcode steht ja für beide Varianten zur Verfügung, um sich Anregungen dafür zu holen.
Timestamp ist für HM und damit für viele interessant.
1.1 Protokoll Support für alte ELV Wetterstationssensoren für weniger User, ebenso wie Wind, Helligkeit und Regen für alte WS2000 Wetterstationen in 1.1 oder 1.2 Protokoll. Der Kunststoff hält leider nicht ewig an der Sonne.


Gruß, Ansgar.
Hi, 
ich kann euch auch gerne Zugriff auf das Repository geben,  dann könnt ihr es einbauen. Gerne unterstütze ich euch auch dabei.  Momentan habe ich leider nicht viel Zeit um mich darum zu kümmern.
Wie gesagt,  wenn Interesse besteht,  dann bitte kurz melden.
Gruß Björn
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Pythonf am 20 April 2016, 16:10:37
Welches ist nun eigentlich die aktuelle Version? Die aus Post #116/117 oder aus diesem Thread https://forum.fhem.de/index.php/topic,31421.msg239101.html#msg239101 (https://forum.fhem.de/index.php/topic,31421.msg239101.html#msg239101)? Und da die 00_CUL.pm abgeändert wird gibt es irgendwelche Nachteile bzw. in wie weit werden aktuelle Updates mit einbezogen?

#EDIT
Und wie muss ich vorgehen, wenn ich einen nanoCUL flashen will?
Hab einen Fehler, wenn ich versuche die FW zu kompilieren:
makefile:338: recipe for target '../../clib/rf_asksin.o' failed
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 April 2016, 22:57:46
Hallo Pythonf,

Zitat
Welches ist nun eigentlich die aktuelle Version? Die aus Post #116/117
Du hast die neueste von mir veröffentlichte Version gefunden.

Zitat
Und da die 00_CUL.pm abgeändert wird gibt es irgendwelche Nachteile bzw. in wie weit werden aktuelle Updates mit einbezogen?
Wie dort im Post steht, ich arbeite auf dem älteren FHEM Stand und kann es daher nicht testen, ob Nebenwirkungen mit dem aktuellen FHEM Stand auftreten.
Also mit Backup der Dateien arbeiten, um ggf. den Rückweg zu erleichtern oder auftretende Probleme im perl Code aufspüren und beheben. (Und bitte hier mitteilen.  :) )

Zitat
Und wie muss ich vorgehen, wenn ich einen nanoCUL flashen will?
Ich kann nur CUL, SCC, COC und CUNO2 testen, respektive die Hardware anschauen.

Bei nanoCUL musst Du einen Blick in die board.h werfen und nach

Zitat
#define SPI_CC1101_READ_SPECIAL_PORT  PORTB
#define SPI_CC1101_READ_SPECIAL_DDR   DDRB
// #define SPI_CC1101_READ_SPECIAL_PIN   6     // we missuse this unused (has to be checked!) pin as fast signaling bit for special cc1101_read_buf

schauen. (Der Compilerfehler vor der von Dir dargestellten Fehlerausgabe gibt den Hinweis).

Du musst also auf Deine nanoCul Hardware schauen und dort einen freien Pin auf PortB (vgl. die vorherigen beiden Zeilen) des Atmels finden. Dann kannst Du den Kommentar aus obiger Zeile entfernen und die entsprechende I/O Pin (Bit) Nummer statt der 6 eintragen. Ich habe die Hardware nicht und kann das daher nicht machen.
Sollte es mit PortB nicht gehen, weil voll genutzt, kannst Du auch einen anderen Port nehmen und in der board.h entsprechend anpassen (Port+DDR) und dessen freien Pin eintragen.

Diesen ungenutzen Pin benutze ich im Code dann als schnelles, speichersparendes Flag (dank der Atmel Bitmanipulationsbefehle für den unteren I/O Bereich). Speicher ist je nach Atmel knapp und Flashspeicher je nach Hardware leider auch, deswegen + Geschwindigkeitsvorteil bin ich auf diese für Dich leider unbequeme Idee gekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 15 Mai 2016, 00:33:57
Hallo,

vielleicht/hoffentlich bin ich hier richtig...

Habe mich schon ein wenig durch's Forum gewühlt.

Habe mitbekommen, dass es wohl (ab und an bzw. mit gewissen HM-Komponenten) Timingprobleme mit CUL gibt.

Habe bereits hier:

https://forum.fhem.de/index.php/topic,53367.0.html (https://forum.fhem.de/index.php/topic,53367.0.html)

und hier versucht eine Antwort/Lösung zu bekommen:

https://forum.fhem.de/index.php/topic,30275.msg447944.html#msg447944 (https://forum.fhem.de/index.php/topic,30275.msg447944.html#msg447944)

Habe mir dann diesen Thread durchgelesen und mir folgendes mal runtergeladen:

https://forum.fhem.de/index.php/topic,24436.msg397787.html#msg397787 (https://forum.fhem.de/index.php/topic,24436.msg397787.html#msg397787)

"culfw-code-459-trunk_lufa_rf_cr_sd_78_2.zip "

Habe einen NanoCUL868 Einsatz soll Homematic sein.

Wenn ich diesen dann baue und flashe habe ich dann eine cul-fw mit Timingkorrekturen für HM, die dann mit 00_CUL.pm zusammenarbeitet??

Vielen Dank!!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Mai 2016, 18:50:53
Hallo Joachim,

Zitat
Wenn ich diesen dann baue und flashe habe ich dann eine cul-fw mit Timingkorrekturen für HM, die dann mit 00_CUL.pm zusammenarbeitet??

Lies bitte auch mal mehr in diesem Thread. Dann siehst Du z.B., dass Du ein Update im folgenden Beitrag übersehen hast.

Bei NanoCUL muss Dir noch klar sein, welchen Atmel Prozessor Du hast und an welchen Pins was angelötet ist.
Dann kannst Du die Firmware entsprechend konfigurieren (board.h, makefile, nanoCUL.c), compilieren und dann flashen.
Ich fürchte, da musst Du noch was lesen und experimentieren, um zum Ziel zu kommen. Macht aber auch Spaß.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 16 Mai 2016, 19:58:27
Hallo Ansgar,

vielen Dank für die Antwort...

Hab noch mal ab meiner Verlinkung geschaut aber konnte keine neuere Version (als culfw-code-459-trunk_lufa_rf_cr_sd_78_2.zip) entdecken...

Bin wohl zu doof...

Nur eine neuere Version von 00_CUL.pm

Hab noch mal ein wenig gelesen und es wird erwähnt, dass askin.c nur HM betrifft.

Andersrum gefragt: wenn ich die neueste von dir (glaube ich waren die Anpassungen!?) asksin.c in die runtergeladenen Sourcen (neueste Version der "standard cul-fw") austausche habe ich dann alles was ich für Homematic timing brauche?

Also die aktuell laufende Version habe ich selbst gebaut und geflasht.
Läuft soweit auch prima.
Nur mit manchen Komponenten (optische Fenstersensoren und der Klingelsensor) gibt es Probleme die (so wie ich es gefunden hab) wohl mit dem Timing zu tun haben...

Entschuldige, wenn ich (wahrscheinlich wirklich) dumm frage und es nicht finden kann...
Aber ich habe mittlerweile so viel in so vielen Threads darüber gelesen aber irgendwie hab ich nicht herausfinden können was/wo nun die aktuellste Version für die HM-Timing Problematik zu finden ist...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Mai 2016, 21:08:14
Hallo Joachim,

Zitat
Nur eine neuere Version von 00_CUL.pm

Die meinte ich. Und wenn Du auch noch die benutzt, dann hast Du den letzten Stand gefunden.

Zitat
Andersrum gefragt: wenn ich die neueste von dir (glaube ich waren die Anpassungen!?) asksin.c in die runtergeladenen Sourcen (neueste Version der "standard cul-fw") austausche habe ich dann alles was ich für Homematic timing brauche?

Die asksin.c alleine reicht nicht, da ich sehr viel mehr in der Firmware geändert habe und es mit dem einfachen Austausch der Datei nicht getan ist.
Wenn Du aber nur HM machen willst, warum willst Du dann die Standard Firmware umbauen? Ich sehe da keinen Vorteil.
Schau nur, dass Du meine Variante mit Deinem nanoCul ans laufen bekommst. Und da nanoCUL nicht zwingend gleich nanoCUL ist, bleibt Dir die Überprüfung und ggf. Anpassung der genannten Dateien nicht erspart.
(Oder es findet sich jemand, der das mit gleicher Hardware und Pinbelegung schon gemacht hat.)

Also ist die erste Frage, was hängt an welchem Pin?
Und die zweite, welchen Prozessor hast Du auf deinem nanoCUL und mit welcher Taktfrequenz läuft der?
(Taktfrquenz ist wichtig um den CPU-Takt Vorteiler so einzustellen, dass ein effektiver Takt von 8MHz raus kommt, sonst geht das Timing trotzdem in die Hose)

Und/Oder Du vergleichst (mindestens) die genannten Dateien aus den Sourcen von der bei Dir schon laufenden Version mit denen aus meiner Variante bezüglich der Pin Nutzung und CPU Takt und passt entsprechend an, was anders ist.
Dann compilieren und flashen.

Zu der Frage "Wie passe ich CUL Firmware Sourcen an meinen nanoCUL an?" wäre es dann sinnvoller einen separaten Thread zu öffnen und die Fragen da zu diskutieren.

Außerdem musst Du die *.pm Dateien im FHEM Verzeicnnis ausstauschen. Das steht im Thread. Inklusive meiner dringenden Hinweise, vorher die Dateien zu sichern, falls FHEM Neuerungen zu Nebenwirkungen führen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 16 Mai 2016, 22:21:45
Hi Ansgar,

vielen Dank!

Dann passt alles.

Also die genannte cul-fw hier im Thread compilieren (gut prüfen und anpassen eh klar) und dann die letzte zu findende 00_CUL.pm.

Das wollte ich wissen.

Hab mich nur wund gesucht und wusste nie, ob ich nun wirklich die aktuellste spezielle cul-fw habe...
...oder ob es irgendwo (sourceforge, github, ...) bereits eine neuere gibt...

Gruß, Joachim

P.S.: pinbelegung etc. ist wie bei "cul-fw" beschrieben, nach der Anleitung habe ich den nanoCUL gebastelt und er läuft ja prinzipiell...
MC ist ein ATMEGA328 auf einem Arduino Nano allerdings mit 16MHz wobei sich das ja per fuse einstellen lässt, dann allerdings nur mit dem internen Takt. Ist der genau genug?? Bzw. kann ich das doch ebenso in der board.h einstellen!?
Ich denke das kriege ich hin...
Wenn nicht: neuer Thread! Danke...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Mai 2016, 00:35:06
Hallo Joachim,

Zitat
MC ist ein ATMEGA328
Im Makefile ist atmega328p oben eingetragen. Wenn ohne p, dann pass es an.
F_CPU = 8000000 belassen, ist relevant für die Baudratenberechnung.

Zitat
16MHz
Das ist ok.
In board.h ist das schon passend definiert, so dass in nanoCUL.c der Prescaler auf Halbierung eingestellt wird -> wunderbare 8MHz.

Zitat
pinbelegung etc. ist wie bei "cul-fw"
Beim schnellen Überfliegen sieht das dann wohl gut aus.
Nur den Kommentar bei
// #define SPI_CC1101_READ_SPECIAL_PIN   6     // we missuse this unused (has to be checked!) pin as fast signaling bit for special cc1101_read_bufmusst Du in board.h entfernen, um die Zeile zu aktivieren und
#define MULTI_FREQ_DEVICE darin auskommentieren, da Du ja vermutlich/hoffentlich ein 868MHz cc1101 Modul hast.

Dann noch alle 433MHz Protokolle, z.B.
#define HAS_TX3_SEND                  // #define HAS_INTERTECHNO#define HAS_IT       // define to enable IT support...
nach Bedarf auskommentieren.

Viel Erfolg,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 17 Mai 2016, 01:47:54
Hallo Ansgar,

vielen Dank für die Hinweise!!

Dann kann ich ja loslegen...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 17 Mai 2016, 18:33:13
Hallo,

also bauen und flashen war (fast) unproblematisch.

Allerdings scheint der 'HM-Sen-Db-Pcb' (Klingelsensor) eine hartnäckige Nuss zu sein.

Habe schon einiges hier gelesen und immer wieder wurde das Timing als Ursache genannt...
...drum habe ich mich auf die Suche nach dieser speziellen cul-fw gemacht.

Aber leider immer noch: ich bekomme die Nachrichten (also dass "gedrückt" wurde), allerdings bleibt 'R-pairCentral' auf 'set_0xAFFE02' stehen...

Werde mal testen, ob der Klingelsensor an einem HM-CFG-USB-2 auch so zickt...
Bei den (optischen) Fenstersensoren hatte ich das auch nur an meinem CUL, sobald ich ihn dann ins "scharfe" System mit HM-CFG-USB-2 integriert habe gings...

Gut, da es mein Testsystem ist, ist es erst mal nicht so schlimm aber komisch ist es schon...

Trotzdem vielen Dank noch mal!!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 Mai 2016, 00:50:19
Hallo Joachim.

dann stell bitte in FHEM den CUL auf verbose 4 und logge damit mal das pairing von dem device und poste es.

Dann kommen wir vielleicht dahinter, was da klemmt.

Gruß, Ansgar

PS: Du hast auch die .pm Dateien im FHEM Verzeichnis ausgetauscht und das nicht vor lauter Firmwarefreude verdrängt?!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 19 Mai 2016, 01:58:59
Hallo Ansgar,

ja habe ich.
Eben noch mal geprüft...

Hier mal zur Sicherheit ein list des CUL:

Internals:
   CMDS       ABCEFGJKMRTUVWXYZeflmtx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   NAME       nanoCUL_HM
   NR         43
   PARTIAL
   RAWMSG     AFF01001B9F4C000FB586102B8E860000000A98DE0C000004
   RSSI       -72
   STATE      Initialized
   TYPE       CUL
   VERSION    V 99.78 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 2249
   nanoCUL_HM_TIME Initialized
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-05-17 03:22:53   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:-22.217kHz
     2016-05-18 21:27:51   cmds             A B C E F G J K M R T U V W X Y Z e f l m t x
     2016-05-06 00:05:19   credit10ms      900
     2016-05-18 20:22:31   hmSioDly        20
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-05-19 01:47:38   scF             1.00016741512861
     2016-05-19 01:49:52   state           Initialized
     2016-05-17 03:23:10   version         V 99.78 nanoCUL868
   Helper:
     398b7d:
       QUEUE:
     Hm:
       FUP        0
       hmCrdts    0
       hmSbusy    0
     Q:
       Cap:
         sum        45000
     Ref:
       ApCUPend   0
       AsPend     0
       Lhmt       14453088
       Lsys       105257899
       Sdly       7
       dwoCCAAa   104
       nusew      31
       pTTu       1024
       pingMax    4
       pingMin    3
       pingRef    4
       pingdly    4
       pinglm     11
       pingtm     105152473
       scErr      15.4089839153457
       scF        1.00016741512861
       scFN       1
       scHT       14347688
       scHTL      14347688
       scST       105152477
       scSTL      105152477
       tgtdly     104
Attributes:
   hmId       AFFE02
   rfmode     HomeMatic
   verbose    4

und hier das Pairing mit verbose 4 (gestartet um 01:55):

2016.05.19 01:54:05 4: CUL_send:  nanoCUL_HM                            Ap AE     
2016.05.19 01:54:05 4: CUL_Parse: nanoCUL_HM  157819 A FF02 14734848 00 01 AE -138
2016.05.19 01:54:35 4: CUL_Parse: nanoCUL_HM  187178 A FF01 14764200 00 0C 6C 8670 2BBF72 000000 009B2F -76
2016.05.19 01:55:03 4: CUL_Parse: nanoCUL_HM  215540 A FF01 14792560 00 0C 00 865A 31D1FE 000000 90F328 -47.5
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216237 A FF01 14793248 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -66
2016.05.19 01:55:04 2: CUL_HM Unknown device HM_398B7D is now defined
2016.05.19 01:55:04 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.05.19 01:55:04 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.05.19 01:55:04 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.05.19 01:55:04 4: CUL_send:  nanoCUL_HM                         Aw 07 10 02 A001 AFFE02 398B7D 00050000000000
2016.05.19 01:55:04 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:76
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216420 A FF13 14793408 00 10 02 A001 AFFE02 398B7D 00050000000000 -138
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216559 A FF11 14793568 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -58.5
2016.05.19 01:55:04 3: CUL_HM set HM_398B7D getConfig
2016.05.19 01:55:04 4: CUL_send:  nanoCUL_HM                         Aw 08 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.05.19 01:55:04 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:83
2016.05.19 01:55:04 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:112 hmSioDly:22
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216696 A FF13 14793680 00 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02 -138
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216810 A FF11 14793824 00 0A 03 8002 398B7D AFFE02 80 -62
2016.05.19 01:55:05 4: CUL_send:  nanoCUL_HM                            Ap AE     
2016.05.19 01:55:05 4: CUL_Parse: nanoCUL_HM  217931 A FF12 14794952 00 01 AE -138
2016.05.19 01:55:07 4: CUL_Parse: nanoCUL_HM  219618 A FF11 14796632 00 0C A9 865A 3227F4 000000 90E329 -86.5
2016.05.19 01:55:10 4: CUL_Parse: nanoCUL_HM  222453 A FF01 14799464 00 0F B7 8610 2B8E86 000000 0A98DF0C0000 -71.5

und noch das list vom Device nach dem Pairing(versuch):

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     3
   NAME       HM_398B7D
   NR         360
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398B7D d:AFFE02 80
   nanoCUL_HM_MSGCNT 3
   nanoCUL_HM_RAWMSG A0A038002398B7DAFFE0280::-62:nanoCUL_HM
   nanoCUL_HM_RSSI -62
   nanoCUL_HM_TIME 2016-05-19 01:55:04
   protCmdDel 5
   protLastRcv 2016-05-19 01:55:04
   protNack   1 last_at:2016-05-19 01:55:04
   protSnd    2 last_at:2016-05-19 01:55:04
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-62.16 min:-66 max:-58.5 lst:-62 cnt:3
   Readings:
     2016-05-19 01:55:04   CommandAccepted no
     2016-05-19 01:55:04   D-firmware      1.0
     2016-05-19 01:55:04   D-serialNr      MEQ0656892
     2016-05-19 01:55:04   R-pairCentral   set_0xAFFE02
     2016-05-19 01:55:04   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       01AFFE02398B7D00050000000000,01AFFE02398B7D000802010AAF0BFE0C02
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LRcTm      14793824
       LRcTmCnt   1
       LSndDlya
       LSndDlyb
       newChn     +398B7D,00,00,00
       nextSend   1463615704.90757
       nextSendLRmsg A0A038002398B7DAFFE0280
       prefIO
       rxt        0
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL_HM -60
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A001AFFE02398B7D00050000000000
         ++A001AFFE02398B7D000802010AAF0BFE0C02
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -62.1666666666667
         cnt        3
         lst        -62
         max        -58.5
         min        -66
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

Vielen Dank (schon mal/noch mal)!!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 Mai 2016, 06:49:10
Hallo Joachim,

an dieser Stelle wäre jetzt Martin gefragt bezüglich der Protokoll Interpretation.

Ich sehe da ein "Nack" vom Device. Und interpretiere es so, dass es nicht mitspielen will.

Hast Du es mal auf Werkseinstellungen zurück gesetzt?


Ansonsten sehe ich noch, dass Du eine hmId AFFE02 gewählt hast. Normalerweise wird F1nnnn gewählt wobei nnnn der FHTID entspricht. Ob das ein Problem macht, kann wohl Martin sagen.

Generell solltest Du nicht relativ kurz nach einem FHEM Neustart ein Pairing versuchen, da ich erst versuche die Laufzeitunterschiede der Uhren zu ermitteln. Lass dem Vorgang mal mind. 1 Stunde Zeit.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 19 Mai 2016, 08:17:15
Hallo Ansgar,

danke.

Ja, habe beides getestet, also mit und ohne zurücksetzen...
Die Aufzeichnung war nach dem Zurücksetzen...

Letzter fhem Start müßte aber (deutlich) mehr als eine Stunde zurück gelegen sein (soweit ich mich erinnere, kann grad nicht nachschauen).

Aber ich probiere noch mal...

Hmmm, AFFE02 auf meinen "scharfen" System habe ich AFFE01 und keine Probleme.
Allerdings einen HM-CFG-USB...

Ich werde auch dort einfach mal testen und schauen, ob sich der Klingelsensor ähnlich wie die optischen Fensterkontakte verhält, also etwas zickig mit dem CUL (noch keine Spezialversion) und dann problemlos mit dem "scharfen" System...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Mai 2016, 00:38:22
Hallo Joachim, hallo Martin, hallo Testwillige,

angehängt eine neue Testversion der .pm Dateien zur Zusammenarbeit mit der Timestamp Firmware.

Es gibt darin bei CUL und CUL_HM ein neues Attribut "hmDstDly". Mittles Slider kann es von 96ms bis 128ms in 8ms Schritten verändert werden.
Wird es nicht gesetzt, dann wird auf 120ms Antwortzeit optimiert. Wird es nur bei CUL gesetzt, dann wird diese Zielantwortzeit für alle damit verknüpften HM Devices eingestellt.
Wird das Attribut für ein HM Device gesetzt, dann wird nur die Zielantwortzeit für dieses eine Gerät verändert. Damit kann man auch unterschiedliche Firmwarestände optimieren.

In der fhem.cfg lassen sich auch Werte jenseits dieser Grenzen einstellen, wenn exotischer getestet werden möchte.

Weiterhin gibt es bei HM devices ein neues Atrribut "UseRepeater" für die Nutzung eines HM Repeaters (HM-Sys-sRP-Pl). Per default ist es auf 0, was gedacht ist für Devices, die nicht selektiv von einem Repeater wiedeholt werden.
Wird es auf 1 gesetzt, dann werden nur noch die Repeater Nachrichten des Devices ausgewertet und mit einer um 88ms verkürzten Antwortzeit beantwortet. Die direkt empfangenen Nachrichten werden unterdrückt. Anwendung für die Kommunikationsoptimierung zu Aktoren.
Wird es auf 2 gesetzt, dann werden beide Nahrichten durchgelassen und von/über CUL_HM beantwortet. Empfangene CUL sende Nachrichten vom Repeater werden unterdrückt (Rechenzeit Optimierung). Anwendung für die Empfangsoptimierung von Sensoren.
Wird es auf 3 gesetzt, dann erscheinen diese Nachichten zumindest im Log, werden aber für CUL_HM unterdrückt. Anwendung zu Debuggingzwecken, um das Timing vollständig sichtbar zu machen.

Meine Tests im Nahbereich und einer CUL_V3 und UseRepeater=1 laufen damit ganz gut mit Repeateten Devices (beide Nachrichten werden jeweils empfangen).
Fernbeich konnte ich bisher nicht testen, also den Fall, dass nur noch der Repeater das Device erreicht bzw. dessen Nachrichten empfängt.

Da echt serielle Devices in der Kommunikation über die serielle Schnittstelle zwangsläufig größere Verzögerungen haben, sind diese mit Repeater kritisch bis unbrauchbar. Insbesondere mit Stacking.
Die Rechenpower des FHEM Hosts muss hier lindern, sofern es überhaupt geht.

@Joachim: versuch mal mit unterschiedlicher "hmDstDly" Einstellung ein pairing mit HM-Sen-DB-PCB. Da es zumindest angelegt wird, kann es mit anderem Timing hoffentlich besser mit dem Pairing klappen.
EDIT: "FHEM module changed 2.ZIP" ausgetauscht gegen "FHEM module changed 3.ZIP".

Gruß, Ansgar.

PS: Wie immer der Hinweis, erst Dateien sichern, dann gegen die aus der Zip Datei tauschen...

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 22 Mai 2016, 08:40:59
Hallo Ansgar,

vielen Dank schon mal!

Komme aber erst heute Abend (oder morgen) zum Testen...

Bin schon sehr gespannt!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 23 Mai 2016, 01:04:49
Hallo Ansgar,

habe mal die pms eingespielt.

Zunächst dachte ich "nur", leider kein Unterschied, bis mir dann eingefallen ist: shutdown restart bzw. Module neu laden...

Leider kommt mein fhem nun nicht mehr auf die Beine:

2016.05.23 00:58:02 3: Opening nanoCUL_HM device /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
2016.05.23 00:58:02 3: Setting nanoCUL_HM serial parameters to 38400,8,N,1
2016.05.23 00:58:02 3: nanoCUL_HM device opened
2016.05.23 00:58:02 1: nanoCUL_HM is VERSION_TS, V 99.78 nanoCUL868, nanoCUL_V1.x
2016.05.23 00:58:03 3: nanoCUL_HM: Possible commands: ABCEFGJKMRTUVWXYZeflmtx
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.
Illegal division by zero at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.

Weil ich grad dabei bin (schon mal vorfühlen für den nächsten Test):

in welche Richtung ist denn besser bzw. was bedeutet "hmDstDly" (HM -> Destination Delay!?).
Leider kann ich das HM-Protokoll (noch ;-)  ) nicht "lesen" bzw. auch nicht genau verstehen was in den Logs (vom letzten Mal) zu sehen ist.
Also wer auf wen wartet bzw. wer wo einen Timeout hat.

Entweder bekomme ich "timeout Register Read" oder einfach nur ein simples "NACK"...

Vielen Dank noch mal/wieder für deine Mühe!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 23 Mai 2016, 22:57:46
Hallo Joachim,

Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.
Illegal division by zero at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.
ich habe die ZIP in meinem letzten Beitrag ausgetauscht.
Ein Problem bei der Variableninitalisierung bei fehlendem Scewfactor. Ich hoffe, jetzt klappt es.

Zitat
HM -> Destination Delay!?
Richtig. Und 100 bis 120ms sollen es wohl normalerweise sein.
Den Einstellbereich habe ich mal zum Spielen vergrößert und auch auf 4ms Schrittweite geändert, was bezüglich Gangunterschied bei den Uhren sinnoll sein kann. 8ms ist aber weiterhin die CUL Timer Auflösung.

Zitat
Leider kann ich das HM-Protokoll (noch ;-)  ) nicht "lesen" bzw. auch nicht genau verstehen was in den Logs (vom letzten Mal) zu sehen ist.
Leider fehlt auch mir die Zeit, um das mal intensiv zu studieren. Martin ist da der Eperte. Bzw. in dem von Dir genannten Thread hat Oliver das wohl schon mal auseinander genommen https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045 (https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 24 Mai 2016, 02:00:28
Hallo Ansgar,

neue pms eingespielt, laufen soweit aber leider klappt es mit dem HM-Sen-Db-Pcb immer noch nicht.

Habe diverse Werte getestet, immer wieder gelöscht und angelernt usw.

Das Gerät zeigt zwar "grün", also eigentlich alles ok...
...aber fhem zeigt beim Gerät "NACK" und R-pairCentral bleibt auf set_0xAFFE02.
(also nicht ganz so wie in der Analyse von Oliver, zumindest soweit ich das verstanden hab)

Scheint wirklich ein hartnäckiges Bürschchen zu sein...

Habe es dann mal mit meinem "scharfen" System mit HM-CFG-USB-2/hmlan gepairt, dort klappt es sofort.

Achja, dort ist die HMID AFFE11 nicht wie ich dachte AFFE01, kann das etwas ausmachen??

Allerdings laufen auf meinem Testsystem auch andere HM-Komponenten (z.B. Wandthermostat und Schalteraktor) problemlos.

Einzig mit dem Klingelsensor und den optischen Fenstersensoren hatte ich bislang Probleme damit, dass R-pairCentral nicht klappt und auf set_ stehen bleibt.

Die magnetischen Fenstersensoren habe ich gleich mit dem "scharfen" System betrieben (da hatte ich noch kein Testsystem).

Da der Klingelsensor am "scharfen" System arbeitet werde ich hier mal aufgeben, sorry...
Allerdings für den Fall, dass was getestet werden soll (für andere Betroffene bzw. um das System besser zu machen) steht das Testsystem nat. "zur Verfügung"... ;-)

Ich werde noch im Thread mit dem Klingelsensor nach hier verlinken, vielleicht passiert noch etwas...
...ansonsten werde ich wie gesagt erst mal so weiter leben...

Vielen, vielen Dank Ansgar!

Und wie gesagt, falls es etwas zu testen gibt, bin ich nat. dabei!

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 26 Juni 2016, 16:20:56
Hallo Testwillige, hallo Martin,

im Anhang eine neue Version zum Testen.

Bezüglich Firmware ist die Timestamp Rückmeldung eines ASKSIN Sendebefehls (As, Aa, Aw) geändert. Bisher wurde die Timestamp und das komplette Sendepaket nach dem Senden zurück gemeldet. Nun wird nicht mehr das komplette Sendepaket mit zurück gemeldet, sondern nur noch bis zur Destination Id. Das ist nach derzeitigem Stand ausreichend und spart etwas Rückmeldezeit insbesondere für serielle devices.

RFR-Router und FastRF Änderungen in der Firmware sind noch Baustelle und ungetestet, also dessen Nutzungsversuche nicht zu empfehlen, was für ASKSIN/HM aber nicht relevant ist.

Zur Nutzung der Timestamp Funktionalität müssen die .pm Module aus der angehängten 20160612_fhem.zip verwendet werden.

Bitte, wie immer, unbedingt erst ein Backup der vorhandenen Dateiein im FHEM Ordner anlegen und dann die Dateien aus der 20160612_fhem.zip hinein kopieren.

Was hat sich geändert:

- das Attribut "UseRepeater" ist entfallen

- mit dem Attribut "hmDstDly" kann sowohl bei CUL als globale Einstellung, als auch bei HM devices die Zielverzögerung für HM Antworten etwas vom Default 120 variiert werden

- es gibt ein neues Attribut "RepBstAddDly" für HM devices. Das ist für die experimentelle HM-Repeater Nutzung von Burst devices speziell in Verbnindung mit STACKABLE_CC relevant. Da eine Antwort auf die erste Nachricht nach einem Burst zum device offenbar timingkritisch nicht erfolgreich verläuft (Kollision?), wird damit eine Zusatzzeit eingestellt, um passend zur nächsten wiederholten Nachricht vom device zu antworten. Für HM-LC-SW1-BA-PCB habe ich 552 als guten Wert ermittelt und als default gewählt, was aber bei anderen devices auch nicht passen kann. Somit kann man hier nach Logging und Timingbetrachtung per Burst device anpassen.

- Es wird automatisch versucht, die Repeaternutzung festzustellen, was insbesondere für die Senderichtung zum device relevant ist. Mit dem neuen Attribut "SndThrRep" kann die Automatik "überschrieben" werden, sprich die Erwartung über einen HM-Repeater zu device zu senden an und abgeschaltet werden. Die Automatik basiert auf empfangenen HM-Repeater Nachrichten von CUL zum Device und auf der per getConfig beim HM-Repeater ermittelten Konfiguration. Nach einem Neustart von FHEM ist die Info verloren und muss neu "eingesammelt" werden. Der erste "getConfig" nach einem Neustart von FHEM kann daher schief gehen.

- mit dem neuen Atrribut "hmLogRptSnd" kann das logging von empfangenen Repeaternachrichten, die CUL abgesetzt hat, aktiviert werden. Per default werden sie im Log unterdrückt, um etwas Rechenzeit zu sparen.
CUL empfängt diese Nachrichten auch nicht immer, was wohl mit dem Umschaltzeit auf Empfang nach dem Senden zusammenhängt.

- Das Sendetiming wurde weiter optimiert und erweitert. Nun werden nicht nur Antworten passend um 120ms verzögert, sondern auch das jeweils erste neue Kommando an das device nachdem eine Antwort gesendet wurde. 96ms hat sich bei mir als brauchbar erwiesen.

- Die Verzögerungsberechnung berücksichtigt nun die Übertragungsrate zum device. Bei CUL und seriellen devices wird die "@baudrate" Information der Definition genutzt.
Damit muss bei CUL "Schnittstelle@12000000" entsprechend der USB Datenrate eingestellt werden (Atmel mit USB Schnittstelle).
Bei SCC/COC ist es "Schnittstelle@38400" für das direkt auf dem RaspPi sitzende device. Stacked devices nutzen auch diese Einstellung des ersten SCC.
Bei CUNO/CUNO2 bei Nutzung der USB Schnittstelle "Schnittstelle@38400" (Atmel mit serieller Schnittstelle).
Bei CUNO/CUNO2 bei Nutzung der Ethernet Schnittstelle muss nichts geändert werden, da die Datenrate des Netzwerks genutzt wird.
Für die Datenrate ist die langsamste Teilstrecke auf der Verbindungsstrecke relevant!

Noch ein Hinweis: Es ist derzeit nur die Nutzung eines CUL device zum Empfangen von ASKSIN/HM möglich/sinnvoll. Die Uhren laufen unterschiedlich auf den verschiedenen CULs. Timestamps werden damit ggf. unbrauchbar, wenn 2 oder mehr CULs die gleiche Nachricht vom device empfangen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Notifies bzw. events können je nach Umfang des Systems erheblich zu Timingproblemen führen. Also bei der Konfiguration des FHEM Systems konsequent Events abschalten, sie nicht benötigt werden (attribut event-on-change-reading reduzierend nutzen!).
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 26 Juni 2016, 16:53:36
Hallo Ansgar,

werd die Tage mal testen...
...und berichten.

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 26 Juni 2016, 18:27:22
Hallo Joachim,

ich hoffe, es hilft auch bei Deinem Problem mit dem Klingelsensor, wenn es nur das Timing sein sollte und nicht ein Protokoll Exot.

Feedback bitte mit Logging mit CUL auf verbose 4.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 27 Juni 2016, 21:36:47
Hallo Ansgar,

hab's eben runtergeladen und auf den PI kopiert.

Habe board.h wie folgt angepasst:

//#define HAS_CC1101_433

also 433 auskommentiert, da ich ja einen 868 habe...

Folgendes musste ich rein nehmen (also "einkommentieren"), sonst gab es einen Fehler in Asksin:

#define SPI_CC1101_READ_SPECIAL_PIN   6 

Ansonsten nichts weiter verändert...

Ich werde mal flashen und sehen...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 27 Juni 2016, 21:58:37
Hallo Ansgar,

so getestet, leider immer noch NACK.

Habe mal noch nichts eingestellt...

Hier das Log mit verbose 4:

2016.06.27 21:53:05 4: CUL_Parse: nanoCUL_HM  271482                  A 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -49.5
2016.06.27 21:53:05 2: CUL_HM Unknown device HM_398B7D is now defined
2016.06.27 21:53:05 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.06.27 21:53:05 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.06.27 21:53:05 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.06.27 21:53:05 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_CUL.pm line 1615.
2016.06.27 21:53:05 4: CUL_send:  nanoCUL_HM                         As 10 02 A001 AFFE02 398B7D 00050000000000
2016.06.27 21:53:06 4: CUL_Parse: nanoCUL_HM  271721                  A 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -49
2016.06.27 21:53:06 3: CUL_HM set HM_398B7D getConfig
2016.06.27 21:53:06 4: CUL_send:  nanoCUL_HM                         As 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.06.27 21:53:06 4: CUL_Parse: nanoCUL_HM  271917                  A 0A 03 8002 398B7D AFFE02 80 -47.5
2016.06.27 21:53:22 4: CUL_Parse: nanoCUL_HM  288255                  A 0F 59 8610 2B1A82 000000 0A60FF0B0040 -53.5
2016.06.27 21:53:26 4: CUL_Parse: nanoCUL_HM  292416                  A 0C DE 865A 453732 000000 A8FA2E -59.5
2016.06.27 21:53:27 4: CUL_Parse: nanoCUL_HM  292725                  A 0C 35 865A 32279A 000000 98FC2F -66

Hier ein list des nanoCUL:

Internals:
   CMDS       BCFiAZEkGMKUYRTVWXefltx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   NAME       nanoCUL_HM
   NR         43
   PARTIAL
   RAWMSG     A0F8F86102B8E860000000A98FC0C004001
   RSSI       -73.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 nanoCUL868
   initString X21
Ar
   nanoCUL_HM_MSGCNT 127
   nanoCUL_HM_TIME Initialized
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-06-27 21:46:01   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:0.000kHz
     2016-06-27 21:41:47   cmds             B C F i A Z E k G M K U Y R T V W X e f l t x
     2016-05-06 00:05:19   credit10ms      900
     2016-05-21 08:31:29   hmSioDly        24
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-06-07 22:41:23   scF             1.00020254163391
     2016-06-27 21:55:08   state           Initialized
     2016-06-27 21:46:12   version         V 1.66 nanoCUL868
   Helper:
     398b7d:
       QUEUE
     Ref:
       AsPend     2
       IObyterate 3840
       doNbyterate 10
       hmDstDly   120
       scF        1
Attributes:
   hmId       AFFE02
   rfmode     HomeMatic
   verbose    4

und noch ein list des "Problemkinds" (Klingelsensor):

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     3
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         388
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398B7D d:AFFE02 80
   nanoCUL_HM_MSGCNT 3
   nanoCUL_HM_RAWMSG A0A038002398B7DAFFE0280::-47.5:nanoCUL_HM
   nanoCUL_HM_RSSI -47.5
   nanoCUL_HM_TIME 2016-06-27 21:53:06
   protCmdDel 5
   protLastRcv 2016-06-27 21:53:06
   protNack   1 last_at:2016-06-27 21:53:06
   protSnd    2 last_at:2016-06-27 21:53:06
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-48.66 min:-49.5 max:-47.5 lst:-47.5 cnt:3
   Readings:
     2016-06-27 21:53:06   CommandAccepted no
     2016-06-27 21:53:06   D-firmware      1.0
     2016-06-27 21:53:06   D-serialNr      MEQ0656892
     2016-06-27 21:53:05   R-pairCentral   set_0xAFFE02
     2016-06-27 21:53:06   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       01AFFE02398B7D00050000000000,01AFFE02398B7D000802010AAF0BFE0C02
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LastRecTyp 02
       lastSend   1467057186.25276
       lastSendtgd
       newChn     +398B7D,00,00,00
       nextSend   1467057186.44878
       nextSendMcnt 03
       prefIO
       rxt        0
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL_HM -45.5
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A001AFFE02398B7D00050000000000
         ++A001AFFE02398B7D000802010AAF0BFE0C02
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -48.6666666666667
         cnt        3
         lst        -47.5
         max        -47.5
         min        -49.5
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

Welche Parameter soll/kann ich denn am besten anpassen?

Habe ich sonst was "falsch" gemacht??
Bzw. was übersehen??

Kann ich noch was für dich testen??

Gruß und danke, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 27 Juni 2016, 22:04:08
Hier noch ein wenig output/input ;-)

Nach einem getConfig bekomme ich dann (wieder) timeout Register read...

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     5
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         388
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:04 - t:00 s:398B7D d:000000 1000DC4D45513036353638393240010101
   nanoCUL_HM_MSGCNT 5
   nanoCUL_HM_RAWMSG A1A048400398B7D0000001000DC4D45513036353638393240010101::-48:nanoCUL_HM
   nanoCUL_HM_RSSI -48
   nanoCUL_HM_TIME 2016-06-27 21:59:13
   protCmdDel 8
   protLastRcv 2016-06-27 21:59:13
   protNack   1 last_at:2016-06-27 21:53:06
   protResndFail 1 last_at:2016-06-27 21:59:18
   protSnd    3 last_at:2016-06-27 21:59:13
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-48.1 min:-49.5 max:-46.5 lst:-48 cnt:5
   Readings:
     2016-06-27 21:53:06   CommandAccepted no
     2016-06-27 21:59:13   D-firmware      1.0
     2016-06-27 21:59:13   D-serialNr      MEQ0656892
     2016-06-27 21:53:05   R-pairCentral   set_0xAFFE02
     2016-06-27 21:59:18   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   4
     cSnd       01AFFE02398B7D000802010AAF0BFE0C02,01AFFE02398B7D00040000000000
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LastRecTyp 00
       lastSend   1467057553.53061
       lastSendtgd
       newChn     +398B7D,00,00,00
       nextSend   1467057553.7358
       nextSendMcnt 04
       prefIO
       rxt        0
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        04
       Io:
         nanoCUL_HM -46
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -48.1
         cnt        5
         lst        -48
         max        -46.5
         min        -49.5
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

hier das log dazu (inkl. pairing von vorhin):

2016.06.27 21:53:05 4: CUL_Parse: nanoCUL_HM  271482                  A 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -49.5
2016.06.27 21:53:05 2: CUL_HM Unknown device HM_398B7D is now defined
2016.06.27 21:53:05 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.06.27 21:53:05 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.06.27 21:53:05 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.06.27 21:53:05 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_CUL.pm line 1615.
2016.06.27 21:53:05 4: CUL_send:  nanoCUL_HM                         As 10 02 A001 AFFE02 398B7D 00050000000000
2016.06.27 21:53:06 4: CUL_Parse: nanoCUL_HM  271721                  A 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -49
2016.06.27 21:53:06 3: CUL_HM set HM_398B7D getConfig
2016.06.27 21:53:06 4: CUL_send:  nanoCUL_HM                         As 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.06.27 21:53:06 4: CUL_Parse: nanoCUL_HM  271917                  A 0A 03 8002 398B7D AFFE02 80 -47.5
2016.06.27 21:53:22 4: CUL_Parse: nanoCUL_HM  288255                  A 0F 59 8610 2B1A82 000000 0A60FF0B0040 -53.5
2016.06.27 21:53:26 4: CUL_Parse: nanoCUL_HM  292416                  A 0C DE 865A 453732 000000 A8FA2E -59.5
2016.06.27 21:53:27 4: CUL_Parse: nanoCUL_HM  292725                  A 0C 35 865A 32279A 000000 98FC2F -66
2016.06.27 21:53:29 4: CUL_Parse: nanoCUL_HM  295142                  A 0F 32 8610 2BA56B 000000 0A60FA0B0040 -65.5
2016.06.27 21:53:33 4: CUL_Parse: nanoCUL_HM  299315                  A 0C EF 865A 31D958 000000 90FD30 -70
2016.06.27 21:53:35 4: CUL_Parse: nanoCUL_HM  300976                  A 0C E4 865A 322927 000000 60FA32 -56.5
2016.06.27 21:53:46 4: CUL_Parse: nanoCUL_HM  312416                  A 0C DE 8470 453732 000000 00FA2E -60
2016.06.27 21:53:47 4: CUL_Parse: nanoCUL_HM  312725                  A 0C 35 8470 32279A 000000 00FC2F -66
2016.06.27 21:53:48 4: CUL_Parse: nanoCUL_HM  313688                  A 0C 73 865A 3227F4 000000 90FC2E -70
2016.06.27 21:53:52 4: CUL_Parse: nanoCUL_HM  318477                  A 0C 90 865A 32185B 000000 60FF2E -47.5
2016.06.27 21:53:53 4: CUL_Parse: nanoCUL_HM  319316                  A 0C EF 8470 31D958 000000 00FD30 -69.5
2016.06.27 21:53:54 4: CUL_Parse: nanoCUL_HM  320305                  A 0F A2 8610 2D9B77 000000 0A60EC0C0040 -68
2016.06.27 21:53:55 4: CUL_Parse: nanoCUL_HM  320977                  A 0C E4 8470 322927 000000 00FA32 -56.5
2016.06.27 21:54:00 4: CUL_Parse: nanoCUL_HM  326126                  A 0C 50 865A 31D1FE 000000 91052B -53
2016.06.27 21:54:08 4: CUL_Parse: nanoCUL_HM  333688                  A 0C 73 8470 3227F4 000000 00FC2E -69.5
2016.06.27 21:54:11 4: CUL_Parse: nanoCUL_HM  337051                  A 0F E4 8610 2C8BFC 000000 0A90FD0C0040 -60.5
2016.06.27 21:54:12 4: CUL_Parse: nanoCUL_HM  338477                  A 0C 90 8470 32185B 000000 00FF2E -47
2016.06.27 21:54:20 4: CUL_Parse: nanoCUL_HM  346124                  A 0C 50 8470 31D1FE 000000 01052B -53
2016.06.27 21:54:27 4: CUL_Parse: nanoCUL_HM  353290                  A 14 E3 845E 4A347F 000000 800B2900000000000914FE -61.5
2016.06.27 21:54:53 4: CUL_Parse: nanoCUL_HM  379288                  A 0C F8 8670 2BBF72 000000 00DF34 -63
2016.06.27 21:55:08 4: CUL_Parse: nanoCUL_HM  394082                  A 0F 8F 8610 2B8E86 000000 0A98FC0C0040 -73.5
2016.06.27 21:55:09 4: CUL_Parse: nanoCUL_HM  395178                  A 0C E3 865A 3229B5 000000 60ED30 -61
2016.06.27 21:55:29 4: CUL_Parse: nanoCUL_HM  415178                  A 0C E3 8470 3229B5 000000 00ED30 -60.5
2016.06.27 21:55:36 4: CUL_Parse: nanoCUL_HM  422227                  A 0C E5 865A 322927 000000 60FA32 -56.5
2016.06.27 21:55:56 4: CUL_Parse: nanoCUL_HM  442227                  A 0C E5 8470 322927 000000 00FA32 -56.5
2016.06.27 21:56:05 4: CUL_Parse: nanoCUL_HM  450566                  A 0C F0 865A 31D958 000000 90FD30 -70
2016.06.27 21:56:11 4: CUL_Parse: nanoCUL_HM  457052                  A 0F E5 8610 2C8BFC 000000 0A90FD0C0040 -60.5
2016.06.27 21:56:11 4: CUL_Parse: nanoCUL_HM  457418                  A 0C DF 865A 453732 000000 A8FB2E -60
2016.06.27 21:56:16 4: CUL_Parse: nanoCUL_HM  461689                  A 0C 74 865A 3227F4 000000 90FC2E -70
2016.06.27 21:56:16 4: CUL_Parse: nanoCUL_HM  461759                  A 0F 5A 8610 2B1A82 000000 0A60FF0B0040 -53.5
2016.06.27 21:56:18 4: CUL_Parse: nanoCUL_HM  464144                  A 0F 33 8610 2BA56B 000000 0A60FA0B0040 -65
2016.06.27 21:56:20 4: CUL_Parse: nanoCUL_HM  466227                  A 0C 36 865A 32279A 000000 98FC30 -65.5
2016.06.27 21:56:21 4: CUL_Parse: nanoCUL_HM  467419                  A 0E E2 8410 453732 000000 0BA8FB0E00 -61
2016.06.27 21:56:25 4: CUL_Parse: nanoCUL_HM  470566                  A 0C F0 8470 31D958 000000 00FD30 -69.5
2016.06.27 21:56:31 4: CUL_Parse: nanoCUL_HM  477418                  A 0C DF 8470 453732 000000 00FB2E -61
2016.06.27 21:56:34 4: CUL_Parse: nanoCUL_HM  479736                  A 0C 91 865A 32185B 000000 60FF2E -47
2016.06.27 21:56:36 4: CUL_Parse: nanoCUL_HM  481689                  A 0C 74 8470 3227F4 000000 00FC2E -70.5
2016.06.27 21:56:40 4: CUL_Parse: nanoCUL_HM  486227                  A 0C 36 8470 32279A 000000 00FC30 -66
2016.06.27 21:56:49 4: CUL_Parse: nanoCUL_HM  495375                  A 0C 51 865A 31D1FE 000000 91052B -53
2016.06.27 21:56:52 3: OutsideWeatherFth: Read response to update didn't match any Reading
2016.06.27 21:56:54 4: CUL_Parse: nanoCUL_HM  499729                  A 0C 91 8470 32185B 000000 00FF2E -47
2016.06.27 21:56:54 4: CUL_Parse: nanoCUL_HM  500555                  A 0F A3 8610 2D9B77 000000 0A60ED0C0040 -69
2016.06.27 21:57:09 4: CUL_Parse: nanoCUL_HM  515375                  A 0C 51 8470 31D1FE 000000 01052B -52.5
2016.06.27 21:57:16 4: CUL_Parse: nanoCUL_HM  522042                  A 0C F9 8670 2BBF72 000000 00DF34 -64.5
2016.06.27 21:57:24 4: CUL_Parse: nanoCUL_HM  005753                  A 14 E4 845E 4A347F 000000 800B290000000000091701 -61.5
2016.06.27 21:57:26 4: CUL_Parse: nanoCUL_HM  008045                  A 0F 90 8610 2B8E86 000000 0A98FC0C0040 -73.5
2016.06.27 21:57:57 4: CUL_Parse: nanoCUL_HM  038642                  A 0C E4 865A 3229B5 000000 60EE30 -61
2016.06.27 21:58:07 4: CUL_Parse: nanoCUL_HM  048643                  A 0E 24 8410 3229B5 000000 0B60EE2D40 -61
2016.06.27 21:58:17 4: CUL_Parse: nanoCUL_HM  058641                  A 0C E4 8470 3229B5 000000 00EE30 -60.5
2016.06.27 21:58:22 4: CUL_Parse: nanoCUL_HM  063278                  A 0C F1 865A 31D958 000000 90FD30 -71
2016.06.27 21:58:27 4: CUL_Parse: nanoCUL_HM  068689                  A 0C E6 865A 322927 000000 60FA32 -56.5
2016.06.27 21:58:29 4: CUL_Parse: nanoCUL_HM  070902                  A 0C 75 865A 3227F4 000000 90FC2E -71
2016.06.27 21:58:42 4: CUL_Parse: nanoCUL_HM  083279                  A 0C F1 8470 31D958 000000 00FD30 -70.5
2016.06.27 21:58:42 4: CUL_Parse: nanoCUL_HM  083631                  A 0C E0 865A 453732 000000 A8FB2E -61
2016.06.27 21:58:47 4: CUL_Parse: nanoCUL_HM  088688                  A 0C E6 8470 322927 000000 00FA32 -56.5
2016.06.27 21:58:49 4: CUL_Parse: nanoCUL_HM  090901                  A 0C 75 8470 3227F4 000000 00FC2E -70.5
2016.06.27 21:58:53 4: CUL_Parse: nanoCUL_HM  094357                  A 0F 34 8610 2BA56B 000000 0A60FA0B0040 -65
2016.06.27 21:58:55 4: CUL_Parse: nanoCUL_HM  096724                  A 0F 5B 8610 2B1A82 000000 0A60FF0B0040 -53.5
2016.06.27 21:58:59 4: CUL_Parse: nanoCUL_HM  101191                  A 0C 37 865A 32279A 000000 98FC30 -66
2016.06.27 21:59:00 4: CUL_Parse: nanoCUL_HM  102191                  A 0C 92 865A 32185B 000000 60FF2E -47
2016.06.27 21:59:00 4: CUL_Parse: nanoCUL_HM  102267                  A 0F E6 8610 2C8BFC 000000 0A90FD0C0040 -60.5
2016.06.27 21:59:02 4: CUL_Parse: nanoCUL_HM  103631                  A 0C E0 8470 453732 000000 00FB2E -61
2016.06.27 21:59:08 3: CUL_HM set HM_398B7D getConfig
2016.06.27 21:59:13 4: CUL_Parse: nanoCUL_HM  114711                  A 1A 03 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.06.27 21:59:13 4: CUL_send:  nanoCUL_HM                         As 10 04 A001 AFFE02 398B7D 00040000000000
2016.06.27 21:59:13 4: CUL_Parse: nanoCUL_HM  114916                  A 1A 04 8400 398B7D 000000 1000DC4D45513036353638393240010101 -48
2016.06.27 21:59:19 4: CUL_Parse: nanoCUL_HM  121191                  A 0C 37 8470 32279A 000000 00FC30 -65.5
2016.06.27 21:59:20 4: CUL_Parse: nanoCUL_HM  122192                  A 0C 92 8470 32185B 000000 00FF2E -47
2016.06.27 21:59:24 4: CUL_Parse: nanoCUL_HM  126088                  A 0C 52 865A 31D1FE 000000 91052B -52.5
2016.06.27 21:59:24 4: CUL_Parse: nanoCUL_HM  126256                  A 0C FA 8670 2BBF72 000000 00DF34 -66
2016.06.27 21:59:30 4: CUL_Parse: nanoCUL_HM  131796                  A 0F 91 8610 2B8E86 000000 0A98FC0C0040 -72.5
2016.06.27 21:59:40 4: CUL_Parse: nanoCUL_HM  142019                  A 0F A4 8610 2D9B77 000000 0A60EE0C0040 -68.5
2016.06.27 21:59:44 4: CUL_Parse: nanoCUL_HM  146087                  A 0C 52 8470 31D1FE 000000 01052B -53
2016.06.27 22:00:06 4: CUL_Parse: nanoCUL_HM  168252                  A 14 E5 845E 4A347F 000000 800B2900000000000917FE -61
2016.06.27 22:00:24 4: CUL_Parse: nanoCUL_HM  185779                  A 0C F2 865A 31D958 000000 90FD30 -70
2016.06.27 22:00:30 4: CUL_Parse: nanoCUL_HM  192142                  A 0C E5 865A 3229B5 000000 60EF30 -61
2016.06.27 22:00:40 4: CUL_Parse: nanoCUL_HM  202144                  A 0E 25 8410 3229B5 000000 0B60EF2D40 -61
2016.06.27 22:00:44 4: CUL_Parse: nanoCUL_HM  205778                  A 0C F2 8470 31D958 000000 00FD30 -70
2016.06.27 22:00:50 4: CUL_Parse: nanoCUL_HM  212143                  A 0C E5 8470 3229B5 000000 00EF30 -61
2016.06.27 22:00:58 4: CUL_Parse: nanoCUL_HM  219883                  A 0C E1 865A 453732 000000 A8FB2E -59.5
2016.06.27 22:01:03 4: CUL_Parse: nanoCUL_HM  225189                  A 0C E7 865A 322927 000000 60FA32 -56.5
2016.06.27 22:01:13 4: CUL_Parse: nanoCUL_HM  234359                  A 0F 35 8610 2BA56B 000000 0A60FA0B0040 -65.5
2016.06.27 22:01:13 4: CUL_Parse: nanoCUL_HM  234443                  A 0C 93 865A 32185B 000000 60FF2E -47

Ich lasse die Installation auf meinem Testsystem mal noch ein Weilchen so...
...falls ich noch was testen kann...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 27 Juni 2016, 22:21:17
Habe mal noch mal geflasht (irgendwie habe ich im Kopf war letztes Mla die FW-Version deutlich anders) um sicher zu gehen...

Nach dem Booten dauert der Start von fhem extrem lange...

Folgende Meldung ist im Log die letzte für lange Zeit:

2016.06.27 22:14:33 1: Including fhem.cfg
2016.06.27 22:14:34 3: telnetPort: port 7072 opened
2016.06.27 22:14:34 3: WEB: port 8083 opened
2016.06.27 22:14:34 2: eventTypes: loaded 999 events from ./log/eventTypes.txt
2016.06.27 22:14:35 3: Opening nanoCUL_HM device /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
2016.06.27 22:14:35 3: Setting nanoCUL_HM serial parameters to 38400,8,N,1
2016.06.27 22:14:35 3: nanoCUL_HM device opened
2016.06.27 22:14:57 1: PERL WARNING: Use of uninitialized value $tsa in concatenation (.) or string at ./FHEM/00_CUL.pm line 2662, <$fh> line 75.
2016.06.27 22:18:17 3: nanoCUL_HM: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2016.06.27 22:18:17 2: Switched nanoCUL_HM rfmode to HomeMatic

Also ca. 3 1/2 Minuten...

Gruß, Joachim

P.S.: nach dem ersten flashen und booten dachte ich schon fhem startet gar nicht mehr... ;-)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Juni 2016, 00:06:45
Hallo Joachim,

danke für den Testversuch.

Blätter erst mal hierhin zurück https://forum.fhem.de/index.php/topic,24436.msg451582.html#msg451582 (https://forum.fhem.de/index.php/topic,24436.msg451582.html#msg451582) bezüglich Anpassungen der Firmware.
Und natürlich die neuen angepassten *.pm aus dem zweiten zip alle benutzen.

Aus dem, was an Logs zu sehen ist, hast Du nicht die compilierte Firmware geflasht, sondern die Standard Firmware. Die Version muss V 99.79 sein, wenn es mit dem flashen richtig geklappt hat.

Ergänze bitte noch

attr global mseclog 1
in der fhem.cfg, damit Zeiten in ms Auflösung im Log erscheinen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 28 Juni 2016, 00:31:52
Hi Ansgar,

hab mich auch schon gewundert über die FW-Nummer...

Aber ich bin (wie letztes mal auch) ins Verzeichnis (also ins neue jetzt ;-)  ) hab dort gebaut ('make') und geflasht ('make program')...

Komisch...

Ich arbeite das mal durch und baue/flashe neu.

Aus der zip-Datei habe ich nur die 00_CUL.pm, die 10_CUL_HM.pm, die HMConfig.pm und die 98_HMinfo.pm getauscht.

Soll/muss ich alle ersetzen, obwohl ich nur HomeMatic nutze?

Wird aber wohl morgen bzw. übermorgen Abend werden...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 28 Juni 2016, 10:47:27
Hi Ansgar,

ich weiß jetzt wo das Problem lag/liegt: zu viele "Käfer" angeschlossen ;-)

Habe noch einen nanoCUL mit eigentlich mySensor...
...der wird sich über die FW des CUL sicher "gefreut" haben...

Ich werde jetzt dann mal den richtigen flashen...
...und mich wieder melden.

Gruß und sorry, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 28 Juni 2016, 11:26:46
Hallo Ansgar,

so ich bin dann mal "zurück gegangen" ;-)

Prinzipiell passt es...
Also es ist ein ATMEGA328P
16MHz
und ein 868MHz-Modul

Habe folgendes angepasst:
/* if you have an Arduino with only 8MHz disable the next line */
#define HAS_16MHZ_CLOCK

...

/* if you are using a cc1101 module for 868MHz disable the next line */
//#define HAS_CC1101_433

...

/* 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;


hier ein list des nanoCUL

Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   NAME       nanoCUL_HM
   NR         43
   PARTIAL
   RAWMSG     AFF71000044C1000C1B865A3229B500000098FA3511
   RSSI       -65.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 21
   nanoCUL_HM_TIME Initialized
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-06-27 21:46:01   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:0.000kHz
     2016-06-28 11:01:16   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-05-06 00:05:19   credit10ms      900
     2016-05-21 08:31:29   hmSioDly        24
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-06-07 22:41:23   scF             1.00020254163391
     2016-06-28 11:03:47   state           Initialized
     2016-06-27 21:46:12   version         V 1.66 nanoCUL868
   Helper:
     Hm:
       FUP        0
       hmCrdts    7
       hmSbusy    0
     Q:
       Cap:
         sum        13500
     Ref:
       ApCUPend   0
       AsPend     0
       IObyterate 3840
       Lhmt       140808
       Lsys       373295708
       Sdly       0
       doNbyterate 8
       hmDstDly   120
       nusew      32
       pTTu       1024
       pingLm     31
       pingMax    30
       pingMin    23
       pingRef    23
       pingtm     373160848
       pingtmBRs  1467104612.72238
       scF        1.00020254163391
       scFN       1
       scHT       5984
       scST       373160871
Attributes:
   hmId       AFFE02
   rfmode     HomeMatic

sieht schon besser aus ;-)

Allerdings leider immer noch NACK beim Pairen...

Hier das list des Klingelsensors:

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     3
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         345
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398B7D d:AFFE02 80
   nanoCUL_HM_MSGCNT 3
   nanoCUL_HM_RAWMSG A0A038002398B7DAFFE0280::-38.5:nanoCUL_HM
   nanoCUL_HM_RSSI -38.5
   nanoCUL_HM_TIME 2016-06-28 11:30:04
   protCmdDel 5
   protLastRcv 2016-06-28 11:30:04
   protNack   1 last_at:2016-06-28 11:30:04
   protSnd    2 last_at:2016-06-28 11:30:04
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-43.16 min:-48 max:-38.5 lst:-38.5 cnt:3
   Readings:
     2016-06-28 11:30:04   CommandAccepted no
     2016-06-28 11:30:04   D-firmware      1.0
     2016-06-28 11:30:04   D-serialNr      MEQ0656892
     2016-06-28 11:30:04   R-pairCentral   set_0xAFFE02
     2016-06-28 11:30:04   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       01AFFE02398B7D00050000000000,01AFFE02398B7D000802010AAF0BFE0C02
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LRcTm      94928
       LRcTmCnt   1
       LSndDlya
       LSndDlyb
       LastRecTyp 02
       lastSend   1467106204.53263
       lastSendtgd 120
       newChn     +398B7D,00,00,00
       nextSend   1467106204.7262
       nextSendMcnt 03
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL_HM -36.5
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A001AFFE02398B7D00050000000000
         ++A001AFFE02398B7D000802010AAF0BFE0C02
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -43.1666666666667
         cnt        3
         lst        -38.5
         max        -38.5
         min        -48
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

und die Logeinträge zum Pairing:

2016.06.28 11:30:04.197 4: CUL_Parse: nanoCUL_HM  006674 A FF71 00094496 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -48
2016.06.28 11:30:04.200 2: CUL_HM Unknown device HM_398B7D is now defined
2016.06.28 11:30:04.210 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.06.28 11:30:04.214 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.06.28 11:30:04.225 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.06.28 11:30:04.235 4: CUL_send:  nanoCUL_HM                         As 10 02 A001 AFFE02 398B7D 00050000000000
2016.06.28 11:30:04.292 4: CUL_Parse: nanoCUL_HM  006778 A FF73 00094568 00 10 02 A001 AFFE02 398B7D  -138
2016.06.28 11:30:04.435 4: CUL_Parse: nanoCUL_HM  006912 A FF71 00094736 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -43
2016.06.28 11:30:04.442 3: CUL_HM set HM_398B7D getConfig
2016.06.28 11:30:04.444 4: CUL_send:  nanoCUL_HM                         As 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.06.28 11:30:04.505 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:48
2016.06.28 11:30:04.506 4: CUL_Parse: nanoCUL_HM  006991 A FF83 00094784 00 13 03 A001 AFFE02 398B7D  -138
2016.06.28 11:30:04.624 4: CUL_Parse: nanoCUL_HM  007109 A FF81 00094928 00 0A 03 8002 398B7D AFFE02 80 -38.5
2016.06.28 11:30:08.153 4: CUL_Parse: nanoCUL_HM  010635 A FF71 00098456 00 0C 92 865A 31D1FE 000000 91072F -54
2016.06.28 11:30:09.501 4: CUL_Parse: nanoCUL_HM  011984 A FF71 00099808 00 0C D2 865A 32185B 000000 60FF33 -46.5
2016.06.28 11:30:12.227 4: CUL_Parse: nanoCUL_HM  014710 A FF71 00102528 00 0F D2 8610 2B8E86 000000 0A98FE0C0040 -68
2016.06.28 11:30:19.756 4: CUL_Parse: nanoCUL_HM  022240 A FF71 00110056 00 0C 26 8470 322927 000000 00FE36 -64.5
2016.06.28 11:30:28.153 4: CUL_Parse: nanoCUL_HM  030635 A FF71 00118456 00 0C 92 8470 31D1FE 000000 01072F -53.5
2016.06.28 11:30:29.501 4: CUL_Parse: nanoCUL_HM  031984 A FF71 00119800 00 0C D2 8470 32185B 000000 00FF33 -46.5
2016.06.28 11:30:30.761 4: CUL_send:  nanoCUL_HM                         Ap AE     
2016.06.28 11:30:30.776 4: CUL_Parse: nanoCUL_HM  033265 A FF72 00121080 00 01 AE -138
2016.06.28 11:30:40.576 4: CUL_send:  nanoCUL_HM                         Ap AA BB CCDD AABBCC DDAABB CCDDAABBCCDDAABBCCDDAA
2016.06.28 11:30:40.612 4: CUL_Parse: nanoCUL_HM  043091 A FF72 00130904 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.06.28 11:31:02.426 4: CUL_Parse: nanoCUL_HM  064908 A FF71 00152720 00 0F 28 8610 2C8BFC 000000 0A90FE0C0040 -69.5
2016.06.28 11:31:06.659 4: CUL_Parse: nanoCUL_HM  069142 A FF71 00156952 00 0C 22 865A 453732 000000 88FE32 -68.5
2016.06.28 11:31:21.264 4: CUL_Parse: nanoCUL_HM  083747 A FF71 00171552 00 0C B7 865A 3227F4 000000 90FD35 -76.5
2016.06.28 11:31:21.793 4: CUL_Parse: nanoCUL_HM  084276 A FF71 00172080 00 0C 3B 8670 2BBF72 000000 00E33C -63.5
2016.06.28 11:31:26.661 4: CUL_Parse: nanoCUL_HM  089143 A FF71 00176952 00 0C 22 8470 453732 000000 00FE32 -68.5
2016.06.28 11:31:30.874 4: CUL_send:  nanoCUL_HM                         Ap AE     
2016.06.28 11:31:30.889 4: CUL_Parse: nanoCUL_HM  093378 A FF72 00181184 00 01 AE -138

Achja, ich habe natürlich weitere HM-Geräte in der Umgebung, die allerdings nicht mit dem Testsystem verbunden sind (siehe Signatur).
Es ist noch ein Wandthermostat verbunden welches prima funktioniert...

Wenn ich noch was tun kann, sag Bescheid...

Wie gesagt mein Problem hat keine hohe Prio, es handelt sich ja um ein Testsystem...
...daher: wenn ich was testen kann (andere Einstellungen etc.), lasse es mich wissen.

Bzw. welche Stellschrauben wären für mich relevant?

Das mit dem Delay habe ich ja schon mal probiert, hat sich da was geändert??

Gruß, Joachim

Achja, fhem läuft mit der richtigen FW auf dem nanoCUL auch zügig hoch ;-)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 29 Juni 2016, 22:08:38
Hallo Joachim,

danke für das Feedback.
Mit der Firmwareversion liegst Du nun richtig. :)

Zitat
Aus der zip-Datei habe ich nur die 00_CUL.pm, die 10_CUL_HM.pm, die HMConfig.pm und die 98_HMinfo.pm getauscht.
DevIo.pm ist auch noch wichtig zu übernehmen.

Du hast das device vorher auch zurück gesetzt? Nicht das es sich weigert, weil es schon mit einer anderen Id gepairt ist?

Das Senden geht noch etwas flot, was vermutlich daran liegt, wie weit der hash für das neu angelegte device schon vorhanden ist und somit dann im Timing Code bei mir überhaupt Timing Infos beim Pairung genutzt werden können.

Ich schau danach.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 29 Juni 2016, 22:23:03
Hi Ansgar,

klar, gerne!
Wenn du dir schon so Mühe gibst.

Ok, werde auch die pm noch kopieren...

Dachte nicht, dass die für HM notwendig ist... ;-)

Ja, Gerät immer brav zurückgesetzt und auch zuvor inkl. log aus fhem gelöscht...

Kann/soll ich was einstellen?

Wenn ich wieder mehr Zeit als nur für's Einspielen und Pairen hab, dann lese ich mal die neuesten Änderungen und versuche herauszufinden was mir davon helfen kann...

Wenn du irgendwas spezifisches getestet haben willst einfach melden...

Bin aber demnächst erst mal ne Woche weg...
...mit ohne Zugriff auf mein System bzw. Hardware...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 30 Juni 2016, 21:25:42
Hi Ansgar,

so jetzt habe ich auch DevIo.pm kopiert.
(ich dachte die Datei heißt DEVLO.pm und daher dachte ich sie hat nix mit "mir" zu tun... Aber die heißt ja DEVIO.pm... eieiei)

Leider startet fhem dann nicht mehr, hier die letzten Logeinträge:

2016.06.30 21:09:00.172 3: Opening zwave_usb device /dev/ttyACM0
2016.06.30 21:09:00.176 3: Setting zwave_usb baudrate to 115200
2016.06.30 21:09:00.181 3: zwave_usb device opened
Undefined subroutine &main::DevIo_IsOpen called at ./FHEM/00_ZWDongle.pm line 542, <$fh> line 550.

Habe dann meinen ZWDongle in der Config deaktiviert, dann geht's wieder...

Habe den Klingelsensor noch mal gelöscht und zurückgesetzt...
...aber leider immer noch NACK...

Hier der Logauszug beim Pairen:

2016.06.30 21:23:01.695 3: CUL_HM set vccu hmPairForSec 60
2016.06.30 21:23:02.020 4: CUL_Parse: nanoCUL_HM  242167 A FF51 00599968 00 0C 81 865A 453732 000000 A90535 -53.5
2016.06.30 21:23:05.873 4: CUL_Parse: nanoCUL_HM  246014 A FF51 00603816 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -48.5
2016.06.30 21:23:05.876 2: CUL_HM Unknown device HM_398B7D is now defined
2016.06.30 21:23:05.887 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.06.30 21:23:05.893 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.06.30 21:23:05.905 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.06.30 21:23:05.916 4: CUL_send:  nanoCUL_HM                         As 10 02 A001 AFFE02 398B7D 00050000000000
2016.06.30 21:23:05.974 4: CUL_Parse: nanoCUL_HM  246123 A FF53 00603896 00 10 02 A001 AFFE02 398B7D  -138
2016.06.30 21:23:06.116 4: CUL_Parse: nanoCUL_HM  246257 A FF51 00604064 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.06.30 21:23:06.123 3: CUL_HM set HM_398B7D getConfig
2016.06.30 21:23:06.125 4: CUL_send:  nanoCUL_HM                         As 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.06.30 21:23:06.186 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D CCAdly:8 dhmSt:48
2016.06.30 21:23:06.187 4: CUL_Parse: nanoCUL_HM  246336 A FF53 00604112 01 13 03 A001 AFFE02 398B7D  -138
2016.06.30 21:23:06.304 4: CUL_Parse: nanoCUL_HM  246453 A FF51 00604256 00 0A 03 8002 398B7D AFFE02 80 -41.5
2016.06.30 21:23:09.796 4: CUL_send:  nanoCUL_HM                         Ap AA BB CCDD AABBCC DDAABB CCDDAABBCCDDAABBCCDDAA
2016.06.30 21:23:09.831 4: CUL_Parse: nanoCUL_HM  249974 A FF52 00607776 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.06.30 21:23:10.780 4: CUL_Parse: nanoCUL_HM  250928 A FF51 00608696 00 0C 8F 8470 31D958 000000 010137 -68.5
2016.06.30 21:23:22.015 4: CUL_Parse: nanoCUL_HM  262162 A FF51 00619960 00 0C 81 8470 453732 000000 010535 -53.5

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 Juli 2016, 00:05:00
Hallo Joachim,

anbei eine neue Version der *.pm s
Geändert ist 00_CUL.pm
und DevIO.pm (danke für den Hinweis auf die fehlende Funktion).

Das Sendetiming wird nun auch besser kontrolliert und gebremst. Auch direkt nach einem Pairing Request.

Ich bin gespannt, ob es was nutzt.
Ich denke aber eher für Dein Klingelsensorproblem, dass es die hier https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045 (https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045) von Oliver schon entdecke Protokollunschärfe seitens Device und dann 10_CUL_HM.pm ist und da müsste Martin was dran tun.

Hier mal ein Pairing Lig eines HM-LC-SW1-BA-PCB ohne Repeater:
2016.06.30 23:17:04.044 4: CUL_Parse: CUL_HM868  268439 A FF81 00071608 00 1A 01 8400 2E1675 000000 16006C4C45513037373138373110410100 -46.5
2016.06.30 23:17:04.305 4: CUL_send:  CUL_HM868                    Aa 2303 10 02 A001 F11034 2E1675 00050000000000
2016.06.30 23:17:04.317 3: CUL_send:  CUL_HM868  id:2E1675 dDly:-199 tgtdly:96 toms:24
2016.06.30 23:17:04.365 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:296
2016.06.30 23:17:04.366 4: CUL_Parse: CUL_HM868  268769 A FF83 00071904 00 10 02 A001 F11034 2E1675  -138
2016.06.30 23:17:04.482 4: CUL_Parse: CUL_HM868  268885 A FF81 00072048 00 0A 02 8002 2E1675 F11034 00 -38
2016.06.30 23:17:04.495 4: CUL_send:  CUL_HM868                    Aa 233A 13 03 A001 F11034 2E1675 000802010AF10B100C34
2016.06.30 23:17:04.506 3: CUL_send:  CUL_HM868  id:2E1675 dDly:54 tgtdly:96 toms:84
2016.06.30 23:17:04.603 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:96
2016.06.30 23:17:04.604 4: CUL_Parse: CUL_HM868  269007 A FF83 00072144 00 13 03 A001 F11034 2E1675  -138
2016.06.30 23:17:04.720 4: CUL_Parse: CUL_HM868  269123 A FF81 00072288 00 0A 03 8002 2E1675 F11034 00 -38
2016.06.30 23:17:04.733 4: CUL_send:  CUL_HM868                    Aa 2358 0B 04 A001 F11034 2E1675 0006
2016.06.30 23:17:04.745 3: CUL_send:  CUL_HM868  id:2E1675 dDly:62 tgtdly:96 toms:90
2016.06.30 23:17:04.840 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:96
2016.06.30 23:17:04.841 4: CUL_Parse: CUL_HM868  269243 A FF83 00072384 00 0B 04 A001 F11034 2E1675  -138
2016.06.30 23:17:04.962 4: CUL_Parse: CUL_HM868  269365 A FF81 00072528 00 0A 04 8002 2E1675 F11034 00 -41.5

und hier mal ein Pairing log mit Repeater (wobei der Repeater nicht den Pairing Request repeated, da nur für direkten Repeat konfiguriert):
2016.06.30 23:31:42.939 4: CUL_Parse: CUL_HM868  098757 A FF81 00087056 00 1A 01 8400 2E1426 000000 16006C4C45513037373132383010410100 -42
2016.06.30 23:31:43.200 4: CUL_send:  CUL_HM868                    Aa 2A8E 10 02 A001 F11034 2E1426 00050000000000
2016.06.30 23:31:43.212 3: CUL_send:  CUL_HM868  id:2E1426 dDly:-202 tgtdly:96 toms:24
2016.06.30 23:31:43.257 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:296
2016.06.30 23:31:43.258 4: CUL_Parse: CUL_HM868  099085 A FF83 00087352 00 10 02 A001 F11034 2E1426  -138
2016.06.30 23:31:43.379 4: CUL_Parse: CUL_HM868  099206 A FF81 00087504 00 0A 02 8002 2E1426 F11034 00 -42
2016.06.30 23:31:43.392 4: CUL_send:  CUL_HM868                    Aa 2AC0 13 03 A001 F11034 2E1426 000802010AF10B100C34
2016.06.30 23:31:43.403 3: CUL_send:  CUL_HM868  id:2E1426 dDly:10 tgtdly:48 toms:40
2016.06.30 23:31:43.456 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:48
2016.06.30 23:31:43.457 4: CUL_Parse: CUL_HM868  099284 A FF83 00087552 00 13 03 A001 F11034 2E1426  -138
2016.06.30 23:31:43.467 4: CUL_Parse: CUL_HM868  099294 A FF81 00087584 00 0A 02 C002 2E1426 F11034 00 rep -34.5
2016.06.30 23:31:43.575 4: CUL_Parse: CUL_HM868  099403 A FF81 00087704 00 0A 03 8002 2E1426 F11034 00 -44.5
2016.06.30 23:31:43.589 4: CUL_send:  CUL_HM868                    Aa 2AD9 0B 04 A001 F11034 2E1426 0006
2016.06.30 23:31:43.600 3: CUL_send:  CUL_HM868  id:2E1426 dDly:14 tgtdly:48 toms:41
2016.06.30 23:31:43.620 4: CUL_Parse: CUL_HM868  099447 A FF81 00087744 00 0A 03 C002 2E1426 F11034 00 rep -35.5
2016.06.30 23:31:43.649 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:48
2016.06.30 23:31:43.650 4: CUL_Parse: CUL_HM868  099477 A FF83 00087752 00 0B 04 A001 F11034 2E1426  -138
2016.06.30 23:31:43.775 4: CUL_Parse: CUL_HM868  099602 A FF81 00087896 00 0A 04 8002 2E1426 F11034 00 -46.5
2016.06.30 23:31:43.820 4: CUL_Parse: CUL_HM868  099647 A FF81 00087944 00 0A 04 C002 2E1426 F11034 00 rep -35

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 03 Juli 2016, 10:42:51
Hi Ansgar,

gerne und danke!

Ich weiß noch nicht, ob ich noch dazu komme, bin die Woche dienstlich mal weg...
...ohne Zugriff auf mein System...

Zitat
Ich bin gespannt, ob es was nutzt.
Ich denke aber eher für Dein Klingelsensorproblem, dass es die hier https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045 von Oliver schon entdecke Protokollunschärfe seitens Device und dann 10_CUL_HM.pm ist und da müsste Martin was dran tun.

Ich auch ;-)
Werde mich dort mal "umsehen"...

Wie gesagt: Testsystem und so die richtige Anwendung für den Klingelsensor habe ich auch noch nicht. Die ursprüngliche Anwendung/Idee (mitbekommen, wenn ich das Licht einschalte per "Parallel-Trafo") scheitert momentan noch, weil die Osram Lightify noch nicht so tut wie ich will... ;-)

Aber wenn ich was testen kann: immer gerne her!

Gruß und danke, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 03 Juli 2016, 10:56:41
Hmmm, hab doch noch schnell kopiert und mal (gelöscht und resetted) und gepaired...
...leider immer noch NACK...

Werde mir den anderen Thread mal ansehen...

Hier ein List des "Kandidaten":

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     3
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         342
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398B7D d:AFFE02 80
   nanoCUL_HM_MSGCNT 3
   nanoCUL_HM_RAWMSG A0A038002398B7DAFFE0280::-34:nanoCUL_HM
   nanoCUL_HM_RSSI -34
   nanoCUL_HM_TIME 2016-07-03 10:51:09
   protCmdDel 5
   protLastRcv 2016-07-03 10:51:09
   protNack   1 last_at:2016-07-03 10:51:09
   protSnd    2 last_at:2016-07-03 10:51:08
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-36.33 min:-38 max:-34 lst:-34 cnt:3
   Readings:
     2016-07-03 10:51:09   CommandAccepted no
     2016-07-03 10:51:08   D-firmware      1.0
     2016-07-03 10:51:08   D-serialNr      MEQ0656892
     2016-07-03 10:51:08   R-pairCentral   set_0xAFFE02
     2016-07-03 10:51:09   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       01AFFE02398B7D00050000000000,01AFFE02398B7D000802010AAF0BFE0C02
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   100000001
       LRcTm      99288
       LRcTmCnt   1
       LSndDlya
       LSndDlyb
       LastRecTyp 02
       lastBurstMCnt
       lastSend   1467535869.00669
       lastSendtgd 96
       newChn     +398B7D,00,00,00
       nextSend   1467535869.24706
       nextSendMcnt 03
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL_HM -32
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A001AFFE02398B7D00050000000000
         ++A001AFFE02398B7D000802010AAF0BFE0C02
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -36.3333333333333
         cnt        3
         lst        -34
         max        -34
         min        -38
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

Und die Logeinträge des Pairings:

2016.07.03 10:51:03.023 3: CUL_HM set vccu hmPairForSec 60
2016.07.03 10:51:07.059 4: CUL_Parse: nanoCUL_HM  277671 A FF71 00097208 00 0C 2F 8470 322927 000000 00F230 -61.5
2016.07.03 10:51:08.654 4: CUL_Parse: nanoCUL_HM  279257 A FF71 00098792 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -38
2016.07.03 10:51:08.659 2: CUL_HM Unknown device HM_398B7D is now defined
2016.07.03 10:51:08.675 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.07.03 10:51:08.681 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.07.03 10:51:08.696 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.07.03 10:51:08.709 4: CUL_send:  nanoCUL_HM                    Aa 3049 10 02 A001 AFFE02 398B7D 00050000000000
2016.07.03 10:51:08.720 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:7 tgtdly:96 toms:0
2016.07.03 10:51:08.767 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:96
2016.07.03 10:51:08.768 4: CUL_Parse: nanoCUL_HM  279380 A FF73 00098888 00 10 02 A001 AFFE02 398B7D  -138
2016.07.03 10:51:08.911 4: CUL_Parse: nanoCUL_HM  279516 A FF71 00099048 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -37
2016.07.03 10:51:08.919 3: CUL_HM set HM_398B7D getConfig
2016.07.03 10:51:08.921 4: CUL_send:  nanoCUL_HM                    Aa 3069 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.07.03 10:51:08.932 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:48 tgtdly:96 toms:22
2016.07.03 10:51:09.025 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:96
2016.07.03 10:51:09.026 4: CUL_Parse: nanoCUL_HM  279639 A FF73 00099144 00 13 03 A001 AFFE02 398B7D  -138
2016.07.03 10:51:09.144 4: CUL_Parse: nanoCUL_HM  279757 A FF71 00099288 00 0A 03 8002 398B7D AFFE02 80 -34
2016.07.03 10:51:09.437 4: CUL_Parse: nanoCUL_HM  280049 A FF71 00099584 00 0C 98 8470 31D1FE 000000 010B35 -51
2016.07.03 10:51:18.417 4: CUL_Parse: nanoCUL_HM  289029 A FF71 00108560 00 0C CC 865A 3227F4 000000 90F82A -71
2016.07.03 10:51:28.421 4: CUL_Parse: nanoCUL_HM  299031 A FF71 00118560 00 0E 11 8410 3227F4 000000 0B90F80E40 -72.5
2016.07.03 10:51:30.588 4: CUL_send:  nanoCUL_HM                         Ap AE     
2016.07.03 10:51:30.603 4: CUL_Parse: nanoCUL_HM  301221 A FF72 00120752 00 01 AE -138
2016.07.03 10:51:32.727 4: CUL_Parse: nanoCUL_HM  303337 A FF71 00122864 00 0F EA 8610 2B8E86 000000 0A98F30C0040 -70
2016.07.03 10:51:34.422 4: CUL_Parse: nanoCUL_HM  305032 A FF71 00124560 00 0F 3D 8610 2C8BFC 000000 0A90FE0C0040 -69.5
2016.07.03 10:51:38.418 4: CUL_Parse: nanoCUL_HM  309029 A FF71 00128560 00 0C CC 8470 3227F4 000000 00F82A -71.5
2016.07.03 10:51:39.165 4: CUL_Parse: nanoCUL_HM  309775 A FF71 00129304 00 0F F5 8610 2D9B77 000000 0A60DB0C0040 -67.5
2016.07.03 10:51:40.742 4: CUL_send:  nanoCUL_HM                         Ap AA BB CCDD AABBCC DDAABB CCDDAABBCCDDAABBCCDDAA
2016.07.03 10:51:40.778 4: CUL_Parse: nanoCUL_HM  311385 A FF72 00130912 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.07.03 10:51:52.983 4: CUL_Parse: nanoCUL_HM  323590 A FF71 00143112 00 14 36 845E 4A347F 000000 800DD50000000000091001 -64
2016.07.03 10:52:17.117 4: CUL_Parse: nanoCUL_HM  347729 A FF71 00167248 00 0C 49 8670 2BBF72 000000 00D039 -66.5
2016.07.03 10:52:18.513 4: CUL_Parse: nanoCUL_HM  349124 A FF71 00168648 00 0C 36 865A 453732 000000 A8F02C -71.5
2016.07.03 10:52:24.094 4: CUL_Parse: nanoCUL_HM  354704 A FF71 00174224 00 0C 41 865A 31D958 000000 90FE34 -70
2016.07.03 10:52:28.516 4: CUL_Parse: nanoCUL_HM  359126 A FF71 00178648 00 0E 40 8410 453732 000000 0BA8F00E00 -72.5
2016.07.03 10:52:30.701 4: CUL_send:  nanoCUL_HM                         Ap AE     
2016.07.03 10:52:30.716 4: CUL_Parse: nanoCUL_HM  361334 A FF72 00180848 00 01 AE -138
2016.07.03 10:52:38.514 4: CUL_Parse: nanoCUL_HM  369125 A FF71 00188640 00 0C 36 8470 453732 000000 00F02C -71.5
2016.07.03 10:52:44.097 4: CUL_Parse: nanoCUL_HM  374708 A FF71 00194216 00 0C 41 8470 31D958 000000 00FE34 -69.5
2016.07.03 10:52:49.006 4: CUL_Parse: nanoCUL_HM  379617 A FF71 00199128 00 0C 36 865A 3229B5 000000 60DB2C -65.5
2016.07.03 10:52:55.294 4: CUL_Parse: nanoCUL_HM  385905 A FF71 00205416 00 0C 81 865A 32279A 000000 98F32C -65
2016.07.03 10:52:56.661 4: CUL_Parse: nanoCUL_HM  387271 A FF71 00206784 00 0F 8B 8610 2BA56B 000000 0A60F20B0040 -56
2016.07.03 10:52:58.442 4: CUL_Parse: nanoCUL_HM  389053 A FF71 00208568 00 0C DB 865A 32185B 000000 60F42B -48
2016.07.03 10:53:09.006 4: CUL_Parse: nanoCUL_HM  399617 A FF71 00219128 00 0C 36 8470 3229B5 000000 00DB2C -65
2016.07.03 10:53:15.293 4: CUL_Parse: nanoCUL_HM  405904 A FF71 00225416 00 0C 81 8470 32279A 000000 00F32C -66
2016.07.03 10:53:18.441 4: CUL_Parse: nanoCUL_HM  409053 A FF71 00228560 00 0C DB 8470 32185B 000000 00F42B -47.5
2016.07.03 10:53:24.188 4: CUL_Parse: nanoCUL_HM  414799 A FF71 00234304 00 0C 99 865A 31D1FE 000000 910B35 -51

So, jetzt muss ich aber los...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 Juli 2016, 21:23:50
Hallo Joachim, hallo Martin und Testwillige,

hier eine neue Version der *.pm s.

00_CUL.pm, 10_CUL_HM.pm und 16_STACKABLE_CC.pm sind geändert.

Es gibt Änderung hinsichtlich der Verwaltung der Zeitinfos, um Überschneidungsprobleme zu vermeiden. Außerdem wir der erste Empfang eines unbekannten Devices nun mit Timestamp gehandelt.

Für das Pairing habe ich nun ein extra Delay für den Pairing Request "00050000000000" eingführt.
Per Default versucht er, 300ms delay zum Empfang des Status einzuhalten. Mit dem Device Attribut "hmPairAddDly" kann man die Zeit verändern. Es ist als Zusatz zu den Default 120ms Verzögerung zu verstehen. Ein Wert von 180 führt zu den 300ms.

@Joachim: Versuch es bitte damit nochmal mit Deinem Klingelsensor. Wenn das Timing mit ~300ms das Problem umschifft, wie es Olivers Logs von HMLAN anscheinend zeigen, dann hilft es hoffentlich. Oder besser: würde das eigentliche Problem umschiffen.

Wie immer die Warnung, erst Backups der auszutauschenden Dateien, dann erst überschreiben.

Hier nochmal Logs von meinen HM-LC-SW1-BA-PCB. Mit den knapp 300ms funktioniert es bei denen auch.

Mit Repeater:
2016.07.03 20:37:30.871 4: CUL_Parse: CUL_HM868  334177 A FF71 00278680 00 1A 01 8400 2E1426 000000 16006C4C45513037373132383010410100 -39.5
2016.07.03 20:37:31.007 4: CUL_send:  CUL_HM868                    Aa 8838 10 02 A001 F11034 2E1426 00050000000000
2016.07.03 20:37:31.019 3: CUL_send:  CUL_HM868  id:2E1426 dDly:-66 tgtdly:300 toms:17
2016.07.03 20:37:31.187 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:296 dHMtgt:296
2016.07.03 20:37:31.188 4: CUL_Parse: CUL_HM868  334502 A FF73 00278976 00 10 02 A001 F11034 2E1426  -138
2016.07.03 20:37:31.234 4: CUL_Parse: CUL_HM868  334545 A FF71 00279048 00 10 02 E001 F11034 2E1426 00050000000000 rep ign -39
2016.07.03 20:37:31.309 4: CUL_Parse: CUL_HM868  334624 A FF71 00279120 00 0A 02 8002 2E1426 F11034 00 -39
2016.07.03 20:37:31.325 4: CUL_send:  CUL_HM868                    Aa 8851 13 03 A001 F11034 2E1426 000802010AF10B100C34
2016.07.03 20:37:31.336 3: CUL_send:  CUL_HM868  id:2E1426 dDly:12 tgtdly:60 toms:28
2016.07.03 20:37:31.355 4: CUL_Parse: CUL_HM868  334669 A FF71 00279168 00 0A 02 C002 2E1426 F11034 00 rep -42.5
2016.07.03 20:37:31.391 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:56 dHMtgt:56
2016.07.03 20:37:31.392 4: CUL_Parse: CUL_HM868  334706 A FF73 00279176 00 13 03 A001 F11034 2E1426  -138
2016.07.03 20:37:31.440 4: CUL_Parse: CUL_HM868  334750 A FF71 00279248 00 13 03 E001 F11034 2E1426 000802010AF10B100C34 rep ign -39
2016.07.03 20:37:31.511 4: CUL_Parse: CUL_HM868  334825 A FF71 00279320 00 0A 03 8002 2E1426 F11034 00 -39.5
2016.07.03 20:37:31.526 4: CUL_send:  CUL_HM868                    Aa 886A 0B 04 A001 F11034 2E1426 0006
2016.07.03 20:37:31.538 3: CUL_send:  CUL_HM868  id:2E1426 dDly:17 tgtdly:60 toms:31
2016.07.03 20:37:31.556 4: CUL_Parse: CUL_HM868  334870 A FF71 00279368 00 0A 03 C002 2E1426 F11034 00 rep -43
2016.07.03 20:37:31.585 3: CUL_ParseTsHM: CUL_HM868  id:2E1426 dhmSt:56 dHMtgt:56
2016.07.03 20:37:31.586 4: CUL_Parse: CUL_HM868  334900 A FF73 00279376 00 0B 04 A001 F11034 2E1426  -138
2016.07.03 20:37:31.629 4: CUL_Parse: CUL_HM868  334943 A FF71 00279440 00 0B 04 E001 F11034 2E1426 0006 rep ign -39.5
2016.07.03 20:37:31.712 4: CUL_Parse: CUL_HM868  335026 A FF71 00279520 00 0A 04 8002 2E1426 F11034 00 -39
2016.07.03 20:37:31.756 4: CUL_Parse: CUL_HM868  335071 A FF71 00279568 00 0A 04 C002 2E1426 F11034 00 rep -43

ohne Repeater:
2016.07.03 20:38:41.746 4: CUL_Parse: CUL_HM868  405052 A FF61 00349168 00 1A 03 8400 2E1675 000000 16006C4C45513037373138373110410100 -53
2016.07.03 20:38:41.861 4: CUL_send:  CUL_HM868                    Aa AAA3 10 04 A001 F11034 2E1675 00050000000000
2016.07.03 20:38:41.873 3: CUL_send:  CUL_HM868  id:2E1675 dDly:-43 tgtdly:300 toms:17
2016.07.03 20:38:42.064 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:296 dHMtgt:296
2016.07.03 20:38:42.065 4: CUL_Parse: CUL_HM868  405379 A FF73 00349464 00 10 04 A001 F11034 2E1675  -138
2016.07.03 20:38:42.184 4: CUL_Parse: CUL_HM868  405498 A FF71 00349608 00 0A 04 8002 2E1675 F11034 00 -48
2016.07.03 20:38:42.200 4: CUL_send:  CUL_HM868                    Aa AAC2 13 05 A001 F11034 2E1675 000802010AF10B100C34
2016.07.03 20:38:42.211 3: CUL_send:  CUL_HM868  id:2E1675 dDly:58 tgtdly:104 toms:74
2016.07.03 20:38:42.316 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:104 dHMtgt:104
2016.07.03 20:38:42.317 4: CUL_Parse: CUL_HM868  405631 A FF73 00349712 00 13 05 A001 F11034 2E1675  -138
2016.07.03 20:38:42.433 4: CUL_Parse: CUL_HM868  405748 A FF71 00349856 00 0A 05 8002 2E1675 F11034 00 -41.5
2016.07.03 20:38:42.450 4: CUL_send:  CUL_HM868                    Aa AAE1 0B 06 A001 F11034 2E1675 0006
2016.07.03 20:38:42.462 3: CUL_send:  CUL_HM868  id:2E1675 dDly:61 tgtdly:104 toms:74
2016.07.03 20:38:42.559 3: CUL_ParseTsHM: CUL_HM868  id:2E1675 dhmSt:104 dHMtgt:104
2016.07.03 20:38:42.560 4: CUL_Parse: CUL_HM868  405874 A FF73 00349960 00 0B 06 A001 F11034 2E1675  -138
2016.07.03 20:38:42.683 4: CUL_Parse: CUL_HM868  405997 A FF71 00350104 00 0A 06 8002 2E1675 F11034 00 -38

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 03 Juli 2016, 21:36:43
Hi Ansgar,

vielen Dank!

Leider komme ich frühestens am WE dazu...
...werde ich aber dann gleich mal testen...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 08 Juli 2016, 22:51:35
Hallo Zusammen!

Ich gehöre auch zu den Glücklichen, welche den Klingelsensor i.v.m einem NanoCUL ihr eigen nennen dürfen.
Bisher lief auch alles ohne Probleme, sämtliche HM-Sensoren / Aktoren ließen sich problemlos pairen.
Aber dieser Klingelsensor macht mich fertig... Entweder NACK oder Register Dead

Also, ich habe deine FW drauf:

VERSION V 99.78 nanoCUL868
Auch habe ich deine Module aus "FHEM_module_changed_4.zip" ersetzt.


Ein List des nanoCUL

Internals:
   CMDS       ABCEFGKMRTUVWXYZeflmtx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         10
   FHTID      1234
   NAME       nanoCUL
   NR         30
   PARTIAL
   RAWMSG     AFF41000160E1001478845E2B2BFE0000008038FD0000000000091AFEF2
   RSSI       -81
   STATE      Initialized
   TYPE       CUL
   VERSION    V 99.78 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   initString X21
Ar
At1
   nanoCUL_MSGCNT 41
   nanoCUL_TIME Initialized
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-07-08 20:51:24   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
     2016-07-08 22:33:38   cmds             A B C E F G K M R T U V W X Y Z e f l m t x
     2016-07-08 22:39:15   hmSioDly        24
     2016-07-08 22:08:13   raw             No answer
     2016-07-08 22:07:17   scF             0.99900149775337
     2016-07-08 22:45:39   state           Initialized
     2016-07-08 22:07:55   uptime          0 00:01:44
   Helper:
     33c508:
       QUEUE:
     398be6:
       QUEUE:
     4c16fd:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    4
       hmSbusy    0
     Q:
       Cap:
         sum        27000
     Ref:
       ApCUPend   0
       AsPend     0
       Lhmt       692832
       Lsys       205636642
       Sdly       2
       dwoCCAAa   104
       dwoCCAAw   104
       nusew      15
       pTTu       1024
       pingMax    1
       pingMin    1
       pingRef    1
       pingdly    1
       pinglm     9
       pingtm     204952326
       scF        0.99900149775337
       scFN       1
       scHT       7848
       scST       204952327
       tgtdly     104
Attributes:
   hmId       2703CC
   rfmode     HomeMatic
   verbose    4

Ein List des HM-Sen-DB-PCB

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     3
   NAME       HM_398BE6
   NR         125
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398BE6 d:2703CC 80
   nanoCUL_MSGCNT 3
   nanoCUL_RAWMSG A0A038002398BE62703CC80::-63:nanoCUL
   nanoCUL_RSSI -63
   nanoCUL_TIME 2016-07-08 22:39:15
   protCmdDel 5
   protLastRcv 2016-07-08 22:39:15
   protNack   1 last_at:2016-07-08 22:39:15
   protSnd    2 last_at:2016-07-08 22:39:15
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL avg:-64.83 min:-70.5 max:-61 lst:-63 cnt:3
   Readings:
     2016-07-08 22:39:15   CommandAccepted no
     2016-07-08 22:39:15   D-firmware      1.0
     2016-07-08 22:39:15   D-serialNr      MEQ0656787
     2016-07-08 22:39:14   R-pairCentral   set_0x2703CC
     2016-07-08 22:39:15   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       012703CC398BE600050000000000,012703CC398BE6000802010A270B030CCC
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LRcTm      337912
       LRcTmCnt   1
       LSndDlya
       LSndDlyb
       newChn     +398BE6,00,00,00
       nextSend   1468010355.58508
       nextSendLRmsg A0A038002398BE62703CC80
       prefIO
       rxt        0
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL    -61
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A0012703CC398BE600050000000000
         ++A0012703CC398BE6000802010A270B030CCC
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -64.8333333333333
         cnt        3
         lst        -63
         max        -61
         min        -70.5
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton

Und zu guter letzt, das Log vom pairen mit verbose 4:

2016.07.08 23:15:02.537 4 : CUL_Parse: nanoCUL 335350 A FF61 00319152 00 1A 01 8400 398BE6 000000 1000DC4D45513036353637383740010101 -67
2016.07.08 23:15:02.537 2 : CUL_HM Unknown device HM_398BE6 is now defined
2016.07.08 23:15:02.538 2 : autocreate: define HM_398BE6 CUL_HM 398BE6
2016.07.08 23:15:02.540 2 : autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016-07-08 23:15:02.553 Global global UNDEFINED HM_398BE6 CUL_HM 398BE6
2016-07-08 23:15:02.553 Global global DEFINED HM_398BE6
2016-07-08 23:15:02.553 Global global DEFINED FileLog_HM_398BE6
2016-07-08 23:15:02.553 Global global SAVE
2016.07.08 23:15:02.555 3 : CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.07.08 23:15:02.558 4 : CUL_send: nanoCUL Aa 9BFC 10 02 A001 2703CC 398BE6 00050000000000
2016.07.08 23:15:02.568 3 : CUL_send: nanoCUL id:398BE6 dDly:44 tgtdly:300 toms:9
2016-07-08 23:15:02.572 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-08 23:15:02.572 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.08 23:15:02.862 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:304 dHMtgt:304
2016.07.08 23:15:02.862 4 : CUL_Parse: nanoCUL 335680 A FF63 00319456 00 10 02 A001 2703CC 398BE6 00050000000000 -138
2016.07.08 23:15:03.002 4 : CUL_Parse: nanoCUL 335815 A FF61 00319616 00 1A 02 8400 398BE6 000000 1000DC4D45513036353637383740010101 -70.5
2016.07.08 23:15:03.005 3 : CUL_HM set HM_398BE6 getConfig
2016.07.08 23:15:03.007 4 : CUL_send: nanoCUL Aa 9C1C 13 03 A001 2703CC 398BE6 000802010A270B030CCC
2016.07.08 23:15:03.017 3 : CUL_send: nanoCUL id:398BE6 dDly:60 tgtdly:98 toms:25
2016-07-08 23:15:03.021 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-08 23:15:03.021 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.08 23:15:03.122 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:96 dHMtgt:96
2016.07.08 23:15:03.123 4 : CUL_Parse: nanoCUL 335939 A FF63 00319712 00 13 03 A001 2703CC 398BE6 000802010A270B030CCC -138
2016.07.08 23:15:03.236 4 : CUL_Parse: nanoCUL 336057 A FF61 00319856 00 0A 03 8002 398BE6 2703CC 80 -71
2016-07-08 23:15:03.242 CUL_HM HM_398BE6 NACK
2016-07-08 23:15:03.242 CUL_HM HM_398BE6 Nack


Auch wenn weitere Infos gewünscht sind, immer raus damit.

Ich danke dir im Voraus.

Lieben Gruß Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juli 2016, 09:30:15
Hallo Chris, hallo Joachim,

versucht's bitte nochmal mit der angehängten 10_CUL_HM.pm.

Ich habe darin die Commando Nummer geändert, wie HM_LAN das zu tun scheint.
Das Pairing klappt damit mit meinem HM-LC-SW1-BA-PCB.

Die Änderung der Nummer vermeidet hoffentlich den Protokollkonflikt mit der "Quatsch"-Antort oder bringt uns etwas weiter, denke ich.
Ich hoffe, das knackt das das Problem mit dem HM-Sen-DB-PCB.

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 Juli 2016, 10:24:13
Hallo Ansgar.

Ich habe die 10_CUL_HM.pm ersetzt, alles was den Klingelsensor angeht gelöscht (Log und Device), dann shudtdown restart durchgeführt.

Dann den Sensor auf Werksreset, nanoCUL in pairingmodus versetzt, Klingelsensor angelernt.

Nun statt NACK ein Missing ACK und Resnd Fail. Eventuell findest du ja was in den Logs was dir weiterhilft.



Das Log mit verbose 4 (inkl Event Montior)

2016.07.09 10:27:51.013 4 : CUL_Parse: nanoCUL 333650 A FF81 00013840 00 1A 07 8400 398BE6 000000 1000DC4D45513036353637383740010101 -71.5
2016.07.09 10:27:51.050 2 : CUL_HM Unknown device HM_398BE6 is now defined
2016.07.09 10:27:51.213 2 : autocreate: define HM_398BE6 CUL_HM 398BE6
2016.07.09 10:27:51.215 2 : autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016-07-09 10:27:51.233 Global global UNDEFINED HM_398BE6 CUL_HM 398BE6
2016-07-09 10:27:51.233 Global global DEFINED HM_398BE6
2016-07-09 10:27:51.233 Global global DEFINED FileLog_HM_398BE6
2016-07-09 10:27:51.233 Global global SAVE
2016.07.09 10:27:51.237 3 : CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.07.09 10:27:51.241 4 : CUL_send: nanoCUL Aa 06E8 10 2F A001 2703CC 398BE6 00050000000000
2016.07.09 10:27:51.252 3 : CUL_send: nanoCUL id:398BE6 dDly:-160 tgtdly:300 toms:9
2016-07-09 10:27:51.257 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-09 10:27:51.257 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.09 10:27:51.336 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:304 dHMtgt:304
2016-07-09 10:27:55.026 CUL_HM HM_398BE6 ResndFail
2016-07-09 10:27:55.028 CUL_HM HM_398BE6 MISSING ACK


und nochmal das List vom Klingelsensor:

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     2
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         80
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:08 - t:00 s:398BE6 d:000000 1000DC4D45513036353637383740010101
   nanoCUL_MSGCNT 2
   nanoCUL_RAWMSG A1A088400398BE60000001000DC4D45513036353637383740010101::-71.5:nanoCUL
   nanoCUL_RSSI -71.5
   nanoCUL_TIME 2016-07-09 10:27:51
   protCmdDel 6
   protLastRcv 2016-07-09 10:27:51
   protResndFail 1 last_at:2016-07-09 10:27:55
   protSnd    1 last_at:2016-07-09 10:27:51
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL avg:-71.5 min:-71.5 max:-71.5 lst:-71.5 cnt:2
   Readings:
     2016-07-09 10:27:51   D-firmware      1.0
     2016-07-09 10:27:51   D-serialNr      MEQ0656787
     2016-07-09 10:27:51   R-pairCentral   set_0x2703CC
     2016-07-09 10:27:55   state           MISSING ACK
   Helper:
     HM_CMDNR   8
     cSnd       ,012703CC398BE600050000000000
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   1
       LRcTm      14304
       LastRecTyp 00
       lastSendtgd 304
       newChn     +398BE6,00,00,00
       nextSend   1468052871.57559
       nextSendMcnt 08
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        08
       Io:
         nanoCUL    -69.5
     Prt:
       bErr       0
       mmcS       1
       sProc      0
       mmcA:
         ++A0012703CC398BE600050000000000
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -71.5
         cnt        2
         lst        -71.5
         max        -71.5
         min        -71.5
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton


Ich danke dir nochmal für deine Mühen. Eventuell testet Joachim parallel deine Version und kann auch Informationen dazu beitragen.

Lieben gruß Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juli 2016, 10:49:33
Hallo Chris,

versuch bitte nochmal zu pairen und schick mir bitte etwas mehr vom Log.
Die Sendequittung von CUL ist leider nicht mehr zu sehen, so dass die Sendetiminginfo zu "00050000000000" fehlt und der Rest bis zum ResndFail.

Oder hat CUL eventuell gar nicht gesendet?

Andererseits ist im Device HM_CMDNR   8 zu sehen, was andeutet, dass die Wiederholung empfangen wurde und damit wegen falscher Comandonummer weiteres durcheinander gekommen ist. Sprich, das müsste eventuell auch noch unterdrückt werden.

Die Comando Nummer von 07 vom Klingelsensir irritiert mich auch etwas? 01 hätte ich erwartet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 Juli 2016, 11:43:28
Hallo Ansgar,

hier noch mal mehr vom Log. Nicht wundern, da hängt noch der ein oder andere Verbraucher mit im Log ;)

2016-07-09 11:49:06.230 CUL nanoCUL hmPairForSec 60
2016.07.09 11:49:08.563 4 : CUL_Parse: nanoCUL 492611 A FF81 00020600 00 14 15 A45F 33C508 2703CC 864A9A0061BC049608D4FD -71
2016.07.09 11:49:08.566 4 : CUL_send: nanoCUL Aa 0A1E 0A 15 8002 2703CC 33C508 00
2016.07.09 11:49:08.577 3 : CUL_send: nanoCUL id:33C508 dDly:91 tgtdly:120 toms:98
2016-07-09 11:49:08.584 CUL_HM HM_33C508 CMDs_done
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr current: 1174
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr eState: E: 41231.4 P: 250.2 I: 1174 U: 226 f: 49.97
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr energy: 41231.4
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr energyCalc: 86226.3
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr frequency: 49.97
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr power: 250.2
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr 41231.4
2016-07-09 11:49:08.586 CUL_HM HM_33C508_Pwr voltage: 226
2016-07-09 11:49:08.587 CUL_HM HM_33C508_SenF 49.97
2016-07-09 11:49:08.588 CUL_HM HM_33C508_SenI 1174
2016-07-09 11:49:08.589 CUL_HM HM_33C508_SenU 226
2016-07-09 11:49:08.590 CUL_HM Leistung 250.2
2016.07.09 11:49:08.695 3 : CUL_ParseTsHM: nanoCUL id:33C508 dhmSt:120 dHMtgt:120
2016.07.09 11:49:08.696 4 : CUL_Parse: nanoCUL 492749 A FF83 00020720 00 0A 15 8002 2703CC 33C508 00 -138
2016-07-09 11:49:10.907 dummy AktuellerVerbrauchPC 250.2
2016-07-09 11:49:10.910 at WattUsageAnDummy Next: 11:49:15
2016.07.09 11:49:15.420 4 : CUL_Parse: nanoCUL 499465 A FF81 00027464 00 1A 01 8400 398BE6 000000 1000DC4D45513036353637383740010101 -67.5
2016.07.09 11:49:15.421 2 : CUL_HM Unknown device HM_398BE6 is now defined
2016.07.09 11:49:15.422 2 : autocreate: define HM_398BE6 CUL_HM 398BE6
2016.07.09 11:49:15.424 2 : autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016-07-09 11:49:15.442 Global global UNDEFINED HM_398BE6 CUL_HM 398BE6
2016-07-09 11:49:15.442 Global global DEFINED HM_398BE6
2016-07-09 11:49:15.442 Global global DEFINED FileLog_HM_398BE6
2016-07-09 11:49:15.442 Global global SAVE
2016.07.09 11:49:15.445 3 : CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.07.09 11:49:15.449 4 : CUL_send: nanoCUL Aa 0D8F 10 29 A001 2703CC 398BE6 00050000000000
2016.07.09 11:49:15.460 3 : CUL_send: nanoCUL id:398BE6 dDly:38 tgtdly:300 toms:46
2016-07-09 11:49:15.465 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-09 11:49:15.465 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.09 11:49:15.745 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:304 dHMtgt:304
2016.07.09 11:49:15.745 4 : CUL_Parse: nanoCUL 499795 A FF83 00027768 00 10 29 A001 2703CC 398BE6 00050000000000 -138
2016.07.09 11:49:15.883 4 : CUL_Parse: nanoCUL 499928 A FF81 00027928 00 1A 02 8400 398BE6 000000 1000DC4D45513036353637383740010101 -64
2016.07.09 11:49:15.887 3 : CUL_HM set HM_398BE6 getConfig
2016-07-09 11:49:15.890 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-09 11:49:15.890 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016-07-09 11:49:15.907 at WattUsageAnDummy Next: 11:49:20
2016-07-09 11:49:18.344 CUL_HM HM_398BE6 ResndFail
2016-07-09 11:49:18.346 CUL_HM HM_398BE6 MISSING ACK
2016-07-09 11:49:20.908 at WattUsageAnDummy Next: 11:49:25
2016-07-09 11:49:25.908 at WattUsageAnDummy Next: 11:49:30
2016-07-09 11:49:30.908 at WattUsageAnDummy Next: 11:49:35
2016-07-09 11:49:35.908 at WattUsageAnDummy Next: 11:49:40
2016-07-09 11:49:40.908 at WattUsageAnDummy Next: 11:49:45
2016.07.09 11:49:41.804 4 : CUL_Parse: nanoCUL 001564 A FF81 00053880 00 14 16 A45F 33C508 2703CC 864AB1006B4004FD08DFFE -71.5
2016.07.09 11:49:41.807 4 : CUL_send: nanoCUL Aw 0B 0A 16 8002 2703CC 33C508 00
2016.07.09 11:49:41.849 3 : CUL_send: nanoCUL id:33C508 dDly:93 tgtdly:120 toms:97
2016-07-09 11:49:41.854 CUL_HM HM_33C508 CMDs_done
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr current: 1277
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr eState: E: 41233.7 P: 274.56 I: 1277 U: 227.1 f: 49.98
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr energy: 41233.7
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr energyCalc: 86228.6
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr frequency: 49.98
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr power: 274.56
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr 41233.7
2016-07-09 11:49:41.857 CUL_HM HM_33C508_Pwr voltage: 227.1
2016-07-09 11:49:41.858 CUL_HM HM_33C508_SenF 49.98
2016-07-09 11:49:41.859 CUL_HM HM_33C508_SenI 1277
2016-07-09 11:49:41.860 CUL_HM HM_33C508_SenU 227.1
2016-07-09 11:49:41.862 CUL_HM Leistung 274.56
2016.07.09 11:49:41.967 3 : CUL_ParseTsHM: nanoCUL id:33C508 dhmSt:144 dHMtgt:120 hmSioDly:3
2016.07.09 11:49:41.967 4 : CUL_Parse: nanoCUL 001731 A FF83 00054024 00 0A 16 8002 2703CC 33C508 00 -138
2016-07-09 11:49:45.907 dummy AktuellerVerbrauchPC 274.56
2016-07-09 11:49:45.910 at WattUsageAnDummy Next: 11:49:50
2016.07.09 11:49:49.564 4 : CUL_Parse: nanoCUL 009324 A FF81 00061648 00 14 17 A45F 33C508 2703CC 864AB600637004A508E0FE -71.5
2016.07.09 11:49:49.568 4 : CUL_send: nanoCUL Aw 0B 0A 17 8002 2703CC 33C508 00
2016.07.09 11:49:49.578 3 : CUL_send: nanoCUL id:33C508 dDly:93 tgtdly:120 toms:96
2016-07-09 11:49:49.583 CUL_HM HM_33C508 CMDs_done
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr current: 1189
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr eState: E: 41234.2 P: 254.56 I: 1189 U: 227.2 f: 49.98
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr energy: 41234.2
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr energyCalc: 86229.1
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr frequency: 49.98
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr power: 254.56
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr 41234.2
2016-07-09 11:49:49.585 CUL_HM HM_33C508_Pwr voltage: 227.2
2016-07-09 11:49:49.587 CUL_HM HM_33C508_SenF 49.98
2016-07-09 11:49:49.588 CUL_HM HM_33C508_SenI 1189
2016-07-09 11:49:49.589 CUL_HM HM_33C508_SenU 227.2
2016-07-09 11:49:49.590 CUL_HM Leistung 254.56
2016.07.09 11:49:49.695 3 : CUL_ParseTsHM: nanoCUL id:33C508 dhmSt:112 dHMtgt:120 hmSioDly:1
2016.07.09 11:49:49.695 4 : CUL_Parse: nanoCUL 009460 A FF83 00061760 00 0A 17 8002 2703CC 33C508 00 -138
2016-07-09 11:49:50.908 dummy AktuellerVerbrauchPC 254.56
2016-07-09 11:49:50.910 at WattUsageAnDummy Next: 11:49:55
2016.07.09 11:49:51.305 4 : CUL_Parse: nanoCUL 011064 A FF81 00063384 00 14 E1 845E 33C508 000000 864AB7005FB2047A08DCFE -72
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr current: 1146
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr eState: E: 41234.3 P: 244.98 I: 1146 U: 226.8 f: 49.98
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr energy: 41234.3
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr energyCalc: 86229.2
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr frequency: 49.98
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr power: 244.98
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr 41234.3
2016-07-09 11:49:51.312 CUL_HM HM_33C508_Pwr voltage: 226.8
2016-07-09 11:49:51.313 CUL_HM HM_33C508_SenF 49.98
2016-07-09 11:49:51.314 CUL_HM HM_33C508_SenI 1146
2016-07-09 11:49:51.315 CUL_HM HM_33C508_SenU 226.8
2016-07-09 11:49:51.316 CUL_HM Leistung 244.98
2016-07-09 11:49:55.907 dummy AktuellerVerbrauchPC 244.98
2016-07-09 11:49:55.910 at WattUsageAnDummy Next: 11:50:00
2016-07-09 11:50:00.908 at WattUsageAnDummy Next: 11:50:05
2016-07-09 11:50:05.908 at WattUsageAnDummy Next: 11:50:10
2016-07-09 11:50:10.908 at WattUsageAnDummy Next: 11:50:15
2016-07-09 11:50:15.908 at WattUsageAnDummy Next: 11:50:20
2016-07-09 11:50:20.908 at WattUsageAnDummy Next: 11:50:25
2016-07-09 11:50:25.908 at WattUsageAnDummy Next: 11:50:30
2016-07-09 11:50:30.908 at WattUsageAnDummy Next: 11:50:35
2016.07.09 11:50:32.414 4 : CUL_Parse: nanoCUL 052174 A FF71 00104536 00 14 AE 845E 2B2BFE 000000 8038FD000000000008F5FE -81
2016-07-09 11:50:32.421 CUL_HM HM_2B2BFE_SenF 49.98
2016-07-09 11:50:32.422 CUL_HM HM_2B2BFE_SenI 0
2016-07-09 11:50:32.423 CUL_HM HM_2B2BFE_SenPwr 0
2016-07-09 11:50:32.424 CUL_HM HM_2B2BFE_SenU 229.3
2016-07-09 11:50:32.431 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.434 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.438 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.441 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.444 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.448 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.451 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.454 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.457 dummy HR.WaschmaschineWatt 0
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power boot: off
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power current: 0
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power eState: E: 1458.9 P: 0 I: 0 U: 229.3 f: 49.98
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power energy: 1458.9
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power energyCalc: 2705.5
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power frequency: 49.98
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power power: 0
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power 1458.9
2016-07-09 11:50:32.459 CUL_HM HR.Waschmaschine_Power voltage: 229.3
2016.07.09 11:50:34.806 4 : CUL_Parse: nanoCUL 054566 A FF71 00106936 00 14 18 A45F 33C508 2703CC 864AD6006E93052808D2FE -71
2016.07.09 11:50:34.810 4 : CUL_send: nanoCUL Aa 3446 0A 18 8002 2703CC 33C508 00
2016.07.09 11:50:34.820 3 : CUL_send: nanoCUL id:33C508 dDly:92 tgtdly:120 toms:101



Evtl wirst du ja mehr schlau draus. Schade nur das Joachim nicht mit testet...

Und danke nochmal

LG Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juli 2016, 13:27:00
Hallo Chris,

danke, ist wohl wie vermutet, ich muss unterdrücken.

Im Anhang der Versuch dazu. Ich kann es nur nicht testen, weil ich kein unpassendes Device dafür habe.
Versuch's bitte nochmal mit dieser geänderten Version von 10_CUL_HM.pm.

Ich hoffe, es kommt so etwas weiter. Leider ist der Code etwas komplex, um ihn mal eben komplett zu überblicken.

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 Juli 2016, 13:58:33
Hallo Ansgar.

So, habe deine neue Version getestet, leider ohne Erfolg.

Das log :

2016.07.09 14:04:00.156 4 : CUL_Parse: nanoCUL 195593 A FF81 00080232 00 1A 01 8400 398BE6 000000 1000DC4D45513036353637383740010101 -68.5
2016.07.09 14:04:00.157 2 : CUL_HM Unknown device HM_398BE6 is now defined
2016.07.09 14:04:00.158 2 : autocreate: define HM_398BE6 CUL_HM 398BE6
2016.07.09 14:04:00.160 2 : autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016-07-09 14:04:00.180 Global global UNDEFINED HM_398BE6 CUL_HM 398BE6
2016-07-09 14:04:00.180 Global global DEFINED HM_398BE6
2016-07-09 14:04:00.180 Global global DEFINED FileLog_HM_398BE6
2016-07-09 14:04:00.180 Global global SAVE
2016.07.09 14:04:00.183 3 : CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.07.09 14:04:00.187 4 : CUL_send: nanoCUL Aa 2753 10 29 A001 2703CC 398BE6 00050000000000
2016.07.09 14:04:00.198 3 : CUL_send: nanoCUL id:398BE6 dDly:34 tgtdly:300 toms:43
2016-07-09 14:04:00.203 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-09 14:04:00.203 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.09 14:04:00.481 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:304 dHMtgt:304
2016.07.09 14:04:00.482 4 : CUL_Parse: nanoCUL 195923 A FF83 00080536 00 10 29 A001 2703CC 398BE6 00050000000000 -138
2016.07.09 14:04:00.620 4 : CUL_Parse: nanoCUL 196057 A FF81 00080696 00 1A 02 8400 398BE6 000000 1000DC4D45513036353637383740010101 -68.5
2016-07-09 14:04:00.624 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-09 14:04:00.624 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016-07-09 14:04:02.659 CUL_HM HM_398BE6 ResndFail
2016-07-09 14:04:02.662 CUL_HM HM_398BE6 MISSING ACK
2016-07-09 14:04:03.090 at WattUsageAnDummy Next: 14:04:08
2016-07-09 14:04:08.090 at WattUsageAnDummy Next: 14:04:13
2016-07-09 14:04:13.090 at WattUsageAnDummy Next: 14:04:18
2016.07.09 14:04:15.910 4 : CUL_Parse: nanoCUL 211351 A FF81 00096008 00 14 16 845E 33C508 000000 865D44006192049108E0FF -71.5
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr current: 1169
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr eState: E: 41709.2 P: 249.78 I: 1169 U: 227.2 f: 49.99
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr energy: 41709.2
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr energyCalc: 86704.1
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr frequency: 49.99
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr power: 249.78
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr 41709.2
2016-07-09 14:04:15.918 CUL_HM HM_33C508_Pwr voltage: 227.2
2016-07-09 14:04:15.919 CUL_HM HM_33C508_SenF 49.99
2016-07-09 14:04:15.920 CUL_HM HM_33C508_SenI 1169
2016-07-09 14:04:15.921 CUL_HM HM_33C508_SenU 227.2
2016-07-09 14:04:15.922 CUL_HM Leistung 249.78
2016.07.09 14:04:16.801 4 : CUL_Parse: nanoCUL 212241 A FF81 00096896 00 14 16 A45F 33C508 2703CC 865D44006ADB04F408E5FE -71.5
2016.07.09 14:04:16.804 4 : CUL_send: nanoCUL Aw 0B 0A 16 8002 2703CC 33C508 00
2016.07.09 14:04:16.814 3 : CUL_send: nanoCUL id:33C508 dDly:90 tgtdly:120 toms:97
2016-07-09 14:04:16.820 CUL_HM HM_33C508 CMDs_done
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr current: 1268
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr eState: E: 41709.2 P: 273.55 I: 1268 U: 227.7 f: 49.98
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr energy: 41709.2
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr energyCalc: 86704.1
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr frequency: 49.98
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr power: 273.55
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr 41709.2
2016-07-09 14:04:16.822 CUL_HM HM_33C508_Pwr voltage: 227.7
2016-07-09 14:04:16.823 CUL_HM HM_33C508_SenF 49.98
2016-07-09 14:04:16.824 CUL_HM HM_33C508_SenI 1268
2016-07-09 14:04:16.825 CUL_HM HM_33C508_SenU 227.7
2016-07-09 14:04:16.826 CUL_HM Leistung 273.55
2016.07.09 14:04:16.937 3 : CUL_ParseTsHM: nanoCUL id:33C508 dhmSt:120 dHMtgt:120
2016.07.09 14:04:16.937 4 : CUL_Parse: nanoCUL 212382 A FF83 00097016 00 0A 16 8002 2703CC 33C508 00 -138
2016-07-09 14:04:18.089 dummy AktuellerVerbrauchPC 273.55
2016-07-09 14:04:18.092 at WattUsageAnDummy Next: 14:04:23
2016-07-09 14:04:23.090 at WattUsageAnDummy Next: 14:04:28
2016.07.09 14:04:24.681 4 : CUL_Parse: nanoCUL 220121 A FF71 00104784 00 14 17 A45F 33C508 2703CC 865D490061CA049B08CDFF -70
2016.07.09 14:04:24.684 4 : CUL_send: nanoCUL Aw 0B 0A 17 8002 2703CC 33C508 00
2016.07.09 14:04:24.695 3 : CUL_send: nanoCUL id:33C508 dDly:90 tgtdly:120 toms:97
2016-07-09 14:04:24.700 CUL_HM HM_33C508 CMDs_done
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr boot: off
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr current: 1179
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr eState: E: 41709.7 P: 250.34 I: 1179 U: 225.3 f: 49.99
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr energy: 41709.7
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr energyCalc: 86704.6
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr frequency: 49.99
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr power: 250.34
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr 41709.7
2016-07-09 14:04:24.702 CUL_HM HM_33C508_Pwr voltage: 225.3
2016-07-09 14:04:24.703 CUL_HM HM_33C508_SenF 49.99
2016-07-09 14:04:24.705 CUL_HM HM_33C508_SenI 1179
2016-07-09 14:04:24.706 CUL_HM HM_33C508_SenU 225.3
2016-07-09 14:04:24.707 CUL_HM Leistung 250.34
2016.07.09 14:04:24.817 3 : CUL_ParseTsHM: nanoCUL id:33C508 dhmSt:120 dHMtgt:120
2016.07.09 14:04:24.817 4 : CUL_Parse: nanoCUL 220262 A FF73 00104904 00 0A 17 8002 2703CC 33C508 00 -138


Und das List vom "bösen Sensor"

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     2
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         96
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:02 - t:00 s:398BE6 d:000000 1000DC4D45513036353637383740010101
   nanoCUL_MSGCNT 2
   nanoCUL_RAWMSG A1A028400398BE60000001000DC4D45513036353637383740010101::-68.5:nanoCUL
   nanoCUL_RSSI -68.5
   nanoCUL_TIME 2016-07-09 14:04:00
   protCmdDel 3
   protLastRcv 2016-07-09 14:04:00
   protResndFail 1 last_at:2016-07-09 14:04:02
   protSnd    1 last_at:2016-07-09 14:04:00
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL avg:-68.5 min:-68.5 max:-68.5 lst:-68.5 cnt:2
   Readings:
     2016-07-09 14:04:00   D-firmware      1.0
     2016-07-09 14:04:00   D-serialNr      MEQ0656787
     2016-07-09 14:04:00   R-pairCentral   set_0x2703CC
     2016-07-09 14:04:02   state           MISSING ACK
   Helper:
     HM_CMDNR   41
     cSnd       ,012703CC398BE600050000000000
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   1000000001
       LRcTm      80696
       LastRecTyp 00
       lastSendtgd 304
       newChn     +398BE6,00,00,00
       nextSend   1468065840.71875
       nextSendMcnt 02
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        02
       Io:
         nanoCUL    -66.5
     Prt:
       bErr       0
       mmcS       1
       sProc      0
       mmcA:
         ++A0012703CC398BE600050000000000
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -68.5
         cnt        2
         lst        -68.5
         max        -68.5
         min        -68.5
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton


Ich bin dir ja unendlich dankbar, dass du es zumindest versuchst. Wenn wir hier nicht weiterkommen, dann schicke ich dir den Sensor auch zu wenn es dir hilft. Ich kann ihn ja so eh nicht nutzen...

LG Chris ...der Hoffnungsvoll nach vorne schaut...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Juli 2016, 14:54:38
Hallo Chris,

ich hoffe mal, das Martin hier noch eine Idee beisteuern kann.

Die Änderung hat zwar geklappt, aber das device antwortet nicht, wie im Beispiel https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045 (https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045). Eventuell ist das noch Timing.
Du könntest noch mit dem Attribut "hmPairAddDly" spielen, wenn das device nach dem ersten Versuch angelegt ist.

Vielleicht wird zu früh oder zu spät gesendet so dass das device schon wieder schläft, so dass Du ab 180 mal abnehmend spielen kannst?
Mit geändertem Attribut neue Versuche starten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Juli 2016, 01:37:23
Hallo Chris, hallo Joachim,

neues Spiel neues Glück!?

Ich habe nochmal einen Blick in das Beispiel genommen und komme nun zum Gedanken, dass HM-LAN noch verzögert hat und zwar hinter die Wiederholung. Daher denke ich nun, dass 544ms Antwortverzögerng vielleicht richtig ist, um passend hinter der Wiederholung vom device zu senden.

 00_CUL.pm und 10_CUL_HM.pm sind dazu angepasst.
Außerdem habe ich auf 120ms Sendeverzögerung für weitere Kommandos umgestellt.

Ich hoffe, das bringt was. Ansonsten bitte wirklich mal mit dem Device Attribut "hmPairAddDly" spielen.  Ein Wert von 424 entspricht dem 544ms Verzögerung.

Meine HM-LC-SW1-BA-PCB pairen damit, aber ich glaube langsam, die sind sehr "gutmütig".

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 11 Juli 2016, 13:04:35
Hallo Ansgar.

Also ich habe deine Änderungen eingespielt. Nun bekomme ich beim pairen wieder ein Nack statt Missing Ack.


Log mit verb 4:

2016-07-11 13:08:37.375 at WattUsageAnDummy Next: 13:08:42
2016.07.11 13:08:37.856 4 : CUL_Parse: nanoCUL 328269 A FF81 00023392 00 1A 01 8400 398BE6 000000 1000DC4D45513036353637383740010101 -72
2016.07.11 13:08:37.857 2 : CUL_HM Unknown device HM_398BE6 is now defined
2016.07.11 13:08:37.859 2 : autocreate: define HM_398BE6 CUL_HM 398BE6
2016.07.11 13:08:37.861 2 : autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016-07-11 13:08:37.882 Global global UNDEFINED HM_398BE6 CUL_HM 398BE6
2016-07-11 13:08:37.882 Global global DEFINED HM_398BE6
2016-07-11 13:08:37.882 Global global DEFINED FileLog_HM_398BE6
2016-07-11 13:08:37.882 Global global SAVE
2016.07.11 13:08:37.885 3 : CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.07.11 13:08:37.890 4 : CUL_send: nanoCUL Aa 0BB0 10 02 A001 2703CC 398BE6 00050000000000
2016.07.11 13:08:37.901 3 : CUL_send: nanoCUL id:398BE6 dDly:51 tgtdly:544 toms:63
2016-07-11 13:08:37.906 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-11 13:08:37.906 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.11 13:08:38.418 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:544 dHMtgt:544
2016.07.11 13:08:38.419 4 : CUL_Parse: nanoCUL 328836 A FF83 00023936 00 10 02 A001 2703CC 398BE6 00050000000000 -138
2016.07.11 13:08:38.557 4 : CUL_Parse: nanoCUL 328970 A FF81 00024096 00 1A 02 8400 398BE6 000000 1000DC4D45513036353637383740010101 -70.5
2016.07.11 13:08:38.561 3 : CUL_HM set HM_398BE6 getConfig
2016.07.11 13:08:38.562 4 : CUL_send: nanoCUL Aa 0BD3 13 03 A001 2703CC 398BE6 000802010A270B030CCC
2016.07.11 13:08:38.573 3 : CUL_send: nanoCUL id:398BE6 dDly:81 tgtdly:120 toms:94
2016-07-11 13:08:38.577 CUL_HM HM_398BE6 D-firmware: 1.0
2016-07-11 13:08:38.577 CUL_HM HM_398BE6 D-serialNr: MEQ0656787
2016.07.11 13:08:38.702 3 : CUL_ParseTsHM: nanoCUL id:398BE6 dhmSt:120 dHMtgt:120
2016.07.11 13:08:38.703 4 : CUL_Parse: nanoCUL 329119 A FF83 00024216 00 13 03 A001 2703CC 398BE6 000802010A270B030CCC -138
2016.07.11 13:08:38.815 4 : CUL_Parse: nanoCUL 329237 A FF81 00024360 00 0A 03 8002 398BE6 2703CC 80 -71.5
2016-07-11 13:08:38.821 CUL_HM HM_398BE6 NACK
2016-07-11 13:08:38.821 CUL_HM HM_398BE6 Nack

List vom "bösen Sensor"

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     3
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         93
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398BE6 d:2703CC 80
   nanoCUL_MSGCNT 3
   nanoCUL_RAWMSG A0A038002398BE62703CC80::-71.5:nanoCUL
   nanoCUL_RSSI -71.5
   nanoCUL_TIME 2016-07-11 13:08:38
   protCmdDel 5
   protLastRcv 2016-07-11 13:08:38
   protNack   1 last_at:2016-07-11 13:08:38
   protSnd    2 last_at:2016-07-11 13:08:38
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL avg:-71.33 min:-72 max:-70.5 lst:-71.5 cnt:3
   Readings:
     2016-07-11 13:08:38   CommandAccepted no
     2016-07-11 13:08:38   D-firmware      1.0
     2016-07-11 13:08:38   D-serialNr      MEQ0656787
     2016-07-11 13:08:37   R-pairCentral   set_0x2703CC
     2016-07-11 13:08:38   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       012703CC398BE600050000000000,012703CC398BE6000802010A270B030CCC
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   1000000001
       LRcTm      24360
       LastRecTyp 02
       lastSendtgd 120
       newChn     +398BE6,00,00,00
       nextSend   1468235318.91858
       nextSendMcnt 03
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL    -69.5
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A0012703CC398BE600050000000000
         ++A0012703CC398BE6000802010A270B030CCC
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -71.3333333333333
         cnt        3
         lst        -71.5
         max        -70.5
         min        -72
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton


Auch habe ich mit angelegtem Device und unterschiedlichen "hmPairAddDly" getestet. Und zwar alle von 0ms, in 50ms Schritten, bis hin zu 440ms.

Leider kein Erfolg.

Aber dennoch danke für´s weiter grübeln.

Gruß Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 13 Juli 2016, 23:15:37
Hallo Chris,

danke für die Tests.

Da im Beispiel von Oliver das Device brav mit 120ms mit ACK antwortet, wie das HM-CFG-USB Beispiel zeigt, war ich zunächst der Ansicht, das HM-LAN den "00050000000000" send extra verzögert. Und dann hätte meine Timing Wahl funktionieren müssen. Die vorherige Variante mit Ausfiltern des wiederholten Status hat zu keiner weiteren Antwort ACK oder NACK geführt. Der HM-Sen-DB-PCB benötigt wohl die Wiederholung, was offenbar auch nicht an der Kommando Nummer liegt, wie ich erst vermutet hatte.

Dummerweise wurde HM-LAN im Beispiel von Oliver nicht mit einem CUL mit meiner Timestamp Firmware "beobachtet".

Auf Grund der Ergebnisse gehe ich nun davon aus, dass HM-LAN "heimlich" den "00050000000000" send genauso wiederholt hat, wie HM-CFG-USB das gemacht hat und darauf der ACK eingetroffen ist. Es wäre schön, wenn ein HM-LAN Besitzer das durch "mithorchen" bestätigen könnte.

Dann müsste entweder 10_CUL_HM.pm angepasst werden, damit bei ausbleibendem ACK "richtig" wiederholt wird, da HM-LAN dies wohl selbständig tut, oder diese Protokollanpassung in 00_CUL.pm hinein gebastelt werden wo es wohl eigentlich nicht hingehört (ist mit CUL-Timestamp zunehmend schon doppelte Interpretation des Protokolls in 00_CUL.pm und 10_CUL_HM.pm).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 14 Juli 2016, 06:37:09
Hallo Ansgar.

Danke, dass du dich weiterhin mit dem Thema beschäftigst.

Wenn ich irgendwas beitragen kann sag mir Bescheid.

Es ist wirklich das einzige Homematic Device was bei mir Probleme macht.

Evtl hat Martin ja noch eine Eingebung.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 August 2016, 23:33:23
Hallo Chris, hallo Joachim,

ich habe mal eine einmalige Wiederholung von HM Nachrichten durch 10_CUL.pm eingebaut, die eine Antwort anfordern. Dazu zählt auch der problematische Pairing Request.

Könnt Ihr bitte damit nochmal testen.

Mit dem Attribut "hmSndRepTmOut" kannst Du noch mit dem Wiederholtimeout spielen. 216 ist default. Wenn es zu kurz gewählt wird, dann passiert es häufiger, dass FHEM zu langsam ist und der Timeout zuschlägt (und wiederholt wird), obwohl CUL die Antwort empfängt. Zu lang kann dazu führen, dass 10_CUL_HM.pm schon wiederholt und dann 00_CUL.pm den Widerholversuch startet, was das Protokoll aus dem Tritt bringen kann.

Aber ich hoffe mal, dass die Wiederholung bei dem Klingelsensor hilft. Bitte mehrmals ein Pairing probieren. Beim ersten Versuch wird das device angelegt, was auch zu einer Verzögerung führt, so dass erst der zweite Versuch eine gute Chance bekommt. Natürlich erst das device richtig in den Auslieferungszustand zurücksetzen, damit es garantiert nicht schon anderweitig gepaired ist.

Außerdem wird die Creditsauslastung wie bei HMLAN nun signalisiert, so dass bei VCCU Nutzung auch gebremst wird, wenn die Credits zur neige gehen. Das hat bisher zu einer FHEM Vollauslastung geführt.
STACKABLE_CC wird mit der korrigierten 10_CUL_HM.pm von der VCCU richtig als list device berücksichtigt.

Test wie immer: Erst backup der Dateien und dann alle Dateien aus der Zip im FHEM Verzeichnis austauschen.
Und bitte mit verbose 4 bei CUL testen, um sinnvolle logs zu erzeugen.

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 August 2016, 00:14:03
Hallo Ansgar,

ja klar!

Sorry war etwas ruhig die letzten (vielen) Tage...
Hatte so einiges um die Ohren...

Wird Zeit, dass ich Urlaub hab... :-)

Rückmeldung sobald getestet!

Danke, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 05 August 2016, 06:07:30
Hallo Ansgar, auch ich werde testen und mich melden!

Gruß Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 August 2016, 22:11:03
Hi Ansgar,

also erster Schnelltest durchgeführt, leider immer noch bekannter Fehler.

Hier das Log mit verbose 4:

2016.08.05 21:57:01.004 3: CUL_HM set vccu hmPairForSec 60
2016.08.05 21:57:02.031 4: CUL_Parse: nanoCUL_HM  508610 A FF61 00319664 00 0C A7 865A 3229B5 000000 98F437 -73.5
2016.08.05 21:57:05.286 4: CUL_Parse: nanoCUL_HM  511858 A FF61 00322912 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -49
2016.08.05 21:57:05.288 2: CUL_HM Unknown device HM_398B7D is now defined
2016.08.05 21:57:05.299 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.08.05 21:57:05.304 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.08.05 21:57:05.315 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.08.05 21:57:05.335 4: CUL_send:  nanoCUL_HM                    Aa 9DEA 10 02 A001 AFFE02 398B7D 00050000000000
2016.08.05 21:57:05.336 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:426 tgtdly:496 toms:415
2016.08.05 21:57:05.801 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.05 21:57:05.801 4: CUL_Parse: nanoCUL_HM  512381 A FF63 00323408 00 10 02 A001 AFFE02 398B7D  -138
2016.08.05 21:57:05.944 4: CUL_Parse: nanoCUL_HM  512515 A FF61 00323568 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46
2016.08.05 21:57:05.952 3: CUL_HM set HM_398B7D getConfig
2016.08.05 21:57:05.965 4: CUL_send:  nanoCUL_HM                    Aa 9E0D 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.08.05 21:57:05.966 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:74 tgtdly:120 toms:63
2016.08.05 21:57:06.082 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.05 21:57:06.086 4: CUL_Parse: nanoCUL_HM  512663 A FF63 00323688 00 13 03 A001 AFFE02 398B7D  -138
2016.08.05 21:57:06.202 4: CUL_Parse: nanoCUL_HM  512782 A FF61 00323832 00 0A 03 8002 398B7D AFFE02 80 -46.5
2016.08.05 21:57:09.652 4: CUL_Parse: nanoCUL_HM  516230 A FF61 00327280 00 0F 8C 8610 2B8E86 000000 0A98FB0B0040 -74.5
2016.08.05 21:57:11.099 4: CUL_Parse: nanoCUL_HM  517678 A FF61 00328728 00 0C 63 865A 3227F4 000000 90F937 -69
2016.08.05 21:57:21.102 4: CUL_Parse: nanoCUL_HM  003392 A FF61 00338728 00 0E CC 8410 3227F4 000000 0B90F90E40 -69
2016.08.05 21:57:21.183 4: CUL_Parse: nanoCUL_HM  003474 A FF61 00338816 00 0C A6 865A 31D958 000000 90FB35 -77
2016.08.05 21:57:22.031 4: CUL_Parse: nanoCUL_HM  004322 A FF61 00339656 00 0C A7 8470 3229B5 000000 00F437 -73
2016.08.05 21:57:31.098 4: CUL_Parse: nanoCUL_HM  013390 A FF61 00348728 00 0C 63 8470 3227F4 000000 00F937 -69.5
2016.08.05 21:57:33.276 4: CUL_Parse: nanoCUL_HM  015574 A FF62 00350912 00 01 AE -138
2016.08.05 21:57:35.442 4: CUL_Parse: nanoCUL_HM  017733 A FF61 00353064 00 0C C9 865A 31D1FE 000000 910832 -56
2016.08.05 21:57:36.931 4: CUL_Parse: nanoCUL_HM  019217 A FF61 00354552 00 14 B8 845E 4A347F 000000 8013190000000000090E07 -65.5
2016.08.05 21:57:41.183 4: CUL_Parse: nanoCUL_HM  023475 A FF61 00358808 00 0C A6 8470 31D958 000000 00FB35 -76
2016.08.05 21:57:43.111 4: CUL_Parse: nanoCUL_HM  025403 A FF61 00360736 00 0C AB 8670 2BBF72 000000 00D03D -60
2016.08.05 21:57:44.679 4: CUL_Parse: nanoCUL_HM  026971 A FF61 00362304 00 0C 71 865A 322927 000000 60F538 -70.5
2016.08.05 21:57:49.593 3: resource, /lights/2, not available
2016.08.05 21:57:49.594 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x2d63ed8)
2016.08.05 21:57:50.489 4: CUL_Parse: nanoCUL_HM  032776 A FF62 00368104 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.08.05 21:57:53.281 4: CUL_Parse: nanoCUL_HM  035571 A FF61 00370904 00 0F D6 8610 2C8BFC 000000 0A90FB0C0040 -76
2016.08.05 21:57:54.684 4: CUL_Parse: nanoCUL_HM  036973 A FF61 00372304 00 0E DE 8410 322927 000000 0B60F52D40 -71
2016.08.05 21:57:55.442 4: CUL_Parse: nanoCUL_HM  037733 A FF61 00373064 00 0C C9 8470 31D1FE 000000 010832 -55.5
2016.08.05 21:58:01.508 3: CUL_HM set vccu hmPairForSec 60
2016.08.05 21:58:02.017 4: CUL_Parse: nanoCUL_HM  044308 A FF61 00379640 00 0C 18 865A 32185B 000000 90FF35 -56.5
2016.08.05 21:58:04.261 4: CUL_Parse: nanoCUL_HM  046545 A FF61 00381872 00 1A 03 8400 398B7D 000000 1000DC4D45513036353638393240010101 -48
2016.08.05 21:58:04.266 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr MEQ0656892
2016.08.05 21:58:04.275 3: CUL_HM set HM_398B7D getConfig
2016.08.05 21:58:04.288 4: CUL_send:  nanoCUL_HM                    Aa BAB4 10 04 A001 AFFE02 398B7D 00050000000000
2016.08.05 21:58:04.288 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:444 tgtdly:496 toms:432
2016.08.05 21:58:04.679 4: CUL_Parse: nanoCUL_HM  046970 A FF61 00382296 00 0C 71 8470 322927 000000 00F538 -71
2016.08.05 21:58:04.773 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.05 21:58:04.773 4: CUL_Parse: nanoCUL_HM  047066 A FF63 00382368 00 10 04 A001 AFFE02 398B7D  -138
2016.08.05 21:58:04.916 4: CUL_Parse: nanoCUL_HM  047200 A FF61 00382528 00 1A 04 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47.5
2016.08.05 21:58:04.934 4: CUL_send:  nanoCUL_HM                    Aa BAD7 13 05 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.08.05 21:58:04.935 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:76 tgtdly:120 toms:66
2016.08.05 21:58:05.056 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.05 21:58:05.057 4: CUL_Parse: nanoCUL_HM  047349 A FF63 00382648 00 13 05 A001 AFFE02 398B7D  -138
2016.08.05 21:58:05.174 4: CUL_Parse: nanoCUL_HM  047466 A FF61 00382792 00 0A 05 8002 398B7D AFFE02 80 -47.5
2016.08.05 21:58:13.074 4: CUL_Parse: nanoCUL_HM  055364 A FF61 00390688 00 0F 67 8610 2D9B77 000000 0A98F40B0040 -70
2016.08.05 21:58:22.017 4: CUL_Parse: nanoCUL_HM  064308 A FF61 00399632 00 0C 18 8470 32185B 000000 00FF35 -56
2016.08.05 21:58:29.469 4: CUL_Parse: nanoCUL_HM  071758 A FF61 00407080 00 0F 21 8610 2BA56B 000000 0A60F50A0040 -63
2016.08.05 21:58:33.380 4: CUL_Parse: nanoCUL_HM  075677 A FF62 00411000 00 01 AE -138
2016.08.05 21:58:37.548 4: CUL_Parse: nanoCUL_HM  079839 A FF61 00415160 00 0C C0 865A 453732 000000 A8FF34 -74
2016.08.05 21:58:49.595 3: resource, /lights/2, not available
2016.08.05 21:58:49.596 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x2eb7058)
2016.08.05 21:58:57.547 4: CUL_Parse: nanoCUL_HM  099839 A FF61 00435152 00 0C C0 8470 453732 000000 00FF34 -76
2016.08.05 21:59:07.376 3: CUL_HM set HM_398B7D getConfig
2016.08.05 21:59:11.678 4: CUL_Parse: nanoCUL_HM  113961 A FF61 00449272 00 1A 05 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46
2016.08.05 21:59:11.700 4: CUL_send:  nanoCUL_HM                    Aa DB6E 10 06 A001 AFFE02 398B7D 00040000000000
2016.08.05 21:59:11.701 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:77 tgtdly:120 toms:65
2016.08.05 21:59:11.812 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.05 21:59:11.813 4: CUL_Parse: nanoCUL_HM  114105 A FF63 00449392 00 10 06 A001 AFFE02 398B7D  -138
2016.08.05 21:59:11.955 4: CUL_Parse: nanoCUL_HM  114239 A FF61 00449552 00 1A 06 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47.5
2016.08.05 21:59:13.849 4: CUL_Parse: nanoCUL_HM  116141 A FF61 00451456 00 0C 64 865A 3227F4 000000 90F937 -69
2016.08.05 21:59:19.282 4: CUL_Parse: nanoCUL_HM  121573 A FF61 00456888 00 0C A8 865A 3229B5 000000 98F437 -73.5
2016.08.05 21:59:20.532 4: CUL_Parse: nanoCUL_HM  122823 A FF61 00458136 00 0C C4 865A 32279A 000000 98FB36 -79
2016.08.05 21:59:30.536 4: CUL_Parse: nanoCUL_HM  132825 A FF61 00468136 00 0E 75 8410 32279A 000000 0B98FB0D40 -79
2016.08.05 21:59:33.485 4: CUL_Parse: nanoCUL_HM  135781 A FF62 00471088 00 01 AE -138
2016.08.05 21:59:33.849 4: CUL_Parse: nanoCUL_HM  136141 A FF61 00471448 00 0C 64 8470 3227F4 000000 00F937 -68
2016.08.05 21:59:39.281 4: CUL_Parse: nanoCUL_HM  141573 A FF61 00476880 00 0C A8 8470 3229B5 000000 00F437 -73
2016.08.05 21:59:40.539 4: CUL_Parse: nanoCUL_HM  142831 A FF61 00478136 00 0C C4 8470 32279A 000000 00FB36 -80.5
2016.08.05 21:59:49.598 3: resource, /lights/2, not available
2016.08.05 21:59:49.599 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x2d63f80)

Hier ein list vom Klingelsensor:

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     8
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         371
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:06 - t:00 s:398B7D d:000000 1000DC4D45513036353638393240010101
   nanoCUL_HM_MSGCNT 8
   nanoCUL_HM_RAWMSG A1A068400398B7D0000001000DC4D45513036353638393240010101::-47.5:nanoCUL_HM
   nanoCUL_HM_RSSI -47.5
   nanoCUL_HM_TIME 2016-08-05 21:59:11
   protCmdDel 13
   protLastRcv 2016-08-05 21:59:11
   protNack   2 last_at:2016-08-05 21:58:05
   protResndFail 1 last_at:2016-08-05 21:59:16
   protSnd    5 last_at:2016-08-05 21:59:11
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-47.25 min:-49 max:-46 lst:-47.5 cnt:8
   Readings:
     2016-08-05 21:58:05   CommandAccepted no
     2016-08-05 21:59:11   D-firmware      1.0
     2016-08-05 21:59:11   D-serialNr      MEQ0656892
     2016-08-05 21:57:05   R-pairCentral   set_0xAFFE02
     2016-08-05 21:59:16   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   6
     cSnd       01AFFE02398B7D000802010AAF0BFE0C02,01AFFE02398B7D00040000000000
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   7000000001
       LRcTm      449552
       LastRecTyp 00
       lastSendtgd 120
       newChn     +398B7D,00,00,00
       nextSend   1470427152.05486
       nextSendMcnt 06
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        06
       Io:
         nanoCUL_HM -45.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -47.25
         cnt        8
         lst        -47.5
         max        -46
         min        -49
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton


und ein list des nanoCUL:

Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   HM_RptCnt  4
   NAME       nanoCUL_HM
   NR         44
   PARTIAL
   RAWMSG     AFF310001EDCB000CC4847045373200000000FF34FB
   RSSI       -76.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 176
   nanoCUL_HM_TIME 2016-08-05 22:08:33
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-08-05 21:53:33   Xmit-Events     ok:1 disconnected:1 init:2 Warning-HighLoad:1
     2016-06-27 21:46:01   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:0.000kHz
     2016-08-05 21:51:32   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-08-05 21:53:33   cond            ok
     2016-05-06 00:05:19   credit10ms      900
     2016-05-21 08:31:29   hmSioDly        24
     2016-08-05 21:51:49   prot_Warning-HighLoad last
     2016-08-05 21:51:31   prot_disconnected last
     2016-08-05 21:51:32   prot_init       last
     2016-08-05 21:53:33   prot_ok         last
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-07-10 19:11:21   scF             1.00022173812602
     2016-08-05 21:51:32   state           Initialized
     2016-07-22 17:11:01   version         V 1.66 nanoCUL868
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    3
       hmSbusy    0
       lastSndTm  1470427151.8009
       Unknwn:
         2b1a82:
           AunknCnt   2000000000
           LRcTm      506168
           LastRecTyp 10
           nextSend   1470427208.68355
           nextSendMcnt 00
           tgtdly     120
         2b8e86:
           AunknCnt   6000000000
           LRcTm      966400
           LastRecTyp 10
           nextSend   1470427669.01214
           nextSendMcnt 90
           tgtdly     120
         2ba56b:
           AunknCnt   5000000000
           LRcTm      837992
           LastRecTyp 10
           nextSend   1470427540.57707
           nextSendMcnt 24
           tgtdly     120
         2bbf72:
           AunknCnt   6000000000
           LRcTm      935880
           LastRecTyp 70
           nextSend   1470427638.48514
           nextSendMcnt AF
           tgtdly     120
         2c8bfc:
           AunknCnt   6000000000
           LRcTm      995776
           LastRecTyp 10
           nextSend   1470427698.39368
           nextSendMcnt DA
           tgtdly     120
         2d9b77:
           AunknCnt   6000000000
           LRcTm      973072
           LastRecTyp 10
           nextSend   1470427675.68517
           nextSendMcnt 6B
           tgtdly     120
         31d1fe:
           AunknCnt   13000000000
           LRcTm      958688
           LastRecTyp 70
           nextSend   1470427661.29811
           nextSendMcnt CD
           tgtdly     120
         31d958:
           AunknCnt   13000000000
           LRcTm      993176
           LastRecTyp 70
           nextSend   1470427695.79296
           nextSendMcnt AA
           tgtdly     120
         32185b:
           AunknCnt   13000000000
           LRcTm      968760
           LastRecTyp 70
           nextSend   1470427671.37229
           nextSendMcnt 1C
           tgtdly     120
         32279a:
           AunknCnt   15000000000
           LRcTm      912040
           LastRecTyp 70
           nextSend   1470427614.63928
           nextSendMcnt C7
           tgtdly     120
         3227f4:
           AunknCnt   17000000000
           LRcTm      945104
           LastRecTyp 70
           nextSend   1470427647.71052
           nextSendMcnt 67
           tgtdly     120
         322927:
           AunknCnt   14000000000
           LRcTm      995664
           LastRecTyp 5A
           nextSend   1470427698.28232
           nextSendMcnt 75
           tgtdly     120
         3229b5:
           AunknCnt   13000000000
           LRcTm      930040
           LastRecTyp 70
           nextSend   1470427632.64276
           nextSendMcnt AB
           tgtdly     120
         4a347f:
           AunknCnt   3000000000
           LRcTm      782208
           LastRecTyp 5E
           nextSend   1470427484.77976
           nextSendMcnt BB
           tgtdly     120
     Hmq:
     Hmqo:
     Cnd:
       0          1
       2          1
       253        1
       255        2
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        15750
     Ref:
       ApCUPend   0
       AsPend     0
       IObyterate 3840
       Lhmt       1011288
       Lsys       475156736
       Sdly       3
       doNbyterate 1
       hmDstDly   120
       nusew      32
       pTTu       1024
       pingLm     15
       pingMax    196
       pingMin    7
       pingRef    7
       pingtm     474160683
       pingtmBRs  1470427671.96604
       scF        1.00022173812602
       scFN       1
       scHT       15456
       scST       474160690
Attributes:
   hmId       AFFE02
   hmLanQlen  1_min
   rfmode     HomeMatic
   verbose    4

Wie gesagt ein erster Schnelltest.

Hatte leider noch keine Zeit mit dem/den Parametern zu "spielen", sorry!

Werde aber wohl erst am So oder Di wieder Zeit haben mich etwas tiefer mit dem Thema zu beschäftigen...

Gruß und vielen Dank, Joachim

P.S.: ich hoffe ich habe bei der Schnelle des Tests nichts wichtiges (dummes) übersehen...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 August 2016, 22:23:33
Hallo Ansgar,

nachdem ich schon mal dabei war hab ich doch noch ein wenig rumprobiert...

Ein wenig mit dem Wert 'hmSndRepTmOut' gespielt.

Aber ohne Erfolg.
Wobei ich nicht genau weiß wieviel in welche Richtung helfen sollte.

Wie ich es verstanden habe eher mal höher?
Default war übrigens 180, kann das sein?
Zumindest wird das beim ersten Anlegen des attr angezeigt.

Bin mal über den Default 216 und dann auf 245 gegangen...

Wenn du noch Logs etc. brauchst oder ich was flasch getestet hab bitte melden!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 August 2016, 22:27:04
Hallo Joachim,

danke für den Test.

Das hat mir zumindest gerade die Augen nochmal geöffnet für das zweite Problem, dass die Message Nummer von 10_CUL_HM.pm für den Request noch ungünstig gewählt ist und daher die Status Wiederholung vom Device schon als Antwort gesehen wird und damit auch die Wiederholung nicht stattfindet, die ich eingebaut hatte.

Da muss ich nochmal drüber schauen wie ich das korrigieren kann.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 August 2016, 22:55:34
Hallo Ansgar,

schön, dass es was geholfen hat.

Auch wenn es leider wieder (nur) mehr "Arbeit" für dich bedeutet...

Wenn ich wieder was tun kann, lass es mich wissen!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 August 2016, 12:53:45
Hallo Joachim, hallo Chris,

anbei eine neuer Versuch zum Testen.
Ich habe 10_CUL_HM.pm angepasst, so dass die Message Nummer um mehr als 1 erhöht wird.

Dann sollte es auch mit der Wiedeholung klappen, hoffe ich.

Zitat
Default war übrigens 180, kann das sein?
Das liegt am Slider, ich weiss leider nicht, wie ich den anders als mit dem Min Wert vorbelegen könnte, wenn das Attribut noch nicht existiert.

Gruß, Ansgar.

Edit: Anhang gelöscht, da update siehe unten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 06 August 2016, 14:04:01
Hi Ansgar,

danke.
Komme aber leider erst morgen dazu...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 August 2016, 17:30:20
Hallo Joachim, hallo Chris, hallo Martin,

im Anhang nochmal ein Update, da mir noch Schwäche in 00_CUL.pm bei der IODelay Ermittlung aufgefallen ist.

Test wie immer: Erst backup der Dateien und dann alle Dateien aus der Zip im FHEM Verzeichnis austauschen.
Und bitte mit verbose 4 bei CUL testen, um sinnvolle logs zu erzeugen.
Das device darf natürlich nicht mit einer anderen Zentrale gepaired sein, also ggf. den Klingelsensor erst mal nach Anleirung in der Auslieferungszustand zurück setzen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 07 August 2016, 22:27:50
Hallo Ansgar,

so habe mal getestet.

Klingelsensor reset und in fhem gelöscht und neu angelernt.

Manuell ein getConfig.
Und noch mal angelernt (ohne reset und ohne löschen in fhem).
Und noch mal (ein paar mal) getConfig.

Hmmm, scheint wohl (etwas) besser, da das Pairing nun (wieder) abgeschlossen wird (also kein set_ mehr).
(nach dem ersten manuellen getConfig, danach allerdigs auch 'RESPONSE TIMEOUT:RegisterRead' und 'CMDs_done_Errors:1')
Allerdings immer noch/wieder den RESPONSE TIMEOUT:RegisterRead...

Hier mal das Log:

2016.08.07 22:07:00.889 3: CUL_HM set vccu hmPairForSec 60
2016.08.07 22:07:04.489 4: CUL_Parse: nanoCUL_HM  371741 A FF61 00464544 00 0C 38 8470 453732 000000 00FC33 -66.5
2016.08.07 22:07:05.496 4: CUL_Parse: nanoCUL_HM  372747 A FF61 00465544 00 0C E5 8470 322927 000000 00F637 -69.5
2016.08.07 22:07:05.959 4: CUL_Parse: nanoCUL_HM  373203 A FF61 00466000 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47.5
2016.08.07 22:07:05.961 2: CUL_HM Unknown device HM_398B7D is now defined
2016.08.07 22:07:05.969 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.08.07 22:07:05.973 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.08.07 22:07:05.984 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.08.07 22:07:06.005 4: CUL_send:  nanoCUL_HM                    Aa E3C8 10 29 A001 AFFE02 398B7D 00050000000000
2016.08.07 22:07:06.005 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:424 tgtdly:496 toms:417
2016.08.07 22:07:06.470 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.07 22:07:06.471 4: CUL_Parse: nanoCUL_HM  373723 A FF63 00466496 00 10 29 A001 AFFE02 398B7D  -138
2016.08.07 22:07:06.613 4: CUL_Parse: nanoCUL_HM  373857 A FF61 00466656 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.08.07 22:07:06.673 4: CUL_send:  nanoCUL_HM                    Aa E41A 10 29 A001 AFFE02 398B7D 00050000000000
2016.08.07 22:07:06.674 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:412 tgtdly:496 toms:404
2016.08.07 22:07:07.126 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.07 22:07:07.127 4: CUL_Parse: nanoCUL_HM  374379 A FF63 00467152 00 10 29 A001 AFFE02 398B7D  -138
2016.08.07 22:07:07.246 4: CUL_Parse: nanoCUL_HM  374499 A FF61 00467296 00 0A 29 8002 398B7D AFFE02 00 -46.5
2016.08.07 22:07:07.262 4: CUL_send:  nanoCUL_HM                    Aa E43B 13 2A A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.08.07 22:07:07.263 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:85 tgtdly:120 toms:78
2016.08.07 22:07:07.393 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:07:07.393 4: CUL_Parse: nanoCUL_HM  374646 A FF63 00467416 00 13 2A A001 AFFE02 398B7D  -138
2016.08.07 22:07:07.511 4: CUL_Parse: nanoCUL_HM  374763 A FF61 00467560 00 0A 2A 8002 398B7D AFFE02 00 -47
2016.08.07 22:07:07.527 4: CUL_send:  nanoCUL_HM                    Aa E45C 0B 2B A001 AFFE02 398B7D 0006
2016.08.07 22:07:07.527 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:89 tgtdly:120 toms:80
2016.08.07 22:07:07.650 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:07:07.650 4: CUL_Parse: nanoCUL_HM  374903 A FF63 00467680 00 0B 2B A001 AFFE02 398B7D  -138
2016.08.07 22:07:07.788 4: CUL_Parse: nanoCUL_HM  375040 A FF61 00467840 00 0A 2B 8002 398B7D AFFE02 00 -46.5
2016.08.07 22:07:08.953 4: CUL_Parse: nanoCUL_HM  376203 A FF61 00469000 00 0C 37 8470 32279A 000000 00FB34 -71
2016.08.07 22:07:12.518 4: CUL_Parse: nanoCUL_HM  379767 A FF61 00472568 00 0F 07 8610 2B8E86 000000 0A98FB0B0040 -74
2016.08.07 22:07:12.869 4: CUL_Parse: nanoCUL_HM  380120 A FF61 00472904 00 0C 1C 8470 31D958 000000 00FB37 -84.5
2016.08.07 22:07:21.192 4: CUL_Parse: nanoCUL_HM  388449 A FF62 00481248 00 01 AE -138
2016.08.07 22:07:27.753 4: CUL_Parse: nanoCUL_HM  395004 A FF51 00487800 00 0C 3C 865A 31D1FE 000000 910433 -58
2016.08.07 22:07:31.669 4: CUL_Parse: nanoCUL_HM  398916 A FF52 00491712 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.08.07 22:07:32.220 3: CUL_HM set HM_398B7D getConfig
2016.08.07 22:07:33.099 3: resource, /lights/2, not available
2016.08.07 22:07:33.103 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x3902de0)
2016.08.07 22:07:36.732 4: CUL_Parse: nanoCUL_HM  403976 A FF51 00496768 00 1A 03 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:07:36.750 4: CUL_send:  nanoCUL_HM                    Aa F29F 10 04 A001 AFFE02 398B7D 00040000000000
2016.08.07 22:07:36.751 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:77 tgtdly:120 toms:70
2016.08.07 22:07:36.868 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:07:36.869 4: CUL_Parse: nanoCUL_HM  404121 A FF53 00496888 00 10 04 A001 AFFE02 398B7D  -138
2016.08.07 22:07:37.012 4: CUL_Parse: nanoCUL_HM  404255 A FF51 00497048 00 1A 04 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.08.07 22:07:47.753 4: CUL_Parse: nanoCUL_HM  415004 A FF51 00507792 00 0C 3C 8470 31D1FE 000000 010433 -58
2016.08.07 22:07:52.642 4: CUL_Parse: nanoCUL_HM  419890 A FF51 00512680 00 14 2F 845E 4A347F 000000 8015DF00000000000912FF -63
2016.08.07 22:07:57.892 4: CUL_Parse: nanoCUL_HM  425137 A FF51 00517928 00 16 39 8653 4BDE84 000000 004100FD4200FE43FFFF440001 -53
2016.08.07 22:08:19.711 3: CUL_HM set vccu hmPairForSec 60
2016.08.07 22:08:21.294 4: CUL_Parse: nanoCUL_HM  448552 A FF52 00541336 00 01 AE -138
2016.08.07 22:08:23.189 4: CUL_Parse: nanoCUL_HM  450433 A FF51 00543216 00 1A 05 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.08.07 22:08:23.195 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr MEQ0656892
2016.08.07 22:08:23.206 3: CUL_HM set HM_398B7D getConfig
2016.08.07 22:08:23.219 4: CUL_send:  nanoCUL_HM                    Aa 097C 10 2D A001 AFFE02 398B7D 00050000000000
2016.08.07 22:08:23.220 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:442 tgtdly:496 toms:434
2016.08.07 22:08:23.704 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.07 22:08:23.704 4: CUL_Parse: nanoCUL_HM  450956 A FF53 00543712 00 10 2D A001 AFFE02 398B7D  -138
2016.08.07 22:08:23.846 4: CUL_Parse: nanoCUL_HM  451090 A FF51 00543872 00 1A 06 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:08:23.903 4: CUL_send:  nanoCUL_HM                    Aa 09CE 10 2D A001 AFFE02 398B7D 00050000000000
2016.08.07 22:08:23.904 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:415 tgtdly:496 toms:408
2016.08.07 22:08:24.359 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:496 dHMtgt:496
2016.08.07 22:08:24.359 4: CUL_Parse: nanoCUL_HM  451612 A FF53 00544368 00 10 2D A001 AFFE02 398B7D  -138
2016.08.07 22:08:24.480 4: CUL_Parse: nanoCUL_HM  451733 A FF51 00544512 00 0A 2D 8002 398B7D AFFE02 00 -46.5
2016.08.07 22:08:24.498 4: CUL_send:  nanoCUL_HM                    Aa 09EF 13 2E A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.08.07 22:08:24.498 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:83 tgtdly:120 toms:76
2016.08.07 22:08:24.625 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:24.627 4: CUL_Parse: nanoCUL_HM  451878 A FF53 00544632 00 13 2E A001 AFFE02 398B7D  -138
2016.08.07 22:08:24.745 4: CUL_Parse: nanoCUL_HM  451997 A FF51 00544776 00 0A 2E 8002 398B7D AFFE02 00 -46.5
2016.08.07 22:08:24.762 4: CUL_send:  nanoCUL_HM                    Aa 0A10 0B 2F A001 AFFE02 398B7D 0006
2016.08.07 22:08:24.763 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:87 tgtdly:120 toms:78
2016.08.07 22:08:24.883 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:24.884 4: CUL_Parse: nanoCUL_HM  452136 A FF53 00544896 00 0B 2F A001 AFFE02 398B7D  -138
2016.08.07 22:08:25.024 4: CUL_Parse: nanoCUL_HM  452276 A FF51 00545056 00 0A 2F 8002 398B7D AFFE02 00 -46.5
2016.08.07 22:08:25.041 4: CUL_send:  nanoCUL_HM                    Aa 0A33 10 30 A001 AFFE02 398B7D 00040000000000
2016.08.07 22:08:25.042 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:85 tgtdly:120 toms:78
2016.08.07 22:08:25.168 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:25.168 4: CUL_Parse: nanoCUL_HM  452421 A FF53 00545176 00 10 30 A001 AFFE02 398B7D  -138
2016.08.07 22:08:25.311 4: CUL_Parse: nanoCUL_HM  452555 A FF51 00545336 00 1A 30 A010 398B7D AFFE02 02020105000AAF0BFE0C02140618000000 -46
2016.08.07 22:08:25.333 4: CUL_send:  nanoCUL_HM                    Aa 0A56 0A 30 8002 AFFE02 398B7D 00
2016.08.07 22:08:25.333 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:77 tgtdly:120 toms:67
2016.08.07 22:08:25.402 4: CUL_send:  nanoCUL_HM                    Aa 0A65 10 31 A001 AFFE02 398B7D 01040000000001
2016.08.07 22:08:25.403 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:124 tgtdly:240 toms:117
2016.08.07 22:08:25.442 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:25.443 4: CUL_Parse: nanoCUL_HM  452695 A FF53 00545456 00 0A 30 8002 AFFE02 398B7D  -138
2016.08.07 22:08:25.568 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:240 dHMtgt:240
2016.08.07 22:08:25.569 4: CUL_Parse: nanoCUL_HM  452821 A FF53 00545576 00 10 31 A001 AFFE02 398B7D  -138
2016.08.07 22:08:25.701 4: CUL_Parse: nanoCUL_HM  452948 A FF51 00545728 00 12 31 A010 398B7D AFFE02 020410080030060000 -46.5
2016.08.07 22:08:25.723 4: CUL_send:  nanoCUL_HM                    Aa 0A87 0A 31 8002 AFFE02 398B7D 00
2016.08.07 22:08:25.724 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:79 tgtdly:120 toms:70
2016.08.07 22:08:25.795 4: CUL_send:  nanoCUL_HM                    Aa 0A96 0B 32 A001 AFFE02 398B7D 0103
2016.08.07 22:08:25.795 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:127 tgtdly:240 toms:118
2016.08.07 22:08:25.834 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:25.835 4: CUL_Parse: nanoCUL_HM  453087 A FF53 00545848 00 0A 31 8002 AFFE02 398B7D  -138
2016.08.07 22:08:25.956 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:240 dHMtgt:240
2016.08.07 22:08:25.956 4: CUL_Parse: nanoCUL_HM  453209 A FF53 00545968 00 0B 32 A001 AFFE02 398B7D  -138
2016.08.07 22:08:26.085 4: CUL_Parse: nanoCUL_HM  453336 A FF51 00546120 00 0D 32 A010 398B7D AFFE02 01000000 -46
2016.08.07 22:08:26.104 4: CUL_send:  nanoCUL_HM                      Aw 09 0A 32 8002 AFFE02 398B7D 00
2016.08.07 22:08:26.104 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:90 tgtdly:120 toms:83
2016.08.07 22:08:26.211 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:104 dHMtgt:120 hmSioDly:18
2016.08.07 22:08:26.211 4: CUL_Parse: nanoCUL_HM  453463 A FF53 00546224 00 0A 32 8002 AFFE02 398B7D  -138
2016.08.07 22:08:28.283 4: CUL_Parse: nanoCUL_HM  455533 A FF51 00548312 00 0F 9A 8610 2BA56B 000000 0A60F60A0040 -63.5
2016.08.07 22:08:33.110 3: resource, /lights/2, not available
2016.08.07 22:08:33.111 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x38c1b00)
2016.08.07 22:08:38.947 4: CUL_Parse: nanoCUL_HM  466198 A FF51 00558976 00 0C 8C 865A 32185B 000000 90FD34 -55.5
2016.08.07 22:08:45.372 4: CUL_Parse: nanoCUL_HM  472623 A FF51 00565400 00 0C 1F 865A 3229B5 000000 98F936 -76.5
2016.08.07 22:08:51.741 4: CUL_Parse: nanoCUL_HM  478992 A FF51 00571768 00 0C 39 865A 453732 000000 88FD33 -66
2016.08.07 22:08:53.298 3: CUL_HM set HM_398B7D getConfig
2016.08.07 22:08:55.605 4: CUL_Parse: nanoCUL_HM  482856 A FF51 00575632 00 0C 1D 865A 31D958 000000 90FB37 -87
2016.08.07 22:08:56.147 4: CUL_Parse: nanoCUL_HM  483391 A FF51 00576168 00 1A 07 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:08:56.169 4: CUL_send:  nanoCUL_HM                    Aa 1964 10 08 A001 AFFE02 398B7D 00040000000000
2016.08.07 22:08:56.170 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:78 tgtdly:120 toms:73
2016.08.07 22:08:56.286 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:08:56.287 4: CUL_Parse: nanoCUL_HM  483539 A FF53 00576288 00 10 08 A001 AFFE02 398B7D  -138
2016.08.07 22:08:56.429 4: CUL_Parse: nanoCUL_HM  483673 A FF51 00576448 00 1A 08 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:08:58.946 4: CUL_Parse: nanoCUL_HM  486197 A FF51 00578968 00 0C 8C 8470 32185B 000000 00FD34 -55.5
2016.08.07 22:08:59.916 4: CUL_Parse: nanoCUL_HM  487166 A FF51 00579944 00 0F DE 8610 2D9B77 000000 0A98F90B0040 -70.5
2016.08.07 22:09:00.967 4: CUL_Parse: nanoCUL_HM  488218 A FF51 00580992 00 0C DD 865A 3227F4 000000 90F936 -68.5
2016.08.07 22:09:01.744 4: CUL_Parse: nanoCUL_HM  488995 A FF51 00581768 00 0E 68 8410 453732 000000 0B88FD0E00 -65.5
2016.08.07 22:09:02.297 4: CUL_Parse: nanoCUL_HM  489547 A FF51 00582320 00 0F 75 8610 2B1A82 000000 0A90FD0B0040 -61
2016.08.07 22:09:05.373 4: CUL_Parse: nanoCUL_HM  492624 A FF51 00585400 00 0C 1F 8470 3229B5 000000 00F936 -77.5
2016.08.07 22:09:11.741 4: CUL_Parse: nanoCUL_HM  498993 A FF51 00591768 00 0C 39 8470 453732 000000 00FD33 -66
2016.08.07 22:09:13.705 4: CUL_Parse: nanoCUL_HM  500955 A FF51 00593728 00 0C 38 865A 32279A 000000 98FB34 -71
2016.08.07 22:09:15.604 4: CUL_Parse: nanoCUL_HM  502855 A FF51 00595624 00 0C 1D 8470 31D958 000000 00FB37 -86
2016.08.07 22:09:20.969 4: CUL_Parse: nanoCUL_HM  508219 A FF51 00600984 00 0C DD 8470 3227F4 000000 00F936 -68.5
2016.08.07 22:09:21.396 4: CUL_Parse: nanoCUL_HM  508653 A FF52 00601424 00 01 AE -138
2016.08.07 22:09:30.293 4: CUL_Parse: nanoCUL_HM  517544 A FF51 00610312 00 0C 22 8670 2BBF72 000000 00E238 -62.5
2016.08.07 22:09:31.973 4: CUL_Parse: nanoCUL_HM  519220 A FF52 00611984 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.08.07 22:09:33.192 3: resource, /lights/2, not available
2016.08.07 22:09:33.193 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x3ae2880)
2016.08.07 22:09:33.704 4: CUL_Parse: nanoCUL_HM  520955 A FF51 00613720 00 0C 38 8470 32279A 000000 00FB34 -71.5
2016.08.07 22:09:35.450 4: CUL_Parse: nanoCUL_HM  522700 A FF51 00615464 00 0F 50 8610 2C8BFC 000000 0A90FB0C0040 -67.5
2016.08.07 22:09:36.247 4: CUL_Parse: nanoCUL_HM  523498 A FF51 00616264 00 0C E6 865A 322927 000000 60F637 -69.5
2016.08.07 22:09:45.503 4: CUL_Parse: nanoCUL_HM  008467 A FF51 00625520 00 0C 3D 865A 31D1FE 000000 910433 -58
2016.08.07 22:09:46.912 3: CUL_HM set HM_398B7D getConfig
2016.08.07 22:09:50.522 4: CUL_Parse: nanoCUL_HM  013477 A FF51 00630528 00 1A 09 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:09:50.550 4: CUL_send:  nanoCUL_HM                    Aa 33EF 10 0A A001 AFFE02 398B7D 00040000000000
2016.08.07 22:09:50.551 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:67 tgtdly:120 toms:62
2016.08.07 22:09:50.660 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:09:50.662 4: CUL_Parse: nanoCUL_HM  013624 A FF53 00630648 00 10 0A A001 AFFE02 398B7D  -138
2016.08.07 22:09:50.800 4: CUL_Parse: nanoCUL_HM  013756 A FF51 00630808 00 1A 0A 8400 398B7D 000000 1000DC4D45513036353638393240010101 -46.5
2016.08.07 22:09:56.247 4: CUL_Parse: nanoCUL_HM  019210 A FF51 00636264 00 0C E6 8470 322927 000000 00F637 -70.5
2016.08.07 22:10:05.141 4: CUL_Parse: nanoCUL_HM  028099 A FF51 00645144 00 16 3A 8653 4BDE84 000000 004100FD4200FF43FFFE440002 -52.5
2016.08.07 22:10:05.503 4: CUL_Parse: nanoCUL_HM  028466 A FF51 00645512 00 0C 3D 8470 31D1FE 000000 010433 -58
2016.08.07 22:10:12.270 4: CUL_Parse: nanoCUL_HM  035231 A FF51 00652280 00 0F 08 8610 2B8E86 000000 0A98FB0B0040 -74
2016.08.07 22:10:21.500 4: CUL_Parse: nanoCUL_HM  044469 A FF52 00661512 00 01 AE -138
2016.08.07 22:10:21.643 4: CUL_Parse: nanoCUL_HM  044602 A FF51 00661648 00 14 30 845E 4A347F 000000 8015DF00000000000910FF -63
2016.08.07 22:10:33.108 3: resource, /lights/2, not available
2016.08.07 22:10:33.109 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x3ae8718)
2016.08.07 22:10:35.653 3: CUL_HM set HM_398B7D getConfig
2016.08.07 22:10:39.309 4: CUL_Parse: nanoCUL_HM  062265 A FF51 00679304 00 1A 0B 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:10:39.327 4: CUL_send:  nanoCUL_HM                    Aa 4BC0 10 0C A001 AFFE02 398B7D 00040000000000
2016.08.07 22:10:39.327 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:76 tgtdly:120 toms:71
2016.08.07 22:10:39.444 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.07 22:10:39.445 4: CUL_Parse: nanoCUL_HM  062409 A FF53 00679424 00 10 0C A001 AFFE02 398B7D  -138
2016.08.07 22:10:39.587 4: CUL_Parse: nanoCUL_HM  062543 A FF51 00679584 00 1A 0C 8400 398B7D 000000 1000DC4D45513036353638393240010101 -47
2016.08.07 22:10:49.036 4: CUL_Parse: nanoCUL_HM  071996 A FF51 00689032 00 0F 9B 8610 2BA56B 000000 0A60F60A0040 -63.5

Es gibt allerdings das 'attr hmSndRepTmOut' nicht mehr, oder!?
Dafür einige andere.
Soll ich da mal Werte anpassen?
Welche in welche Richtung?

Hier noch das list des Klingelsensors:

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     21
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         394
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:0C - t:00 s:398B7D d:000000 1000DC4D45513036353638393240010101
   nanoCUL_HM_MSGCNT 21
   nanoCUL_HM_RAWMSG A1A0C8400398B7D0000001000DC4D45513036353638393240010101::-47:nanoCUL_HM
   nanoCUL_HM_RSSI -47
   nanoCUL_HM_TIME 2016-08-07 22:10:39
   protCmdDel 12
   protLastRcv 2016-08-07 22:10:39
   protResndFail 4 last_at:2016-08-07 22:10:43
   protSnd    16 last_at:2016-08-07 22:10:39
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-46.69 min:-47.5 max:-46 lst:-47 cnt:21
   Readings:
     2016-08-07 22:08:25   CommandAccepted yes
     2016-08-07 22:10:39   D-firmware      1.0
     2016-08-07 22:10:39   D-serialNr      MEQ0656892
     2016-08-07 22:08:25   PairedTo        0xAFFE02
     2016-08-07 22:08:25   R-ledMode       off
     2016-08-07 22:08:25   R-longPress     0.4 s
     2016-08-07 22:08:25   R-pairCentral   0xAFFE02
     2016-08-07 22:08:25   R-sign          off
     2016-08-07 22:10:43   state           RESPONSE TIMEOUT:RegisterRead
   Helper:
     HM_CMDNR   12
     cSnd       01AFFE02398B7D00040000000000,01AFFE02398B7D00040000000000
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     peerIDsRaw ,00000000
     rxType     4
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       AunknCnt   1000000001
       LRcTm      679584
       LastRecTyp 00
       dwoCCAAa   120
       dwoCCAAw   104
       lastSendtgd 120
       newChn     +398B7D,00,00,00
       nextSend   1470600639.68741
       nextSendMcnt 0C
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        0C
       Io:
         nanoCUL_HM -45
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -46.6904761904762
         cnt        21
         lst        -47
         max        -46
         min        -47.5
     Shadowreg:
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.0
   model      HM-Sen-DB-PCB
   peerIDs    00000000,
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

Er funktioniert (wie zuvor) auch, also die Auslösesignale werden in fhem angezeigt.
Aber das ist klar, die Funkmeldungen werden empfangen und ja auch ohne abgeschlossenes Pairing ja zugeordnet und angezeigt (das ging ja schon immer irgendwie).

Dann ist auch der 'RESPONSE TIMEOUT:RegisterRead' weg (auch klar: neuer state).
Nach einem getConfig ist er dann wieder da...

Soweit erst mal wieder von mir...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 August 2016, 00:59:17
Hallo Joachim,

danke für den Test!

Der hat schon mal gezeigt, dass das Pairing mit meinem Workaround durchläuft. Das Device bestätigt, wie es sein soll. Ich hoffe, mit der Info kann Martin das in 10_CUL_HM.pm für die Allgemeinheit anpassen.

Das mit dem getConfig ist einmal direkt nach dem Anlernen fast durchgelaufen. Dann hat ein Aw mit vermutlich zu kurzer Wartezeit das Device zum Abbruch des getConfig gebracht oder was anderes hat gestört.
Die hmSioDly Optimierung war wohl noch nicht weit genug durch gelaufen, weswegen Aw zu früh dran war.

Bei Deinen übrigen getConfig Versuchen hat das device nicht geantwortet, obwohl die Anfrage mit wunderbaren 120ms "Antwortzeit" von nanoCUL gesendet wurde.
Drückst Du eventuell die Taste dann falsch?
Ich kenne es häufig so: Taste etwa 4 Sekunden drücken bis die LED blinkt zum Anlernen.
Um nur Aufzuwecken, damit das device auf getConfig reagiert, Taste kurz drücken.
Aber vielleicht ist das bei dem Klingelsensor auch anders? Ich habe leider keine Doku dazu.
EDIT: Hier ist der Anlernhinweis zu finden http://www.elv.de/topic/funk-klingelsignalsensor-hm-sen-db-pcb-kein-anlernen-moeglich.html (http://www.elv.de/topic/funk-klingelsignalsensor-hm-sen-db-pcb-kein-anlernen-moeglich.html)

Oder das device schläft früher wieder ein oder ist noch nicht empfangsbereit? Dann müsste man $CUL_hmSndDly oben in 00_CUL.pm verringern oder vergrößern.
Dazu wäre es gut, ein "original" getConfig mit CUL "belauschen" zu können. Zumindest zielführender als lange rum zu probieren.

Edit: Oder das device will es beim ersten mal nicht verstehen und benötigt auch für getConfig eine Wiederholung nach dem Aufwachen, die nicht kommt, weil ich den Message Counter Trick nur auf das Pairing beschränkt habe?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 August 2016, 23:00:49
Hallo Joachim, hallo Chris, hallo Martin,

ich habe den letzten Gedanken nochmal weiter verfolgt und im Anhang neue Versionen vom 10_CUL_HM.pm und 00_CUL.pm kreiert.

Zum einen habe ich die vermutlich unnötige extra Wartezeit nach einem Pair Request wieder entfernt.
Und zum anderen die Wiederholung bei jedem Pair Request eingebaut, so dass auch bei getConfig einmal wiederholt werden sollte.

Damit hoffe ich richtig zu liegen so dass sowohl das Pairing, als auch getConfig nach Drücken der Anlerntaste beim Klingelsensor funktionieren.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 08 August 2016, 23:57:07
Hallo Ansgar,

super! Scheint jetzt zu funktionieren! :-)

Vom Klingelsensor her war es aber schon immer ok, das Pairing.
Also genau wie in der verlinkten "Anleitung" beschrieben.

Oranges (wenn man das so nennen kann ;-)   ) Blinken und dann mit grün bestätigt.

Beim getConfig bin ich mir nicht so sicher aber zumindest war bislange kein Rot am Ende...
(außer gestern glaube ich, bin mir aber nicht sicher hab noch mit dem Differenztemperaturfühler auf dem HM-UART-Testsystem "rumgespielt")


Hier das Log:

2016.08.08 23:45:01.845 3: CUL_HM set vccu hmPairForSec 60
2016.08.08 23:45:07.121 4: CUL_Parse: nanoCUL_HM  379682 A FF71 00209792 00 0F 3E 8610 2D9B77 000000 0A98FA0B0040 -71
2016.08.08 23:45:07.528 4: CUL_Parse: nanoCUL_HM  380084 A FF71 00210192 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -58
2016.08.08 23:45:07.530 2: CUL_HM Unknown device HM_398B7D is now defined
2016.08.08 23:45:07.543 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.08.08 23:45:07.548 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.08.08 23:45:07.562 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.08.08 23:45:07.585 4: CUL_send:  nanoCUL_HM                    Aa 66B1 10 29 A001 AFFE02 398B7D 00050000000000
2016.08.08 23:45:07.585 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:42 tgtdly:120 toms:48
2016.08.08 23:45:07.667 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:45:07.668 4: CUL_Parse: nanoCUL_HM  380232 A FF73 00210312 00 10 29 A001 AFFE02 398B7D  -138
2016.08.08 23:45:07.708 4: CUL_Parse: nanoCUL_HM  380272 A FF71 00210376 00 0C 7C 8470 31D958 000000 00FB37 -85.5
2016.08.08 23:45:07.810 4: CUL_Parse: nanoCUL_HM  380366 A FF71 00210472 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -57.5
2016.08.08 23:45:07.867 4: CUL_send:  nanoCUL_HM                    Aa 66D4 10 29 A001 AFFE02 398B7D 00050000000000
2016.08.08 23:45:07.867 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:39 tgtdly:120 toms:45
2016.08.08 23:45:07.946 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:45:07.947 4: CUL_Parse: nanoCUL_HM  380512 A FF73 00210592 00 10 29 A001 AFFE02 398B7D  -138
2016.08.08 23:45:08.068 4: CUL_Parse: nanoCUL_HM  380633 A FF71 00210736 00 0A 29 8002 398B7D AFFE02 00 -57.5
2016.08.08 23:45:08.084 4: CUL_send:  nanoCUL_HM                    Aa 66F5 13 2A A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.08.08 23:45:08.085 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:83 tgtdly:120 toms:90
2016.08.08 23:45:08.213 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:45:08.214 4: CUL_Parse: nanoCUL_HM  380778 A FF73 00210856 00 13 2A A001 AFFE02 398B7D  -138
2016.08.08 23:45:08.332 4: CUL_Parse: nanoCUL_HM  380897 A FF71 00211000 00 0A 2A 8002 398B7D AFFE02 00 -59
2016.08.08 23:45:08.349 4: CUL_send:  nanoCUL_HM                    Aa 6716 0B 2B A001 AFFE02 398B7D 0006
2016.08.08 23:45:08.349 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:87 tgtdly:120 toms:92
2016.08.08 23:45:08.471 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:45:08.472 4: CUL_Parse: nanoCUL_HM  381036 A FF73 00211120 00 0B 2B A001 AFFE02 398B7D  -138
2016.08.08 23:45:08.611 4: CUL_Parse: nanoCUL_HM  381175 A FF71 00211280 00 0A 2B 8002 398B7D AFFE02 00 -62
2016.08.08 23:45:20.073 4: CUL_Parse: nanoCUL_HM  392636 A FF71 00222736 00 0C EA 8470 32185B 000000 00FC36 -54
2016.08.08 23:45:27.068 4: CUL_Parse: nanoCUL_HM  399638 A FF72 00229736 00 01 AE -138
2016.08.08 23:45:30.775 4: CUL_Parse: nanoCUL_HM  403339 A FF71 00233440 00 0C 81 8670 2BBF72 000000 00E338 -65.5
2016.08.08 23:45:37.526 4: CUL_Parse: nanoCUL_HM  410088 A FF71 00240184 00 0C 99 865A 453732 000000 88FA35 -65.5
2016.08.08 23:45:43.414 3: resource, /lights/2, not available
2016.08.08 23:45:43.415 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x1b9bbe8)
2016.08.08 23:45:44.010 4: CUL_Parse: nanoCUL_HM  416569 A FF72 00246664 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.08.08 23:45:47.102 4: CUL_Parse: nanoCUL_HM  419666 A FF71 00249760 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:47.303 4: CUL_Parse: nanoCUL_HM  419867 A FF71 00249968 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:47.502 4: CUL_Parse: nanoCUL_HM  420066 A FF71 00250160 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:48.126 4: CUL_Parse: nanoCUL_HM  420690 A FF71 00250784 00 0B 34 A001 AFFE11 4A8036 010E -40
2016.08.08 23:45:48.327 4: CUL_Parse: nanoCUL_HM  420891 A FF71 00250984 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:48.527 4: CUL_Parse: nanoCUL_HM  421091 A FF71 00251184 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:50.703 4: CUL_Parse: nanoCUL_HM  423267 A FF71 00253360 00 0B 34 A001 AFFE11 4A7FC7 010E -40
2016.08.08 23:45:50.903 4: CUL_Parse: nanoCUL_HM  423467 A FF71 00253560 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:51.103 4: CUL_Parse: nanoCUL_HM  423667 A FF71 00253760 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:52.816 4: CUL_Parse: nanoCUL_HM  425380 A FF71 00255472 00 0B 34 A001 AFFE11 4A8036 010E -40
2016.08.08 23:45:53.016 4: CUL_Parse: nanoCUL_HM  425580 A FF71 00255672 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:53.217 4: CUL_Parse: nanoCUL_HM  425781 A FF71 00255872 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:55.334 4: CUL_Parse: nanoCUL_HM  427897 A FF71 00257992 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:55.535 4: CUL_Parse: nanoCUL_HM  428099 A FF71 00258192 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:55.735 4: CUL_Parse: nanoCUL_HM  428299 A FF71 00258392 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:57.447 4: CUL_Parse: nanoCUL_HM  430011 A FF71 00260104 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:57.525 4: CUL_Parse: nanoCUL_HM  430087 A FF71 00260184 00 0C 99 8470 453732 000000 00FA35 -65
2016.08.08 23:45:57.649 4: CUL_Parse: nanoCUL_HM  430213 A FF71 00260304 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:57.848 4: CUL_Parse: nanoCUL_HM  430412 A FF71 00260504 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:45:59.770 4: CUL_Parse: nanoCUL_HM  432333 A FF71 00262424 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:45:59.970 4: CUL_Parse: nanoCUL_HM  432534 A FF71 00262632 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:46:00.170 4: CUL_Parse: nanoCUL_HM  432734 A FF71 00262832 00 0B 34 A001 AFFE11 4A7FC7 010E -39.5
2016.08.08 23:46:01.883 4: CUL_Parse: nanoCUL_HM  434447 A FF71 00264544 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:46:02.084 4: CUL_Parse: nanoCUL_HM  434648 A FF71 00264744 00 0B 34 A001 AFFE11 4A8036 010E -40
2016.08.08 23:46:02.284 4: CUL_Parse: nanoCUL_HM  434848 A FF71 00264944 00 0B 34 A001 AFFE11 4A8036 010E -39.5
2016.08.08 23:46:04.644 4: CUL_Parse: nanoCUL_HM  437206 A FF71 00267296 00 0F D4 8610 2B1A82 000000 0A90FC0B0040 -58.5
2016.08.08 23:46:05.944 4: CUL_Parse: nanoCUL_HM  438507 A FF71 00268600 00 0C 3E 865A 3227F4 000000 90FB37 -70.5
2016.08.08 23:46:13.416 4: CUL_Parse: nanoCUL_HM  445978 A FF71 00276072 00 0C 44 865A 322927 000000 90F938 -68.5
2016.08.08 23:46:18.243 3: CUL_HM set HM_398B7D getConfig
2016.08.08 23:46:20.693 4: CUL_Parse: nanoCUL_HM  453250 A FF61 00283344 00 16 99 8653 4BDE84 000000 004100FA4200FD43FFFD440003 -52.5
2016.08.08 23:46:22.123 4: CUL_Parse: nanoCUL_HM  454679 A FF61 00284768 00 1A 03 8400 398B7D 000000 1000DC4D45513036353638393240010101 -62.5
2016.08.08 23:46:22.144 4: CUL_send:  nanoCUL_HM                    Aa 8B1B 10 2B A001 AFFE02 398B7D 00040000000000
2016.08.08 23:46:22.145 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:73 tgtdly:120 toms:80
2016.08.08 23:46:22.259 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:46:22.260 4: CUL_Parse: nanoCUL_HM  454824 A FF73 00284888 00 10 2B A001 AFFE02 398B7D  -138
2016.08.08 23:46:22.403 4: CUL_Parse: nanoCUL_HM  454959 A FF71 00285048 00 1A 04 8400 398B7D 000000 1000DC4D45513036353638393240010101 -64
2016.08.08 23:46:22.458 4: CUL_send:  nanoCUL_HM                    Aa 8B3E 10 2B A001 AFFE02 398B7D 00040000000000
2016.08.08 23:46:22.459 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:39 tgtdly:120 toms:46
2016.08.08 23:46:22.540 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:46:22.540 4: CUL_Parse: nanoCUL_HM  455105 A FF73 00285168 00 10 2B A001 AFFE02 398B7D  -138
2016.08.08 23:46:22.683 4: CUL_Parse: nanoCUL_HM  455239 A FF71 00285328 00 1A 2B A010 398B7D AFFE02 02020105000AAF0BFE0C02140618000000 -69.5
2016.08.08 23:46:22.704 4: CUL_send:  nanoCUL_HM                    Aa 8B61 0A 2B 8002 AFFE02 398B7D 00
2016.08.08 23:46:22.705 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:76 tgtdly:120 toms:81
2016.08.08 23:46:22.787 4: CUL_send:  nanoCUL_HM                    Aa 8B70 10 2C A001 AFFE02 398B7D 01040000000001
2016.08.08 23:46:22.787 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:110 tgtdly:240 toms:117
2016.08.08 23:46:22.814 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:46:22.815 4: CUL_Parse: nanoCUL_HM  455379 A FF73 00285448 00 0A 2B 8002 AFFE02 398B7D  -138
2016.08.08 23:46:22.939 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:240 dHMtgt:240
2016.08.08 23:46:22.940 4: CUL_Parse: nanoCUL_HM  455504 A FF73 00285568 00 10 2C A001 AFFE02 398B7D  -138
2016.08.08 23:46:23.071 4: CUL_Parse: nanoCUL_HM  455631 A FF71 00285720 00 12 2C A010 398B7D AFFE02 020410080030060000 -69.5
2016.08.08 23:46:23.091 4: CUL_send:  nanoCUL_HM                    Aa 8B92 0A 2C 8002 AFFE02 398B7D 00
2016.08.08 23:46:23.091 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:83 tgtdly:120 toms:88
2016.08.08 23:46:23.180 4: CUL_send:  nanoCUL_HM                    Aa 8BA1 0B 2D A001 AFFE02 398B7D 0103
2016.08.08 23:46:23.181 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:113 tgtdly:240 toms:118
2016.08.08 23:46:23.207 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:46:23.208 4: CUL_Parse: nanoCUL_HM  455772 A FF73 00285840 00 0A 2C 8002 AFFE02 398B7D  -138
2016.08.08 23:46:23.328 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:240 dHMtgt:240
2016.08.08 23:46:23.328 4: CUL_Parse: nanoCUL_HM  455893 A FF73 00285960 00 0B 2D A001 AFFE02 398B7D  -138
2016.08.08 23:46:23.458 4: CUL_Parse: nanoCUL_HM  456021 A FF71 00286112 00 0D 2D A010 398B7D AFFE02 01000000 -68.5
2016.08.08 23:46:23.476 4: CUL_send:  nanoCUL_HM                      Aw 0B 0A 2D 8002 AFFE02 398B7D 00
2016.08.08 23:46:23.476 3: CUL_XmitDlyHM:  nanoCUL_HM  id:398B7D dDly:90 tgtdly:120 toms:99
2016.08.08 23:46:23.600 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:120 dHMtgt:120
2016.08.08 23:46:23.600 4: CUL_Parse: nanoCUL_HM  456164 A FF73 00286232 00 0A 2D 8002 AFFE02 398B7D  -138
2016.08.08 23:46:25.944 4: CUL_Parse: nanoCUL_HM  458507 A FF71 00288592 00 0C 3E 8470 3227F4 000000 00FB37 -71
2016.08.08 23:46:27.170 4: CUL_Parse: nanoCUL_HM  459740 A FF72 00289832 00 01 AE -138
2016.08.08 23:46:29.375 4: CUL_Parse: nanoCUL_HM  461937 A FF71 00292024 00 0F 69 8610 2B8E86 000000 0A98FA0B0040 -69.5
2016.08.08 23:46:32.987 4: CUL_Parse: nanoCUL_HM  465549 A FF71 00295632 00 0F B1 8610 2C8BFC 000000 0A90FB0C0040 -70.5
2016.08.08 23:46:33.414 4: CUL_Parse: nanoCUL_HM  465978 A FF71 00296064 00 0C 44 8470 322927 000000 00F938 -68.5
2016.08.08 23:46:43.419 3: resource, /lights/2, not available
2016.08.08 23:46:43.420 2: Licht_SchlaZi: got wrong status message for Licht_SchlaZi: ARRAY(0x1d29b20)
2016.08.08 23:46:45.918 4: CUL_Parse: nanoCUL_HM  478481 A FF61 00308568 00 0C 9B 865A 31D1FE 000000 910334 -59.5

und das list:

Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     22
   NAME       HM_398B7D
   NOTIFYDEV  global
   NR         352
   STATE      HM_398B7D Short
   TYPE       CUL_HM
   lastMsg    No:10 - t:40 s:398B7D d:AFFE02 010E
   nanoCUL_HM_MSGCNT 22
   nanoCUL_HM_RAWMSG A0B10A240398B7DAFFE02010E::-62.5:nanoCUL_HM
   nanoCUL_HM_RSSI -62.5
   nanoCUL_HM_TIME 2016-08-08 23:54:06
   protLastRcv 2016-08-08 23:54:06
   protSnd    21 last_at:2016-08-08 23:54:06
   protState  CMDs_done
   rssi_at_nanoCUL_HM avg:-62.56 min:-69.5 max:-57.5 lst:-62.5 cnt:24
   Readings:
     2016-08-08 23:45:08   CommandAccepted yes
     2016-08-08 23:46:22   D-firmware      1.0
     2016-08-08 23:46:22   D-serialNr      MEQ0656892
     2016-08-08 23:46:22   PairedTo        0xAFFE02
     2016-08-08 23:46:22   R-ledMode       off
     2016-08-08 23:46:23   R-longPress     0.4 s
     2016-08-08 23:46:22   R-pairCentral   0xAFFE02
     2016-08-08 23:46:23   R-sign          off
     2016-08-08 23:54:06   battery         ok
     2016-08-08 23:54:06   state           HM_398B7D Short
     2016-08-08 23:54:06   trigDst_vccu    noConfig
     2016-08-08 23:54:06   trigger         Short_14
     2016-08-08 23:54:06   trigger_cnt     14
   Helper:
     BNO        14
     BNOCNT     1
     HM_CMDNR   16
     cSnd       01AFFE02398B7D01040000000001,01AFFE02398B7D0103
     mId        00DC
     peerIDsRaw ,00000000
     rxType     4
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       AunknCnt   1
       LRcTm      748808
       LastRecTyp 40
       dwoCCAAa   120
       dwoCCAAw   120
       lastSend   1470693246.36044
       lastSendtgd 120
       newChn     +398B7D,00,00,00
       nextSend   1470693246.36044
       nextSendMcnt 10
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        10
       Io:
         nanoCUL_HM -60.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         nanoCUL_HM
       flg        A
       ts         1470693246.26569
       ack:
         HASH(0x1a182a8)
         108002AFFE02398B7D00
     Rssi:
       At_nanocul_hm:
         avg        -62.5625
         cnt        24
         lst        -62.5
         max        -57.5
         min        -69.5
     Shadowreg:
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.0
   model      HM-Sen-DB-PCB
   peerIDs    00000000,
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton

SUPER ARBEIT!!!

Vielen Dank!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 August 2016, 05:38:29
Hallo zusammen.

Sieht doch schon mal super aus.  Ich werde es dann heute Abend wie versprochen auch probieren.
Danke schon einmal für deine Mühen Ansgar.

Gruß Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 August 2016, 20:12:53
Hallo Ansgar, Joachim und Martin.

Also, ich habe es wie versprochen auch getestet. Dateien ausgetauscht, altes Device gelöscht, Save Config, shutdown restart, und pairforsec 60.
Dann Klingelsensor resettet und einmal angelernt.

Nun bekomme ich zur Abwechslung ein IOerr

Sodele, das List des Sensors:

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     1
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         152
   STATE      IOerr
   TYPE       CUL_HM
   lastMsg    No:01 - t:00 s:398BE6 d:000000 1000DC4D45513036353637383740010101
   nanoCUL_MSGCNT 1
   nanoCUL_RAWMSG A1A018400398BE60000001000DC4D45513036353637383740010101::-68.5:nanoCUL
   nanoCUL_RSSI -68.5
   nanoCUL_TIME 2016-08-09 20:00:32
   protCmdDel 4
   protIOerr  1 last_at:2016-08-09 20:01:31
   protLastRcv 2016-08-09 20:00:32
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL lst:-68.5 avg:-68.5 min:-68.5 cnt:1 max:-68.5
   Readings:
     2016-08-09 20:00:32   D-firmware      1.0
     2016-08-09 20:00:32   D-serialNr      MEQ0656787
     2016-08-09 20:00:32   R-pairCentral   set_0x2703CC
     2016-08-09 20:01:31   state           IOerr
   Helper:
     HM_CMDNR   40
     Supp_Pair_Rep 1
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +398BE6,00,00,00
       nextSend   1470765632.38789
       prefIO
       rxt        0
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        01
       Io:
         nanoCUL    -66.5
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul:
         avg        -68.5
         cnt        1
         lst        -68.5
         max        -68.5
         min        -68.5
     Shadowreg:
       RegL_00.    02:01 0A:27 0B:03 0C:CC
Attributes:
   IODev      nanoCUL
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton


und das Log:

2016.08.09 20:00:32.260 2: CUL_HM Unknown device HM_398BE6 is now defined
2016.08.09 20:00:32.262 2: autocreate: define HM_398BE6 CUL_HM 398BE6
2016.08.09 20:00:32.264 2: autocreate: define FileLog_HM_398BE6 FileLog ./log/HM_398BE6-%Y.log HM_398BE6
2016.08.09 20:00:32.300 3: CUL_HM pair: HM_398BE6 pushButton, model HM-Sen-DB-PCB serialNr
2016.08.09 20:01:39.534 2: CUL_Parse: nanoCUL new condition Warning-HighLoad
2016.08.09 20:01:39.538 4: CUL_Parse: nanoCUL  496060 A FFB1 00173992 00 14 03 A45F 33C508 2703CC 827237006E9D051808DB01 -73.5
2016.08.09 20:01:39.551 4: CUL_send:  nanoCUL                      Aw 0B 0A 03 8002 2703CC 33C508 00
2016.08.09 20:01:39.551 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:87 tgtdly:120 toms:99
2016.08.09 20:01:39.669 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:39.669 4: CUL_Parse: nanoCUL  496202 A FFB3 00174112 00 0A 03 8002 2703CC 33C508 00 -138
2016.08.09 20:01:47.292 4: CUL_Parse: nanoCUL  503820 A FFA1 00181760 00 14 42 845E 33C508 000000 82723C006115047A08E702 -73
2016.08.09 20:01:47.552 4: CUL_Parse: nanoCUL  504080 A FFA1 00182016 00 14 04 A45F 33C508 2703CC 82723C006115047A08E702 -74
2016.08.09 20:01:47.565 4: CUL_send:  nanoCUL                      Aw 0B 0A 04 8002 2703CC 33C508 00
2016.08.09 20:01:47.566 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:89 tgtdly:120 toms:99
2016.08.09 20:01:47.685 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:47.685 4: CUL_Parse: nanoCUL  504218 A FFA3 00182136 00 0A 04 8002 2703CC 33C508 00 -138
2016.08.09 20:01:56.532 4: CUL_Parse: nanoCUL  513060 A FFA1 00191008 00 14 05 A45F 33C508 2703CC 827243006F89051A08E203 -74.5
2016.08.09 20:01:56.545 4: CUL_send:  nanoCUL                    Aa 5D53 0A 05 8002 2703CC 33C508 00
2016.08.09 20:01:56.545 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:91 tgtdly:120 toms:102
2016.08.09 20:01:56.669 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:01:56.669 4: CUL_Parse: nanoCUL  513202 A FFA3 00191128 00 0A 05 8002 2703CC 33C508 00 -138
2016.08.09 20:02:04.313 4: CUL_Parse: nanoCUL  520840 A FFA1 00198792 00 14 06 A45F 33C508 2703CC 82724800647604A608DF03 -73.5
2016.08.09 20:02:04.326 4: CUL_send:  nanoCUL                      Aw 0B 0A 06 8002 2703CC 33C508 00
2016.08.09 20:02:04.326 3: CUL_XmitDlyHM:  nanoCUL  id:33C508 dDly:88 tgtdly:120 toms:99
2016.08.09 20:02:04.445 3: CUL_ParseTsHM: nanoCUL  id:33C508 dhmSt:120 dHMtgt:120
2016.08.09 20:02:04.446 4: CUL_Parse: nanoCUL  520979 A FFA3 00198912 00 0A 06 8002 2703CC 33C508 00 -138


Irgendwie habe ich das Gefühl, das pairing ist nicht beendet worden. Was mir auch neu ist, ist diese Meldung : nanoCUL new condition Warning-HighLoad. Glaube kaum, dass er bei meinen 14 Devices an die Grenze der 1% Regel kommt.  :o
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 09 August 2016, 20:33:55
Hi Chris,

highload hatte ich nach dem shutdown restart auch...

Hab mal durchgebootet (dann wird die Load zurück gesetzt) und danach gings...

Mit dem Zustand highload hab ichs gar nicht erst versucht...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Lowbird am 09 August 2016, 21:08:14
So Problem gefunden und eliminiert. Meine HUE-Brigde schien zu hängen. Auch mehrfaches rebooten half nicht. Also die Bridge von Hand resettet, neu gepairt, reboot gemacht.
Danach gewartet bis highload vorbei war und dann mal nach dem Klingelsensor geschaut.

Der war ja nun schon "angelernt", hatte aber bei STATE komischerweise jetzt "? ? ?" drei Fragezeichen.

Dann mal die Klingel gedrückt und nun geht er.

Hier mal das List:

Internals:
   CFGFN
   DEF        398BE6
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     11
   NAME       HM_398BE6
   NOTIFYDEV  global
   NR         200
   STATE      HM_398BE6 Short
   TYPE       CUL_HM
   lastMsg    No:05 - t:40 s:398BE6 d:2703CC 0103
   nanoCUL_MSGCNT 11
   nanoCUL_RAWMSG A0B05A240398BE62703CC0103::-59.5:nanoCUL
   nanoCUL_RSSI -59.5
   nanoCUL_TIME 2016-08-09 20:58:44
   protLastRcv 2016-08-09 20:58:44
   protSnd    10 last_at:2016-08-09 20:58:44
   protState  CMDs_done
   rssi_at_nanoCUL max:-59.5 lst:-59.5 min:-85.5 avg:-75.38 cnt:13
   Readings:
     2016-08-09 20:50:19   CommandAccepted yes
     2016-08-09 20:52:49   D-firmware      1.0
     2016-08-09 20:52:49   D-serialNr      MEQ0656787
     2016-08-09 20:52:50   PairedTo        0x2703CC
     2016-08-09 20:52:50   R-pairCentral   0x2703CC
     2016-08-09 20:52:50   R-sign          off
     2016-08-09 20:52:50   RegL_00.          02:01 05:00 0A:27 0B:03 0C:CC 14:06 18:00 00:00
     2016-08-09 20:52:50   RegL_01.          04:10 08:00 30:06 00:00
     2016-08-09 20:58:44   battery         ok
     2016-08-09 20:58:44   state           HM_398BE6 Short
     2016-08-09 20:58:44   trigDst_2703CC  noConfig
     2016-08-09 20:58:44   trigger         Short_3
     2016-08-09 20:58:44   trigger_cnt     3
   Helper:
     BNO        3
     BNOCNT     1
     HM_CMDNR   5
     cSnd       012703CC398BE601040000000001,012703CC398BE60103
     mId        00DC
     peerIDsRaw ,00000000
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       AunknCnt   1
       LRcTm      1153736
       LastRecTyp 40
       dwoCCAAa   120
       dwoCCAAw   120
       lastSend   1470769124.26695
       lastSendtgd 120
       newChn     +398BE6,00,00,00
       nextSend   1470769124.26695
       nextSendMcnt 05
       prefIO
       rxt        0
       tgtdly     120
       vccu
       p:
         398BE6
         00
         00
         00
     Mrssi:
       mNo        05
       Io:
         nanoCUL    -57.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         nanoCUL
       flg        A
       ts         1470769124.16285
       ack:
         HASH(0x68739f0)
         0580022703CC398BE600
     Rssi:
       At_nanocul:
         avg        -75.3846153846154
         cnt        13
         lst        -59.5
         max        -59.5
         min        -85.5
     Shadowreg:
Attributes:
   IODev      nanoCUL
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   peerIDs    00000000,
   room       CUL_HM
   serialNr   MEQ0656787
   subType    pushButton

Ansgar, ich werde ihn morgen eventuell nochmal unpairen und neu pairen, wenn du das Log auch noch benötigst. Jetzt muss ich erstmal in die Falle, war ja wie gesagt seit Donnerstag auf Dienstreise.
Danke euch allen, allen voran Ansgar, dass soviel Zeit und Mühe investiert wurde, um dieses "bockige" Device mit einem CUL zur Zusammenarbeit zu bewegen.


LG Chris
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 August 2016, 21:16:05
Hallo Chris,

das mit Warning-HighLoad hängt mit den credits zusammen und auch damit, dass ich mir das mit der 1% Regel mal durchgelesen habe.

Danach muss es eine 1%/h Sendezeitbeschränkung im Gerät geben und es darf keinen Befehl geben, um die Sendezeitbeschränkung im Gerät zurück zu setzen.
Blöderweise gibt es aber den Reboot Befehl, der leider auch die credits zurück setzt. Und volle "Aufladung" geht somit nicht.

Wenn Du also neu startest und auch den nanoCUL frisch mit Strom versorgt hast (oder auch ein Reset mit in den CUL Init integriert hast), dann geht erst mal nicht viel, bis die credits genügend "nachgeladen"sind. sprich, Du musst warten. 10% ist die Grenze für Warning-HighLoad und somit beim CUL Neustart normal. Immerhin kommt jetzt die Warnung und CUL_HM wird gebremst, CUL und das FHEM-System mit zwecklosen Sendbefehlen zu überfordern.

Wenn Du beim Start schon einiges an andere devices sendest, dann kann es auch sein, dass Du so das Sendelimit erreicht hast.

Bei den HM devices sollte autoReadReg auf 5_readMissing eingestellt sein, damit nicht unnötig Rgisterwerte vom device abgerufen werden und Du solltest HMinfo mit Archivierung nutzen, also so was

#################
# Homematic Info
#################

define HM_Info HMinfo
attr HM_Info autoArchive 1
attr HM_Info autoUpdate 08:00
attr HM_Info configDir /opt/fhem
attr HM_Info configFilename HM_Info_Save.dat
attr HM_Info room Receiver
attr HM_Info sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
attr HM_Info sumStatus battery,sabotageError,powerError,motor
in Deiner fhem.cfg stehen haben. Dann werden die schon gelesenen Registerwerte in HM_Info_Save.dat gespeichert und beim nächste fhem start wieder gelesen, statt sie vom device anzufordern und damit credits zu verschwenden.

Es wurde so auch in Deinem Log Auszug nichts an das device gesendet, nachdem Dein pairing request empfangen wurde.
Also warte einfach und probier es nochmal, wenn cond Warning-HighLoad nach cond ok wechselt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 August 2016, 22:33:55
Hallo Chris,

Zitat
Danke euch allen, allen voran Ansgar, dass soviel Zeit und Mühe investiert wurde, um dieses "bockige" Device mit einem CUL zur Zusammenarbeit zu bewegen.

Bitte, bitte. Allerdings sind wir damit nur bei einer Funktion mit meiner speziellen Version der Dateien und der Firmware und dem Grund für das Problem auf die Spur gekommen.
Ständig die Aktualisierungen von FHEM darin einzupflegen kann ich leider nicht dienstleisten. Ich hoffe Martin schafft mit diesen Hinweisen das Pairing und getConfig seiner 10_CUL_HM.pm mit CUL zu verbessern und das unabhängig von 00_CUL.pm und Firmware.

Sonst ist mit dem nächsten Update von FHEM wieder Schluss mit "Funktion" beim Anlernen des Klingelsensors mit CUL.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 August 2016, 10:30:21
Hallo Testwillige,

hier mein letzter Stand nochmal gesammelt (keine Änderungen an der Firmware).

Im perl Timing Code habe ich noch Änderungen bezüglich Wiederholungstiming vorgenomen.
Zusätzlich Formatierungsanpassungen, damit mit z.B. Notepad++ besser am Code gearbeitet werden kann.

Es gilt für den perl Code wie gehabt:
Erst Backup der vorhandenen Dateien und dann Austausch. Die Codebasis ist nicht der neueste Stand.

EDIT: Anhang gelöscht. Hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 (https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979) ist der neue Stand.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: davedeluxe am 20 August 2016, 11:38:50
Ich bekomme folgenden Fehler:
Compilation failed in require at ./FHEM/10_CUL_HM.pm line 10, <$fh> line 528.
BEGIN failed--compilation aborted at ./FHEM/10_CUL_HM.pm line 10, <$fh> line 52$
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 August 2016, 12:01:39
Hallo Dave,

das Problem kann ich leider nicht am Code nachvollziehen.

Aber eventuell hilft Dir das https://forum.fhem.de/index.php/topic,21924.msg153781.html#msg153781 (https://forum.fhem.de/index.php/topic,21924.msg153781.html#msg153781) "Thema: gelöst: Fehler FHEM 10_CUL_HM - Compilation failed" weiter.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: davedeluxe am 20 August 2016, 14:00:58
Hey,

wollte meinen Post grade entfernen oder updaten.
Meine Test-Fheminstallation ist grade  am spinnen und das war wohl der Grund für die Fehler.
Sorry fürs voreilige Posten, ich werds morgen nochmal in Ruhe testen und bin mir sicher es läuft - so wie immer ;)

Grüße Dave
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 03 September 2016, 13:57:42
Ich versuche mich gerade als Tester; nicht zuletzt um meine Displays benutzen zu können.

Die Module habe ich getauscht und die CUL_V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip geflasht.
Neustart und jetzt kann der CUL nicht mehr initialisiert werden...

Frage:
Kann ich die bereits enthaltene CUL-V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip nehmen oder muss ich den Sourcecode compilieren???

Vielen Dank für einen kurzen Tipp!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 September 2016, 14:32:42
Hallo Dog,

Zitat
Kann ich die bereits enthaltene CUL-V3.hex aus dem culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip nehmen oder muss ich den Sourcecode compilieren???

Wenn Deine CUL Hardware ein CUL V3 ist, dann kannst Du das Hex aus der Zip nehmen.
Bei nanoCUL z.B. musst Du dagegen nach ggf. nötiger Anpassung compilieren. Dazu gibt's hier im Thread einige Hinweise.

Wenn Du der Hardware entsprechend geflashed hast, dann würde Log Info mit verbose 4 oder 5 helfen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 03 September 2016, 14:54:48
Danke für die Info!

Ja, es ist ein CUL V3.4 - ich habe den CUL mit der 1.66 aus fhem/FHEM/firmware erst einmal wieder funktionstüchtig bekommen...
Was da schief gelaufen ist kann ich im Moment nicht mehr sagen...

Der CUL wurde zwar erkannt, weigerte sich jedoch Befehle entgegen zu nehmen.
Ich werde es später nochmals testen und berichten.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 03 September 2016, 15:28:26
Das Flashen der fertigen CUL_V3.hex läuft ohne Fehler durch.
Dann ersetzte ich lediglich die 00_CUL.pm in /opt/fhem/FHEM/.

Nach einem reboot kann der CUL nicht mehr initialisiert werden: Cannot init /dev/ttyACM0, ignoring it (CUL_0)
Das Ganze ist reversibel. Also kann's doch eigentlich kein Bedienerfehler sein!?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 September 2016, 15:50:18
Hallo Dog,

Zitat
Dann ersetzte ich lediglich die 00_CUL.pm in /opt/fhem/FHEM/.
und warum meinst Du, dass ich die anderen .pm Dateien mit ins zip gepackt habe?
DevIo.pm und 10_CUL_HM.pm müssen für Homematic auch minimal mit getauscht werden.

... danach zieh bitte mal CUL und steck ihn neu an. Vielleicht hilft noch ein Hard Reset des CUL.
Und setze bitte für CUL das attribut verbose auf 5 in der fhem.cfg -> Neustart und dann bitte nochmal das Log.

Auf einer Console bitte mal
lsusbausführen und schauen, ob da ein Atmel Corp. LUFA USB device auftaucht.
Möglicherweise hat Dein System CUL auf einen anderen Anschluss als /dev/ttyACM0 gemappt.
Dann mal einen System Neustart probieren.

EDIT: ein
dmesgzeigt Dir auch auf welche Schnittstelle CUL gemappt wurde.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 03 September 2016, 17:07:00
Hi Ansgar!
DevIo.pm und 10_CUL_HM.pm müssen für Homematic auch minimal mit getauscht werden.
Ja, hatte ich natürlich auch mitgenommen...
Zitat
dmesgzeigt Dir auch auf welche Schnittstelle CUL gemappt wurde.
Die beiden USB Geräte (CUL und ZWDongle) habe doch tatsächlich nach Flashen Deiner Firmware die devs getauscht und nach Flashen der 1.66er wieder zurück!?
Deswegen funktionierte alles wieder mit der ursprünglichen FW...

Ich kann jetzt endlich ein wenig testen.
Mir ist aufgefallen, dass im Log jetzt jede Menge CUL_XmitDlyHM und CUL_ParseTsHM Meldungen auftauchen.
Kann ich das später auf ein sinnvolles Maß reduzieren (verbose ist 3).
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 September 2016, 17:30:44
Hallo Dog,

Zitat
Die beiden USB Geräte (CUL und ZWDongle) habe doch tatsächlich nach Flashen Deiner Firmware die devs getauscht und nach Flashen der 1.66er wieder zurück!?
Das liegt dann vermutlich an der Seriennummer, die ich der Firmware mitgegeben habe. Dafür hat das Feature bei richtiger Nutzung auch seine Vorteile bei mehreren CULs im System.

Zitat
Kann ich das später auf ein sinnvolles Maß reduzieren (verbose ist 3).
Wenn Du verbose 3 nicht benötigst, dann einfach reduzieren auf 2 oder weniger.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 04 September 2016, 09:11:25
Moin Ansgar,

habe das zweite Display jetzt tatsächlich vollständig pairen können.
Ein getConfig läuft jedoch immer noch nicht vollständig ohne einen RESPONSE TIMEOUT (register oder peer read) durch.

Merkwürdigerweise hat Display Nr. 1 damit gar keine Probleme...
(Kann das eigentlich allein durch Bauteiltoleranzen verursacht werden?)

Ich habe einige (für mich) neue CUL Attribute gesehen.
Was bedeuten diese und die diversen neuen LOG Parameter genau?
(bspw: dhmSt, dHMtgt, dDly, tgtDly, toms, CCAdly, hmSioDly)

Und, an welchen Parametern kann/sollte ich schrauben um vielleicht eine Verbesserung herbei zu führen?
(Gibt es eine Doku, die ich noch nicht gefunden habe?)

Vielen Dank im Voraus!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 September 2016, 11:18:06
Hallo Dog,

Zitat
Merkwürdigerweise hat Display Nr. 1 damit gar keine Probleme...
(Kann das eigentlich allein durch Bauteiltoleranzen verursacht werden?)
Gleiche Firmware Version? Abstand / Hindernisse / Ausrichtung zu CUL (Funkprobleme)? Störsender? Lötfehler?

Zitat
Ein getConfig läuft jedoch immer noch nicht vollständig ohne einen RESPONSE TIMEOUT (register oder peer read) durch.
Dann bitte ein Log mit
attr global mseclog 1verbose 4 für den CUL und das device für solch einen getConfig.
Ausserdem ein list von CUL und dem device.
Welche 10_CUL_HM.pm verwendest Du?

dhmSt:     Zeitdifferenz auf CUL zwischen letztem Empfang vom device und dem Senden der Nachricht/Antwort
dHMtgt:    Ziel für die Zeitdifferenz, idealerweise sollte dhmSt diesen Wert annehmen
toms:       Sendeverzögerung an CUL auf FHEM Seite (Sendewarteschlange wird Timerbasiert abgearbeitet)
CCAdly:    zusätzliche Sendeverzögerung auf CUL verursacht durch Kanalbelegung
hmSioDly: Aus Kommunikation mit CUL, Sendequittungen etc. ermittelte Restverzögerung des IO zu CUL

Zitat
Gibt es eine Doku,
Es gibt diesen Thread und den Code.

Zitat
Und, an welchen Parametern kann/sollte ich schrauben um vielleicht eine Verbesserung herbei zu führen?
Ohne Log und Lists gibt die Glaskugel leider gar nichts her.  ;)
Ich weiss bisher nur, dass Du einen CUL V3.4 an einem Linux basierten System verwendest und Probleme bei Pairing und getConfig mit Displays hast. (device Hardware, die keinen Typ hat und die ich selber auch nicht besitze)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 September 2016, 12:36:34
Hallo Dog,

ich habe meine Glaskugel jetzt hier https://forum.fhem.de/index.php/topic,56839.msg483271.html#msg483271 (https://forum.fhem.de/index.php/topic,56839.msg483271.html#msg483271) etwas erhellen können. (Wäre nett und hilfreich gewesen, mir einen Link auf diesen Thread mitzuteilen)

Es ist möglich, dass sich die letzte Änderung von Martin bezüglich des Pairings, die wegen eines anderen Problemdevices (HM-Sen-DB-PCB) eingeflossen ist, jetzt bei dem Display HM-Dis-WM55 negativ bemerkbar macht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 04 September 2016, 13:08:08
Hi Ansgar,

vielen Dank für Deine Bemühungen und einmal mehr für Deine Suche nach meinem anderen Thread!!

Ich verlange gar keine mundgerechte Lösung für mein Problem. Vielmehr bin ich es gewohnt selbst nach Lösungen zu suchen und Fehler zu beseitigen. Deswegen meine Frage nach den Parametern und deren Auswirkungen.

Und - für mich - selbstverständlich habe ich mich bereits selbst auf die Suche nach den Unterschieden beider Displays gemacht und kann sämtliche von Dir genannten Fehlermöglichkeiten mit Sicherheit  (Lötfehler, Funkprobleme, Standort, Ausrichtung) oder an Sicherheit grenzender Wahrscheinlichkeit (Störsender) ausschliessen.

Zum Test habe ich BEIDE Displays an identischen Orten und derselben Firmware (1.0) unter identischen Bedingungen in Betrieb genommen.
Mit unterschiedlichen Ergebnissen. Selbst nach Austausch des zweiten vermeintlich defekten Displays.

Die Suche nach den Unterschieden beider Displays erachte ich momentan jedoch als nebensächlich.
Der derzeitige Funktionszustand ist zwar nicht 100%, aber für mich erst einmal ausreichend funktional.

Aus Interesse würde ich das in den nächsten Tagen gerne noch etwas verbessern.
Insbesondere der RESPONSE TIMEOUT fordert mich heraus...

Ich würde mich freuen, nochmals von Dir zu hören, wenn ich demnächst mit etwas detaillierteren Infos hier eintreffe.

Ein grosses DANKE aus Solingen!
Bernd
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 September 2016, 14:11:46
Hallo Bernd,

Zitat
Deswegen meine Frage nach den Parametern und deren Auswirkungen.
Es gibt zwar noch Timing Parameter, an denen man drehen kann, aber das erst auf Basis eines aussagekräftigen Logs, da es sonst nur zielloses Probieren ist.

Zitat
Zum Test habe ich BEIDE Displays an identischen Orten und derselben Firmware (1.0) unter identischen Bedingungen in Betrieb genommen.
OK das war gut so.
Aber zu deutlich unterschiedlichen Zeitpunkten mit FHEM Update(s) dazwischen, richtig?

Zitat
Ich würde mich freuen, nochmals von Dir zu hören, wenn ich demnächst mit etwas detaillierteren Infos hier eintreffe.
Nur aussagekräftige Logs helfen hier weiter. Mit meiner Firmware Variante und meinen geänderten FHEM Modulen bekomme ich sinnvolle Timing Infos.
Ggf. kann ich Protkollprobleme sehen, so weit ich sie verstehe. Zur Zeit vermute ich eher Protokollprobleme aus Deinen Log Auszügen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 04 September 2016, 14:32:14
Hi Ansgar,

nein, bei Erstinbetriebnahme lagen schon ca. 14 Tage zwischen Display Nr. 1 und Nr. 2.
Ich nahm ebenfalls zunächst eine Änderung in den Updates als Ursache an.

Habe dann aber gestern mit diversen Backups aus dem relevanten Zeitraum getestet und habe immer ein unterschiedliches Verhalten beobachten können. Auch zuletzt mit Deiner FW und den geänderten Modulen.

Nr. 1 begann unmittelbar nach Tastendruck mit der Übertragung (Wow - das war zuvor nie der Fall) Nr. 2 lässt sich mehrere Sekunden Zeit mit dem Start, überträgt dann einige Sekunden und ein wenig später gibt's dann den Timeout.

Aber wie angekündigt lasse ich dieses WE erst einmal die Finger von einer zumindest einsatzbereiten Konfiguration - bin froh das es dank Deiner Software funktioniert.

Nächstes WE werde ich dann gerne ein paar aussagekräftige Infos liefern und vielleicht gibt es eine Möglichkeit noch etwas zu verbessern.

LG Bernd
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 September 2016, 15:08:22
Hallo Bernd,

Zitat
nein, bei Erstinbetriebnahme lagen schon ca. 14 Tage zwischen Display Nr. 1 und Nr. 2.
am 14.8.16 hat Martin das Pairing Verhalten von 10_CUL_HM.pm mit Blick auf den Klingelsensor geändert.
War Display 1 da schon erfolgreich gepaired mit samt erfolgreichem getConfig?
Wenn ich Dein Thread Datum betrachte, müsste es so gewesen sein.

Zitat
Nr. 1 begann unmittelbar nach Tastendruck mit der Übertragung (Wow - das war zuvor nie der Fall) Nr. 2 lässt sich mehrere Sekunden Zeit mit dem Start, überträgt dann einige Sekunden und ein wenig später gibt's dann den Timeout.
Ein klein wenig Hintergrundwissen zum Protkoll und Martins Programmierung ist von Vorteil bei der Interpretation.

In Deinen Log Auszügen im Thread quaselt auch schon mal ein anderes Device dazwischen. Da Martin die verschiedenen Sendedaten nachdem Empfang des Request in einen Sendepuffer schiebt und die nach Empfang von Antworten (nicht unbedingt der wirklich passenden) dann nacheinander rausgeschocben werden, ist so ein dazwischen quaseln kontraproduktiv, da dabei die Protokollinterpretation meistens "divergiert" und auch das Timing zwangsweise durcheinander kommt (Display schläft schon wieder).
Daher kann Deine Interpretation bei zu seltener Wiederholung des Experiments und ohne Interpretation der Details (Logs) deutilich schief gehen. ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 September 2016, 14:54:42
Diese Version ist veraltet und die letzte wo 00_TSCUL.pm das wesentliche Timing macht.
Hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) geht es zu aktuellen Version.

Hallo Testwillige,

da die Integration in die "offizielle" Firmware und FHEM wegen Komplexität der mittlerweile aufgelaufenen Änderungen wohl nichts mehr werden wird, habe ich eine "AddOn" Lösung gebaut, die "Wartungsfreundlicher" ist, da sie quasi neben der normalen FHEM Installation laufen kann, wenn Rudolf und Martin ein paar kleine Änderungen übernehmen. Damit dann eine "updateresistente" Lösung.

Im Anhang ist in culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip wieder die unveränderte Timestamp Firmware zu finden.
Ergänzender Hinweis: Nach dem flashen von CUL kann es sein, dass das Betriebssystem CUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen. Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.

In der FHEM_module_changed_TS_9.zip sind die neuen und geänderten Module zu finden.

 00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
 DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
 CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
 16_TSSTACKED.pm -> statt der 16_STACKABLE_CC.pm, aus STACKABLE_CC werden damit TSSTACKED devices in der fhem.cfg (händisch anzupassen)

 10_TSIT.pm            -> statt der 10_IT.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus IT wird dann TSIT in der fhem.cfg (händisch anzupassen)
 10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
 13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen)
 14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
 14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
 CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

Da diese Module ergänzt werden, überleben sie auch ein Update von FHEM.

Für einen Mischbetrieb mit non-Timestamp CUL Modulen muss auch die 00_CUL.pm und 16_STACKABLE_CC.pm ausgetauscht werden, was ggf. bei gestapelten Modulen notwendig ist.

@Rudolf: Nur $clientsSlowRF etc und die Abfragen bezüglich CUL Typ sind angepasst gegenüber der "Standard" Version und werden mit Funktionen aus CUL_Util.pm gebildet -> damit leicht wartbar bei Änderungen und Ergänzungen. Die Änderungen sind mit "# ToDo TSCUL" markiert.
Kannst Du damit leben und das bitte in die Standard Version einfließen lassen? Danke!

10_CUL_HM.pm muss ebenfalls ausgetauscht werden, bis @Martin die Änderung in den Standard übernommen hat. Auch hier wird auf CUL_Util.pm zurück gegriffen, um den CUL Typ abzufragen. (Außerdem noch eine kleine Änderung zum PairRequest bezüglich Unterdrückung von Wiederholungen)

Wie immer, vor Austausch und Veränderungen der fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem update am ungewollten Austausch der angepassten Module hindern:
attr global exclude_from_update 00_CUL.pm 10_CUL_HM.pm 16_STACKABLE_CC.pm 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_TSIT.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm
Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 (https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057) noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.
fhem> { `perl contrib/commandref_join.pl` }
Gruß, Ansgar.

EDIT: FHEM_module_changed_TS_9.zip enthält aktualisierte TS-Module. Die Modul HTML Doku ist aktualisert, so dass nach einem Rebuild des FHEM Commandref auch die TS-Module im Commandref zu finden sind. 00_TSCUL.pm ist im Protokollsupport reduziert auf die obigen Module.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 15 September 2016, 20:18:43
Hallo Ansgar,

so nun lege ich mal los (bzw. fange damit an)...

Ich mache mal einen update aller fhem Installationen (hmusb-System, HMUART-System, und Test-System [spezial-CUL], damit müsste die Testumgebung ja wieder auf Original sein bis auf FW des CUL) und kopiere die (zusätzlichen) pm-Module aus dem Post.

EDIT: folgende habe ich nach /opt/fhem/FHEM/ kopiert:

00_CUL.pm
00_TSCUL.pm
10_CUL_HM.pm
10_TSIT.pm
10_UNIRoll_TS.pm
13_TSKS300.pm
14_TSCUL_TX.pm
14_TSCUL_WS.pm
16_TSSTACKED.pm
CalcUtil.pm
CUL_Util.pm
DevIoTS.pm


Dann ändere ich den CUL in TSCUL (falls das nicht automatisch geschieht).
EDIT: habe ich mal händisch gemacht (siehe list).


Hier noch ein list des nanoCUL nach den Arbeiten:

Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   HM_RptCnt  0
   NAME       nanoCUL_HM
   NR         44
   PARTIAL
   RAWMSG     AFF010004B291000CA0847031D1FE000000010B3708
   RSSI       -70
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 454
   nanoCUL_HM_TIME 2016-09-15 21:17:47
   owner_CCU  vccu
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-09-15 20:38:24   Xmit-Events     ok:1 disconnected:1 init:2 Warning-HighLoad:1
     2016-06-27 21:46:01   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:0.000kHz
     2016-09-15 20:36:32   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-09-15 20:38:24   cond            ok
     2016-05-06 00:05:19   credit10ms      900
     2016-08-10 20:11:18   hmSioDly        2
     2016-09-15 20:36:49   prot_Warning-HighLoad last
     2016-09-15 20:36:31   prot_disconnected last
     2016-09-15 20:36:33   prot_init       last
     2016-09-15 20:38:24   prot_ok         last
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-09-15 21:11:05   scF             1.00022197238458
     2016-09-15 20:36:32   state           Initialized
     2016-07-22 17:11:01   version         V 1.66 nanoCUL868
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    0
       hmSbusy    0
       Unknwn:
         2b1a82:
           aUnknCnt   12000000000
           lRcTm      2447376
           lstRecType 10
           nextSend   1473967052.10586
           nxtSndMcnt 05
           tgtDly     120
         2b8e86:
           aUnknCnt   14000000000
           lRcTm      2449120
           lstRecType 10
           nextSend   1473967053.84941
           nxtSndMcnt EF
           tgtDly     120
         2ba56b:
           aUnknCnt   15000000000
           lRcTm      2395912
           lstRecType 10
           nextSend   1473967000.62846
           nxtSndMcnt 71
           tgtDly     120
         2bbf72:
           aUnknCnt   15000000000
           lRcTm      2382728
           lstRecType 70
           nextSend   1473966987.44248
           nxtSndMcnt BF
           tgtDly     120
         2c8bfc:
           aUnknCnt   14000000000
           lRcTm      2438456
           lstRecType 10
           nextSend   1473967043.1807
           nxtSndMcnt 2C
           tgtDly     120
         2d9b77:
           aUnknCnt   15000000000
           lRcTm      2348048
           lstRecType 10
           nextSend   1473966952.75594
           nxtSndMcnt 8D
           tgtDly     120
         31d1fe:
           aUnknCnt   31000000000
           lRcTm      2462856
           lstRecType 70
           nextSend   1473967067.58828
           nxtSndMcnt A0
           tgtDly     120
         31d958:
           aUnknCnt   31000000000
           lRcTm      2394120
           lstRecType 70
           nextSend   1473966998.83465
           nxtSndMcnt BD
           tgtDly     120
         32185b:
           aUnknCnt   32000000000
           lRcTm      2391752
           lstRecType 70
           nextSend   1473966996.46663
           nxtSndMcnt FE
           tgtDly     120
         32279a:
           aUnknCnt   30000000000
           lRcTm      2370536
           lstRecType 70
           nextSend   1473966975.24673
           nxtSndMcnt B0
           tgtDly     120
         3227f4:
           aUnknCnt   31000000000
           lRcTm      2403632
           lstRecType 70
           nextSend   1473967008.34852
           nxtSndMcnt B7
           tgtDly     120
         322927:
           aUnknCnt   31000000000
           lRcTm      2341496
           lstRecType 70
           nextSend   1473966946.20206
           nxtSndMcnt 5C
           tgtDly     120
         3229b5:
           aUnknCnt   31000000000
           lRcTm      2331552
           lstRecType 70
           nextSend   1473966936.25574
           nxtSndMcnt CD
           tgtDly     120
         3515da:
           aUnknCnt   28000000000
           lRcTm      2150800
           lstRecType 02
           nextSend   1473966755.45921
           nxtSndMcnt 03
           tgtDly     120
         453732:
           aUnknCnt   31000000000
           lRcTm      2370688
           lstRecType 70
           nextSend   1473966975.39876
           nxtSndMcnt 49
           tgtDly     120
         4a347f:
           aUnknCnt   15000000000
           lRcTm      2382328
           lstRecType 5E
           nextSend   1473966987.04222
           nxtSndMcnt DE
           tgtDly     120
         999999:
           aUnknCnt   3000000000
           lRcTm      377432
           lstRecType 12
           nextSend   1473964981.70212
           nxtSndMcnt 99
           tgtDly     120
         Affe11:
           aUnknCnt   38000000000
           lRcTm      2150688
           lstRecType 11
           nextSend   1473966755.34681
           nxtSndMcnt 03
           tgtDly     120
         Affe22:
           aUnknCnt   18000000000
           lRcTm      1403424
           lstRecType 11
           nextSend   1473966007.92033
           nxtSndMcnt 07
           tgtDly     120
     Cnd:
       0          1
       2          1
       253        1
       255        2
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        22500
     Ref:
       Sdly       5
       hmDstDly   120
       ioByteRate 3840
       lHMt       2449120
       lSys       793271201
       nusew      32
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      15
       pngMax     7
       pngMin     7
       pngRef     7
       pngtm      792882700
       scErr      0.499999999767169
       scF        1.00022197238458
       scFN       2
       scHT       13160
       scST       790834700
Attributes:
   hmId       AFFE02
   hmLanQlen  1_min
   rfmode     HomeMatic
   verbose    4


Passt das so oder hab ich da was falsch verstanden?

Danach (falls keine Probleme oder Einspruch bzgl. "da hab ich was falsch gemacht") lege ich dann mal mit dem Mitlauschen etc. los...
EDIT: habe mal gepairt und getConfig gemacht und mitgelauscht...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 September 2016, 13:37:10
Hallo Joachim,

Zitat
EDIT: folgende habe ich nach /opt/fhem/FHEM/ kopiert:
Du hast die richtigen Dateien kopiert.

Zitat
Dann ändere ich den CUL in TSCUL (falls das nicht automatisch geschieht).
EDIT: habe ich mal händisch gemacht (siehe list).
Das war richtig. Und eine Automatik gibt es dabei nicht. Wird es wohl auch nicht geben, da ich nicht wissen kann, ob ein User den einen oder einen anderen CUL auf Timstamp  Firmware umstellen und nutzen möchte.

Zitat
Passt das so oder hab ich da was falsch verstanden?
Nur für HM passt das so.

Wenn noch IT, TX, WS, KS300 oder Uniroll mit CUL im Spiel sind, dann muss bei Umstellung des jeweiligen CUL/STACKABLE_CC auf TSCUL/TSSTACKED auch auf die jeweile TS Variante händisch umgestellt werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 17 September 2016, 20:12:44
Hi Ansgar,

ok, sehr schön.

Zitat
00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg

Klang halt ein wenig nach automatisch ;-)

Aber nachdem da nichts automatisch passiert ist habe ich ihn mal umdefiniert...

D.h. bis die Anpassungen (falls) in die 00_CUL.pm bzw. 10_CUL_HM.pm eingeflossen sind muss ich diese vom update ausschließen...

Danke, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 29 September 2016, 17:18:07
Hi Ansgar,

D.h. bis die Anpassungen (falls) in die 00_CUL.pm bzw. 10_CUL_HM.pm eingeflossen sind muss ich diese vom update ausschließen...

gibt es schon Rückmeldung bzgl. der Integration in 00_CUL.pm und 10_CUL_HM.pm??

Läuft bei mir gut soweit...
...wobei ich auf dem Testsystem nicht so viel damit mache (außer bei Bedarf ;-)  )...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 29 September 2016, 21:22:11
Hallo Joachim,

bis auf einen Daumen ;-) keine Rückmeldung.
Die Wunschliste scheint wohl nicht der richtige Ort dafür.
Oder das Interesse ist sehr bescheiden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 05 Oktober 2016, 11:30:38
Bei mir läuft aktuell die "normale" culfw sowie FHEM Module. Meine HM-Komponenten laufen soweit auch, allerdings beginnt es zu haken, wenn ich meine Rollladenaktoren auf SIGN ON schalte. Einen zu schalten funktioniert meistens noch, mehrere gleichzeitig geht grundsätzlich schief.

Klingt das nach einem Timing-Problem, wie es die alternative HM FW adressiert?

Falls ich die im Post #218 aufgeführten Komponenten bei mir einspiele, muss ich dann die 00_TSCUL zusätzlich über meine 00_CUL kopieren (oder verlinken), wenn ich noch weitere CULs nutze?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 Oktober 2016, 12:03:59
Hallo,

sorry falls ich mit meinem Post #221 (oder einem anderen) ein wenig Durcheinander rein gebracht haben sollte...

Eigentlich ist im genannten Post (#218) alles beschrieben.

"Einfach" die Module nach /opt/fhem/FHEM/ kopieren (sofern das dein Installationsort ist).
Vorher natürlich Backup!

Danach aus den IODevs vom Typ CUL den Typ TSCUL machen...
..."umdefinieren"...
(ich hab's einfach in der fhem.cfg geändert / SOLL MAN ABER NICHT! ;-)  )

Dann (bis die Integration stattgefunden hat) die 00_CUL.pm und 10_CUL_HM.pm vom Update ausnehmen (habe ich aktuell so gemacht), weil sonst werden die ja wieder überschrieben...
...daher würde ich mir eine Integration wünschen bzw. eine Strategie hierfür (ich finde den Parallelbetrieb wie er hier vorgeschlagen wurde gut)...

--------------------------------------------------------------------
EDIT: ich nutze nur HM, daher reichen wohl die genannten Module vom Update auszuschließen bzw. habe ich selbst vergessen CUL_Util.pm auszuschließen (werde ich gleich noch tun! ;-)  ).
Ansonsten wie im Post #218 geschrieben:

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem update am ungewollten Austausch der angepassten Module hindern:

attr global exclude_from_update 00_CUL.pm 10_CUL_HM.pm 16_STACKABLE_CC.pm 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_TSIT.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm
--------------------------------------------------------------------

Und natürlich die entsprechende FW auf den CUL flashen!



Ob das Problem ein Timing-Problem ist kann ich leider nicht sagen (nutze [noch] kein AES/signing)...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 05 Oktober 2016, 12:07:21
Danke dir, jetzt habe ich die Prozedur verstanden!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 05 Oktober 2016, 17:59:40
Und nochmal eine Frage: Im CUL-Archiv aus Post #218 sind ja schon HEX-Dateien enthalten.
Kann ich die CULv3 für meinen nanoCUL verwenden oder muss ich selbst kompilieren?

Falls letzteres, welche Libraries brauche ich da noch, ich bekomme zig Fehler a la
In file included from /usr/lib/avr/include/avr/io.h:99:0,
                 from /usr/lib/avr/include/avr/pgmspace.h:88,
                 from ../../clib/rf_asksin.c:20:
../../clib/rf_asksin.c: In function ‘rf_asksin_task’:
../../clib/spi.h:119:82: error: ‘SPI_CC1101_READ_SPECIAL_PIN’ undeclared (first use in this function)
 # define SPI_READ_BUF_ACTIVATE_GDO0_CHK()   SPI_CC1101_READ_SPECIAL_PORT |=  _BV(SPI_CC1101_READ_SPECIAL_PIN)
                                                                                  ^
../../clib/rf_asksin.c:512:5: note: in expansion of macro ‘SPI_READ_BUF_ACTIVATE_GDO0_CHK’
     SPI_READ_BUF_ACTIVATE_GDO0_CHK();               // do GDO0 check while reading payload from RX-FIFO
     ^
../../clib/spi.h:119:82: note: each undeclared identifier is reported only once for each function it appears in
 # define SPI_READ_BUF_ACTIVATE_GDO0_CHK()   SPI_CC1101_READ_SPECIAL_PORT |=  _BV(SPI_CC1101_READ_SPECIAL_PIN)
                                                                                  ^
../../clib/rf_asksin.c:512:5: note: in expansion of macro ‘SPI_READ_BUF_ACTIVATE_GDO0_CHK’
     SPI_READ_BUF_ACTIVATE_GDO0_CHK();               // do GDO0 check while reading payload from RX-FIFO
     ^
makefile:338: recipe for target '../../clib/rf_asksin.o' failed
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 Oktober 2016, 20:13:33
Hi,

soweit mir bekannt sind die für Original-CULs...

Ich hab meine FW selbst compiliert und geflasht...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 Oktober 2016, 20:16:12
Bzgl. der Fehlermeldungen mal die Board.h anpassen...

Einige (mehrere) Posts weiter vorne habe ich mal beschrieben was ich so eingestellt hab...

Sorry, dass so kurz aber mobil...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 05 Oktober 2016, 20:36:40
Danke, hat geholfen!

Habe immer noch viele Warnings:
../../clib/ttydata.c:349:9: note: #pragma message: USE_TTYDATA_NO_FUNCTION_CODE IS ACTIVE
 #pragma message "USE_TTYDATA_NO_FUNCTION_CODE IS ACTIVE"
         ^
Compiling C: ../../clib/fht.c
Compiling C: ../../clib/rf_receive.c
../../clib/rf_receive.c:41:9: note: #pragma message: HAS_RF_RECEIVE_FILTER_ADAPTION IS ACTIVE
 #pragma message "HAS_RF_RECEIVE_FILTER_ADAPTION IS ACTIVE"
         ^
In file included from ../../clib/rf_receive.c:44:0:
../../clib/rf_receive_timing.h:81:9: note: #pragma message: WS_WSREPEATER_OVRSH: (984-856)
 #pragma message "WS_WSREPEATER_OVRSH: " STR(WS_WSREPEATER_OVRSH)
         ^
../../clib/rf_receive_timing.h:674:9: note: #pragma message: MIN_MATCHKEY_HIGHLOW_TIME: 304
 #pragma message "MIN_MATCHKEY_HIGHLOW_TIME: " STR(MIN_MATCHKEY_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:675:9: note: #pragma message: MAX_MATCHKEY_HIGHLOW_TIME: 1256
 #pragma message "MAX_MATCHKEY_HIGHLOW_TIME: " STR(MAX_MATCHKEY_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:677:9: note: #pragma message: MIN_MATCHKEY_SUM_TIME: 720
 #pragma message "MIN_MATCHKEY_SUM_TIME: " STR(MIN_MATCHKEY_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:678:9: note: #pragma message: MAX_MATCHKEY_SUM_TIME: 2232
 #pragma message "MAX_MATCHKEY_SUM_TIME: " STR(MAX_MATCHKEY_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:680:9: note: #pragma message: MIN_MANCHESTER_HIGHLOW_TIME: 250
 #pragma message "MIN_MANCHESTER_HIGHLOW_TIME: " STR(MIN_MANCHESTER_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:681:9: note: #pragma message: MAX_MANCHESTER_HIGHLOW_TIME: 1000
 #pragma message "MAX_MANCHESTER_HIGHLOW_TIME: " STR(MAX_MANCHESTER_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:683:9: note: #pragma message: MIN_MANCHESTER_SUM_TIME: 500
 #pragma message "MIN_MANCHESTER_SUM_TIME: " STR(MIN_MANCHESTER_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:684:9: note: #pragma message: MAX_MANCHESTER_SUM_TIME: 2000
 #pragma message "MAX_MANCHESTER_SUM_TIME: " STR(MAX_MANCHESTER_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:686:9: note: #pragma message: MIN_PROTOCOL_HIGHLOW_TIME: 96
 #pragma message "MIN_PROTOCOL_HIGHLOW_TIME: " STR(MIN_PROTOCOL_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:687:9: note: #pragma message: MAX_PROTOCOL_HIGHLOW_TIME: 1256
 #pragma message "MAX_PROTOCOL_HIGHLOW_TIME: " STR(MAX_PROTOCOL_HIGHLOW_TIME)
         ^
../../clib/rf_receive_timing.h:689:9: note: #pragma message: MIN_PROTOCOL_SUM_TIME: 500
 #pragma message "MIN_PROTOCOL_SUM_TIME: " STR(MIN_PROTOCOL_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:690:9: note: #pragma message: MAX_PROTOCOL_SUM_TIME: 2232
 #pragma message "MAX_PROTOCOL_SUM_TIME: " STR(MAX_PROTOCOL_SUM_TIME)
         ^
../../clib/rf_receive_timing.h:692:9: note: #pragma message: SILENCE_SYNC_START:   ((12160 + 500 + 8) / 8) * 8
 #pragma message "SILENCE_SYNC_START:   " STR(SILENCE_SYNC_START * 8)
         ^
../../clib/rf_receive_timing.h:693:9: note: #pragma message: SILENCE_SYNC_ZERO:    ((2232 + (96 * 21/4)) / 8) * 8
 #pragma message "SILENCE_SYNC_ZERO:    " STR(SILENCE_SYNC_ZERO * 8)
         ^
../../clib/rf_receive_timing.h:694:9: note: #pragma message: SILENCE:              ((1220 + (96 * 5)) / 8) * 8
 #pragma message "SILENCE:              " STR(SILENCE * 8)
         ^
../../clib/rf_receive_timing.h:696:9: note: #pragma message: Max_Sync_Zero_Start_High_Time:    ((((1264 + ((96 * 2) * 3/2)) / 8)) * 8)
 #pragma message "Max_Sync_Zero_Start_High_Time:    " STR(TO_1US_SCALE(Max_Sync_Zero_Start_High_Time))
         ^
../../clib/rf_receive_timing.h:697:9: note: #pragma message: Max_Sync_Zero_Start_Low_Time:     ((((1000 + ((96 * 2) * 3/2)) / 8)) * 8)
 #pragma message "Max_Sync_Zero_Start_Low_Time:     " STR(TO_1US_SCALE(Max_Sync_Zero_Start_Low_Time))
         ^
../../clib/rf_receive_timing.h:699:9: note: #pragma message: MATCH_SYNC_LIMIT:   (((((((96 * 3) + ((984-856) * 2)) * 9/8)) / 8)) * 8)
 #pragma message "MATCH_SYNC_LIMIT:   " STR(TO_1US_SCALE(MATCH_SYNC_LIMIT))
         ^
../../clib/rf_receive_timing.h:700:9: note: #pragma message: MATCH_ADDBIT_LIMIT: ((((((96 * 3) + ((984-856) * 2))) / 8)) * 8)
 #pragma message "MATCH_ADDBIT_LIMIT: " STR(TO_1US_SCALE(MATCH_ADDBIT_LIMIT))
         ^
../../clib/rf_receive_timing.h:702:9: note: #pragma message: Min_FilterTimeLimit:          ((((22 + 8) / 8)) * 8)
 #pragma message "Min_FilterTimeLimit:          " STR(TO_1US_SCALE(Min_FilterTimeLimit))
         ^
../../clib/rf_receive_timing.h:703:9: note: #pragma message: Max_FilterInTimeLimit:        (((((((65536 / 4) - 1) * 8)) / 8)) * 8)
 #pragma message "Max_FilterInTimeLimit:        " STR(TO_1US_SCALE(Max_FilterInTimeLimit))
         ^
../../clib/rf_receive_timing.h:705:9: note: #pragma message: Sync_Start_High_FilterTime:   ((((22 + 8) / 8)) * 8)
 #pragma message "Sync_Start_High_FilterTime:   " STR(TO_1US_SCALE(Sync_Start_High_FilterTime))
         ^
../../clib/rf_receive_timing.h:706:9: note: #pragma message: Sync_Start_Low_FilterTime:    ((((22 + 8) / 8)) * 8)
 #pragma message "Sync_Start_Low_FilterTime:    " STR(TO_1US_SCALE(Sync_Start_Low_FilterTime))
         ^
../../clib/rf_receive_timing.h:707:9: note: #pragma message: Sync_Start_High_FilterInTime: ((((12000 - 8) / 8)) * 8)
 #pragma message "Sync_Start_High_FilterInTime: " STR(TO_1US_SCALE(Sync_Start_High_FilterInTime))
         ^
../../clib/rf_receive_timing.h:708:9: note: #pragma message: Sync_Start_Low_FilterInTime:  ((((12160 - 8) / 8)) * 8)
 #pragma message "Sync_Start_Low_FilterInTime:  " STR(TO_1US_SCALE(Sync_Start_Low_FilterInTime))
         ^
../../clib/rf_receive_timing.h:709:9: note: #pragma message: Sync_Zero_High_FilterTime:    ((((22 + 8) / 8)) * 8)
 #pragma message "Sync_Zero_High_FilterTime:    " STR(TO_1US_SCALE(Sync_Zero_High_FilterTime))
         ^
../../clib/rf_receive_timing.h:710:9: note: #pragma message: Sync_Zero_Low_FilterTime:     ((((22 + 8) / 8)) * 8)
 #pragma message "Sync_Zero_Low_FilterTime:     " STR(TO_1US_SCALE(Sync_Zero_Low_FilterTime))
         ^
../../clib/rf_receive_timing.h:715:9: note: #pragma message: Min_FilterTime:        ((((96 / 3) / 8)) * 8)
 #pragma message "Min_FilterTime:        " STR(TO_1US_SCALE(Min_FilterTime))
         ^
../../clib/rf_receive_timing.h:716:9: note: #pragma message: Max_FilterInTimeHigh:  ((((1256 + ((96 * 2) * 9/8)) / 8)) * 8)
 #pragma message "Max_FilterInTimeHigh:  " STR(TO_1US_SCALE(Max_FilterInTimeHigh))
         ^
../../clib/rf_receive_timing.h:717:9: note: #pragma message: Max_FilterInTimeLow:   ((((1256 + ((96 * 2) * 9/8) + (984-856)) / 8)) * 8)
 #pragma message "Max_FilterInTimeLow:   " STR(TO_1US_SCALE(Max_FilterInTimeLow))
         ^
../../clib/rf_receive_timing.h:718:9: note: #pragma message: Def_FilterDTSpikeHigh: ((((((96 * 2) * 9/8)) / 8)) * 8)
 #pragma message "Def_FilterDTSpikeHigh: " STR(TO_1US_SCALE(Def_FilterDTSpikeHigh))
         ^
../../clib/rf_receive_timing.h:719:9: note: #pragma message: Def_FilterDTSpikeLow:  ((((((96 * 2) * 9/8) + (984-856)) / 8)) * 8)
 #pragma message "Def_FilterDTSpikeLow:  " STR(TO_1US_SCALE(Def_FilterDTSpikeLow))
         ^
../../clib/rf_receive_timing.h:720:9: note: #pragma message: Def_FilterDTUpperHigh: ((((((96 * 2) * 9/8)) / 8)) * 8)
 #pragma message "Def_FilterDTUpperHigh: " STR(TO_1US_SCALE(Def_FilterDTUpperHigh))
         ^
../../clib/rf_receive_timing.h:721:9: note: #pragma message: Def_FilterDTUpperLow:  ((((((96 * 2) * 9/8) + (984-856)) / 8)) * 8)
 #pragma message "Def_FilterDTUpperLow:  " STR(TO_1US_SCALE(Def_FilterDTUpperLow))
         ^
../../clib/rf_receive_timing.h:784:9: note: #pragma message: MIN_SYNC_BITS: 7
 #pragma message "MIN_SYNC_BITS: " STR(MIN_SYNC_BITS)
         ^
../../clib/rf_receive.c:50:9: note: #pragma message: CALCTIME_TIMER_TCNTn IS USED FOR CALC TIME MEASUREMENT IN 1US UNITS
 #pragma message "CALCTIME_TIMER_TCNTn IS USED FOR CALC TIME MEASUREMENT IN 1US UNITS"
         ^
../../clib/rf_receive.c:58:9: note: #pragma message: HAS_TX3 IS ACTIVE
 #pragma message "HAS_TX3 IS ACTIVE"
         ^
../../clib/rf_receive.c:62:9: note: #pragma message: HAS_ESA IS ACTIVE
 #pragma message "HAS_ESA IS ACTIVE"
         ^
../../clib/rf_receive.c:66:9: note: #pragma message: HAS_IT IS ACTIVE
 #pragma message "HAS_IT IS ACTIVE"
         ^
../../clib/rf_receive.c:70:9: note: #pragma message: HAS_REVOLT IS ACTIVE
 #pragma message "HAS_REVOLT IS ACTIVE"
         ^
../../clib/rf_receive.c:74:9: note: #pragma message: HAS_RF_RECEIVE_KEYING IS ACTIVE
 #pragma message "HAS_RF_RECEIVE_KEYING IS ACTIVE"
         ^
../../clib/rf_receive.c:82:9: note: #pragma message: LONG_PULSE IS ACTIVE
 #pragma message "LONG_PULSE IS ACTIVE"
         ^
../../clib/rf_receive.c:90:9: note: #pragma message: HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX IS ACTIVE
 #pragma message "HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX IS ACTIVE"
         ^
../../clib/rf_receive.c:92:9: note: #pragma message: HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC IS ACTIVE
 #pragma message "HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC IS ACTIVE"
         ^
../../clib/rf_receive.c:181:9: note: #pragma message: HAS_SLOWRF_RECTO_ACTION IS ACTIVE
 #pragma message "HAS_SLOWRF_RECTO_ACTION IS ACTIVE"
         ^
Compiling C: ../../clib/rf_router.c
Compiling C: ../../clib/rf_send.c
../../clib/rf_send.c: In function ‘sendraw’:
../../clib/rf_send.c:708:9: note: #pragma message: HAS_RAWSEND_FORCE_IDLE_BEFORE_TX IS ACTIVE
 #pragma message "HAS_RAWSEND_FORCE_IDLE_BEFORE_TX IS ACTIVE"
         ^
Compiling C: ../../clib/rf_credits.c
../../clib/rf_credits.c:16:9: note: #pragma message: USES_RF_CALC_CREDITS_BYTE_RATE IS ACTIVE
 #pragma message "USES_RF_CALC_CREDITS_BYTE_RATE IS ACTIVE"
         ^
../../clib/rf_credits.c:66:9: note: #pragma message: USES_RF_CALC_CREDITS_TIME16US IS ACTIVE
 #pragma message "USES_RF_CALC_CREDITS_TIME16US IS ACTIVE"
         ^
Compiling C: ../../clib/clock.c
../../clib/clock.c:51:9: note: #pragma message: HAS_GET_TIMESTAMP IS ACTIVE
 #pragma message "HAS_GET_TIMESTAMP IS ACTIVE"
         ^
Compiling C: ../../clib/delay.c
Compiling C: ../../clib/rf_asksin.c
../../clib/rf_asksin.c:61:9: note: #pragma message: HAS_ASKSIN_FUP IS ACTIVE
 #pragma message "HAS_ASKSIN_FUP IS ACTIVE"
         ^
../../clib/rf_asksin.c:65:9: note: #pragma message: HAS_ASKSIN_TIMESTAMP IS ACTIVE
 #pragma message "HAS_ASKSIN_TIMESTAMP IS ACTIVE"
         ^
../../clib/rf_asksin.c:69:9: note: #pragma message: HAS_ASKSIN_PING IS ACTIVE
 #pragma message "HAS_ASKSIN_PING IS ACTIVE"
         ^
../../clib/rf_asksin.c:73:9: note: #pragma message: HAS_ASKSIN_SEND_TIMESTAMP IS ACTIVE
 #pragma message "HAS_ASKSIN_SEND_TIMESTAMP IS ACTIVE"
         ^
../../clib/rf_asksin.c:77:9: note: #pragma message: HAS_ASKSIN_NO_COMMAND_ERROR_HINT IS ACTIVE
 #pragma message "HAS_ASKSIN_NO_COMMAND_ERROR_HINT IS ACTIVE"
         ^
../../clib/rf_asksin.c:85:9: note: #pragma message: HAS_CC1101_TX_CCA IS ACTIVE
 #pragma message "HAS_CC1101_TX_CCA IS ACTIVE"
         ^
../../clib/rf_asksin.c:463:10: note: #pragma message: ASKSIN_RX_FIFO_SIG_MODE
 # pragma message "ASKSIN_RX_FIFO_SIG_MODE"
          ^
Compiling C: ../../clib/cc1101_pllcheck.c
../../clib/cc1101_pllcheck.c:49:9: note: #pragma message: HAS_CC1101_FORCE_RX_CAL IS ACTIVE
 #pragma message "HAS_CC1101_FORCE_RX_CAL IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:52:9: note: #pragma message: HAS_CC1101_FORCE_CAL_MANUAL IS ACTIVE
 #pragma message "HAS_CC1101_FORCE_CAL_MANUAL IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:55:9: note: #pragma message: HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX IS ACTIVE
 #pragma message "HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:58:9: note: #pragma message: HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC IS ACTIVE
 #pragma message "HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:62:9: note: #pragma message: HAS_CC1101_PLL_LOCK_CHECK IS ACTIVE
 #pragma message "HAS_CC1101_PLL_LOCK_CHECK IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:65:9: note: #pragma message: HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT IS ACTIVE
 #pragma message "HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:75:9: note: #pragma message: HAS_CC1101_RX_INTEN IS ACTIVE
 #pragma message "HAS_CC1101_RX_INTEN IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:78:9: note: #pragma message: HAS_CC1101_TX_CCA IS ACTIVE
 #pragma message "HAS_CC1101_TX_CCA IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:81:9: note: #pragma message: HAS_CC1101_TX_INTDIS IS ACTIVE
 #pragma message "HAS_CC1101_TX_INTDIS IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:84:9: note: #pragma message: HAS_CC1101_TX_CCA_INTDIS IS ACTIVE
 #pragma message "HAS_CC1101_TX_CCA_INTDIS IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:88:9: note: #pragma message: HAS_CC1101_RX IS ACTIVE
 #pragma message "HAS_CC1101_RX IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:91:9: note: #pragma message: HAS_CC1101_TX IS ACTIVE
 #pragma message "HAS_CC1101_TX IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:95:9: note: #pragma message: HAS_CC1101_TO_STATE IS ACTIVE
 #pragma message "HAS_CC1101_TO_STATE IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:98:9: note: #pragma message: HAS_CC1101_TO_STATE_STROBE_ACK IS ACTIVE
 #pragma message "HAS_CC1101_TO_STATE_STROBE_ACK IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:101:9: note: #pragma message: HAS_CC1101_WAIT_STATE IS ACTIVE
 #pragma message "HAS_CC1101_WAIT_STATE IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:105:9: note: #pragma message: HAS_CC1101_PLL_LOCK_CHECK_MSG_SW IS ACTIVE
 #pragma message "HAS_CC1101_PLL_LOCK_CHECK_MSG_SW IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:108:9: note: #pragma message: HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX IS ACTIVE
 #pragma message "HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:111:9: note: #pragma message: HAS_CC1101_PLL_LOCK_CHECK_MSG IS ACTIVE
 #pragma message "HAS_CC1101_PLL_LOCK_CHECK_MSG IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:114:9: note: #pragma message: HAS_CC1101_PLL_ERROR_MSG IS ACTIVE
 #pragma message "HAS_CC1101_PLL_ERROR_MSG IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:118:9: note: #pragma message: HAS_CC1101_PLL_LOCK_CHECK_MSG_CALSTATE IS ACTIVE
 #pragma message "HAS_CC1101_PLL_LOCK_CHECK_MSG_CALSTATE IS ACTIVE"
         ^
../../clib/cc1101_pllcheck.c:122:9: note: #pragma message: HAS_CC1101_RECOVER_RX_OVERFLOW_RX IS ACTIVE
 #pragma message "HAS_CC1101_RECOVER_RX_OVERFLOW_RX IS ACTIVE"
         ^
Compiling C: ../../clib/spi.c
../../clib/spi.c:53:9: note: #pragma message: HAS_SPI_SEND_INLINE IS ACTIVE
 #pragma message "HAS_SPI_SEND_INLINE IS ACTIVE"
         ^
../../clib/spi.c:59:9: note: #pragma message: HAS_SPI_SEND_PGMDATA IS ACTIVE
 #pragma message "HAS_SPI_SEND_PGMDATA IS ACTIVE"
         ^
../../clib/spi.c:109:9: note: #pragma message: HAS_SPI_SEND_EEDATA IS ACTIVE
 #pragma message "HAS_SPI_SEND_EEDATA IS ACTIVE"
         ^
../../clib/spi.c:183:9: note: #pragma message: HAS_SPI_SEND_BUF IS ACTIVE
 #pragma message "HAS_SPI_SEND_BUF IS ACTIVE"
         ^
../../clib/spi.c:234:9: note: #pragma message: HAS_SPI_READ_BUF IS ACTIVE
 #pragma message "HAS_SPI_READ_BUF IS ACTIVE"
         ^
../../clib/spi.c:237:10: note: #pragma message: HAS_SPI_READ_BUF_WITH_GDO0_CHECK IS ACTIVE
 # pragma message "HAS_SPI_READ_BUF_WITH_GDO0_CHECK IS ACTIVE"
          ^
../../clib/spi.c: In function ‘spi_init’:
../../clib/spi.c:437:9: note: #pragma message: SPI_SS CONFIGURED AS OUTPUT
 #pragma message "SPI_SS CONFIGURED AS OUTPUT"
         ^
Compiling C: ../../clib/cc1101.c
../../clib/cc1101.c:619:9: note: #pragma message: HAS_CC1101_RXFIFO_BURSTREAD IS ACTIVE
 #pragma message "HAS_CC1101_RXFIFO_BURSTREAD IS ACTIVE"
         ^

Der Compile läuft aber durch und ich habe jetzt ein Binary, mit dem ich weitermachen kann.

Danke erst mal soweit!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Oktober 2016, 22:12:56
Hallo Weini,

was Du jetzt noch im compiler output gesehen hast sind nur eingebaute messages, mit denen ich sehen, ob die bedingte Compilierung richtig funktioniert.

Wichtig ist, dass Du im richtigen Verzeichnis die board.h entsprechend der physikalischen I/O Belegung etc. richtig angepasst hast.
Außerdem ist der Speicher beim nanoCUL recht klein, so dass die Auswahl der glieichzeitig eincompilierbaren Funktionen sehr beschränkt ist.
Daher Vorsicht bei der Aktivierung weiterer Funktionen in der board.h. Besser ist abzuschalten (auskommentieren) was nicht benötigt wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 08 Oktober 2016, 13:09:44
Die Installation habe ich wunderbar hinbekommen, leider besteht mein Problem aber mit der neuen Lösung genauso: Wenn ich für meine Rollläden AES aktiviere (set SIGN ON) und dann mit einem Wildcard mehrere gleichzeitig laufen lassen will, dann funktioniert das nicht. Die Rollläden mit SIGN OFF funktionieren dagegen einwandfrei.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 Oktober 2016, 14:55:23
Hallo Weini,

AES bedeutet, dass ein Kommando an das device gesendet wird, dieses mit einem signing Request antwortet, die signing Antwort gesendet werden muss und schließlich dass device mit einem ACK antworteten muss. Ohne AES sendet CUL das Kommando und es wird direkt ausgeführt und das device sendet ein ACK dazu.

Wenn Du allso mit AES an alle Rolläden gleichzeitig ein Kommando senden möchtes, dann muss die Kommunikation dennoch nacheinander für jeden Rolladen bis zum ACK ablaufen, damit das Protokoll so ablaufen und funktionieren kann.

Einen einzelnen Rollanden mit AES zu steuern klappt jetzt problemlos?

Du kannst mal mit dem Attribut "hmLanQlen" beim HM TSCUL spielen, ob sich damit was ändert. Default ist 1_low. Versuch mal 2 und schaue, ob Du damit 2 Rolläden gleichzeitig ansteuern kannst.
Eine Lösung wäre das jedoch nicht, da damit von TSCUL nur 2 Warteschalngen für Befehle zugelassen werden, bevor CUL_HM "gebremst" wird. Das Timing in Luft und FHEM wird damit kritisch belastet. Wenn diese Aktoren diesbezüglich weniger kritisch sind, kann das etwas helfen, bei anderen Aktoren aber zu problemen führen.
Die TSculfw kann immer nur eine Antwort gleichzeit zeitgerecht verzögern. Weitere landen in der Befehlwarteschalnnge respektive im Kommunikationspuffer und werden dann sehr wahrscheinlich nicht mehr passend verzögert ausgeführt.

Generell würde dass aber nur eine Ansteuerschwäche zeigen, wobei die Frage ist, ob CUL_HM das besser lösen muss, oder ob die Wildcard Schaltaktion FHEM intern bis Quittung/Zusandsänderung serialisert angepasst werden müsste, um das zu ermöglichen, was Du möchtest.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 08 Oktober 2016, 15:07:30
Hi Ansgar!

Prinzipielle Funktionsweise von AES ist soweit klar.

Ja, einen einzelnen Rolladen kann ich steuern. Manchmal habe ich NOACKs, das ist aber selten. Sobald ich aber nur 2 Aktoren gleichzeitig über einen SET Befehl mit Wildcard ansteuern will tut sich nichts mehr. Wenn einige Aktoren unsigniert und andere signiert kommuniziren, dann laufen die unsignierten durchgängig an, die signierten tun durchgängig gar nichts.

Und: Diese Verhalten ist identisch zum "normalen" CUL.pm mit Standard culfw und deiner modifizierten Variante.

Ich habe das hier https://forum.fhem.de/index.php/topic,58009.0.html (https://forum.fhem.de/index.php/topic,58009.0.html) schon mal beschrieben, nur leider kein Feedback dazu bekommen.

Mein Plan ist jetzt, dass ich mir einen HM-MOD-RPI-PCB anschaffe und über einen USB-TTL Wandler an Stelle des CUL anschließe. In meinem RasPI ist die GPIO-Leiste schon blockiert, daher dieser Weg.

Irgendwie scheint beim CUL-Ansatz in Verbindung mit AES noch "der Wurm" drin zu sein.


Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 Oktober 2016, 20:19:46
Hallo Christian,

ich habe mal zwei HM-LC-SW1-BA-PCB auf AES umgestellt.

Diese kann ich mit

Zitat
set HM_Sw_.* off

quasi gleichzeitig ausschalten (mit on auch einschalten). Natürlich mit "sign on" aktiv.

Mit dem TSCUL Attribut "hmLanQlen" auf "1_min" klappt das am besten.
Die Sets werden dann nacheinander für die devices abgearbeitet.

Allerdings gibt es naturgemäß Probleme, wenn die credits zu Ende gehen. Wenn Du also bei TSCUL "cond" "High-Load" oder schlechter hattest oder dabei erreicht hast, kann das natürlich scheitern.
Mal warten, bis die credits bei TSCUL "aufgeladen" sind, kann also auch helfen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Oktober 2016, 10:53:22
Hallo Testwillige,

https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 (https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979) ist aktualisert. Ich habe die Modul HTML Doku für das Commandref für die TS-Module aktualisert.

Derzeit kenne ich leider nur ein FHEM update mit einem Update eines Moduls als Möglichkeit die Commandref neu zu erzeugen, aber vielleicht kennt jemand einen Befehl dazu.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 09 Oktober 2016, 12:45:47
Zitat
Derzeit kenne ich leider nur ein FHEM update mit einem Update eines Moduls als Möglichkeit die Commandref neu zu erzeugen, aber vielleicht kennt jemand einen Befehl dazu.

fhem> { `perl contrib/commandref_join.pl` }
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 09 Oktober 2016, 15:04:21
Hallo Ansgar!

Erst mal vielen lieben Dank für deine Testunterstützung!

Bei mir funktioniert es leider auch mit 2 Aktoren nicht. Hier der relevante Log-Auszug:
2016-10-09_14:47:18 WoZi_ErkerLi_Rollo set_off
2016-10-09_14:47:18 WoZi_ErkerMi_Rollo set_off
2016-10-09_14:47:19 WoZi_ErkerLi_Rollo aesKeyNbr: 02
2016-10-09_14:47:19 WoZi_ErkerLi_Rollo RAWMSG: A110FA0024AD27AD3AA7804FC68F403DBF202::-60.5:nanoCULHomeMatic
2016-10-09_14:47:19 WoZi_ErkerLi_Rollo RSSI: -60.5
2016-10-09_14:47:27 WoZi_ErkerMi_Rollo aesKeyNbr: 00
2016-10-09_14:47:27 WoZi_ErkerMi_Rollo RAWMSG: A110CA0024AD222D3AA78045C05590C598C00::-69.5:nanoCULHomeMatic
2016-10-09_14:47:27 WoZi_ErkerMi_Rollo RSSI: -69.5
2016-10-09_14:47:36 WoZi_ErkerLi_Rollo ResndFail
2016-10-09_14:47:36 WoZi_ErkerLi_Rollo MISSING ACK

Umittelbar danach habe ich einen der beiden Rollläden einzeln gefahren, das funktioniert:

2016-10-09_14:51:02 WoZi_ErkerLi_Rollo set_off
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo aesCommToDev: fail
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo aesKeyNbr: 02
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo RAWMSG: A1110A0024AD27AD3AA780478E33D83FED602::-61.5:nanoCULHomeMatic
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo RSSI: -61.5
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo aesCommToDev: ok
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo deviceMsg: 79.5 (to hm_VCCU)
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo level: 79.5
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo motor: down:79.5
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo pct: 79.5
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo 79.5
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo timedOn: zu
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo RSSI: -64
2016-10-09_14:51:02 WoZi_ErkerLi_Rollo RAWMSG: A121080024AD27AD3AA7801019F203D07447D53::-64:nanoCULHomeMatic
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo deviceMsg: zu (to hm_VCCU)
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo level: 0
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo motor: stop:zu
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo pct: 0
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo zu
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo timedOn: zu
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo RAWMSG: A0D11A4104AD27AD3AA7806010000::-61:nanoCULHomeMatic
2016-10-09_14:51:29 WoZi_ErkerLi_Rollo RSSI: -61
2016-10-09_14:51:32 WoZi_ErkerLi_Rollo RSSI: -61.5
2016-10-09_14:51:32 WoZi_ErkerLi_Rollo RAWMSG: A0D11A4104AD27AD3AA7806010000::-61.5:nanoCULHomeMatic

Meine TSCUL Definition sieht wie folgt aus (habe "hmLanQlen" auf "1_min"):
Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400
   FD         14
   FHTID      0000
   HM_RptCnt  14
   NAME       nanoCULHomeMatic
   NR         37
   PARTIAL
   RAWMSG     AFF610001F6ED00199EA6034C1AFAD3AA78F4A49C8D107F160F6638CF6A1CFC3770E0
   RSSI       -90
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCULHomeMatic_MSGCNT 76
   nanoCULHomeMatic_TIME 2016-10-09 14:55:06
   owner_CCU  hm_VCCU
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-10-09 14:51:02   Xmit-Events     ok:1 Warning-HighLoad:2 init:3 ERROR-Overload:1 disconnected:1
     2016-09-09 13:30:35   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-10-09 14:41:09   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-10-09 14:51:02   cond            ok
     2016-10-09 14:57:38   credit10ms      934
     2016-10-09 14:44:50   hmSioDly        -1
     2016-10-09 14:38:55   prot_ERROR-Overload last
     2016-10-09 14:41:12   prot_Warning-HighLoad last
     2016-10-09 14:37:56   prot_disconnected last
     2016-10-09 14:41:09   prot_init       last
     2016-10-09 14:51:02   prot_ok         last
     2016-10-09 14:58:37   scF             0.999757687916075
     2016-10-09 14:41:09   state           Initialized
     2016-05-18 08:13:12   uptime          0 07:00:34
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    5
       hmSbusy    0
       lstSndTm   1476017706.7145
       Unknwn:
     Cnd:
       0          1
       2          2
       253        1
       255        3
       4          1
     Hmq:
     Hmqo:
     Q:
       HMcndN     0
       InQueues   0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        11250
     Ref:
       Sdly       3
       doNbyterate 65
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3720.13976385962
       lHMt       1241184
       lSys       696651533
       nusew      0
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      15
       pngMax     193
       pngMin     7
       pngRef     7
       pngtm      696651526
       pngtmBRs   1476018012.25688
       scErr      0.871689826017246
       scF        0.999757687916075
       scFN       3
       scHT       36656
       scST       695447296
Attributes:
   addvaltrigger 1
   hmId       D3AA78
   hmLanQlen  1_min
   model      nanoCUL
   rfmode     HomeMatic

Hast du irgendeine Idee, was ich bei mir anders eingestellt haben könnte, dass das nicht klappt?

Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Oktober 2016, 15:32:32
Hallo Rudolf,

danke für den Tip mit dem Commandref Update!

Hast Du meine Antwort hier https://forum.fhem.de/index.php/topic,57806.msg498328.html#msg498328 (https://forum.fhem.de/index.php/topic,57806.msg498328.html#msg498328) in der Wunschliste gelesen?
Was hältst Du von einer Parallelexistenz in der vorgeschlagenen Form?

STACKABLE_CC respektive SCC ist der einzige mir aufgefallenen Haken, der einen, jedoch auch ordnenden Eingriff in 00_CUL.pm erfordert. STACKABLE_CC wird ohnehin gerne vergessen, wenn auf CUL getestet wird (martin hatte es auch in einer Abfrage übersehen), weshalb die in CUL_UTIL.pm vorgeschlagenen Funktionen zu Testung auch an anderen Stellen vorteilhalft nutzbar wären.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Oktober 2016, 15:38:03
Hallo Christian,

kannst Du beides bitte nochmal mit verbose 4 beim NanoCUL loggen.
Im Rolladen-Log alleine ist nicht zu sehen, was wann gesendet und empfangen wird.
Die Einstellungen beim NanoCUL sehen erst mal gut aus.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 09 Oktober 2016, 23:21:18
Hallo Ansgar!

Habe jetzt nochmal mit verbose=4 die Logs gezogen, sieht aber leider nicht besser aus:

2016-10-09_23:15:03 WoZi_ErkerLi_Rollo set_on
2016-10-09_23:15:03 WoZi_ErkerMi_Rollo set_on
2016-10-09_23:15:14 WoZi_ErkerMi_Rollo aesKeyNbr: 00
2016-10-09_23:15:14 WoZi_ErkerMi_Rollo RAWMSG: A111DA0024AD222D3AA7804FEDD1CACD21900::-76.5:nanoCULHomeMatic
2016-10-09_23:15:14 WoZi_ErkerMi_Rollo RSSI: -76.5
2016-10-09_23:15:15 WoZi_ErkerLi_Rollo aesKeyNbr: 02
2016-10-09_23:15:15 WoZi_ErkerLi_Rollo RSSI: -55.5
2016-10-09_23:15:15 WoZi_ErkerLi_Rollo RAWMSG: A1115A0024AD27AD3AA7804956622D3DDA102::-55.5:nanoCULHomeMatic

Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Oktober 2016, 23:46:13
Hallo Christian,

beim NanoCUL musst Du das Attribut verbose auf 4 setzen.
Nur dann werden die Sende- und Empfangsdaten des NanoCUL geloggt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 11 Oktober 2016, 08:15:09
Hallo Ansgar!

Habe gestern noch ein paar Versuche gefahren. Auch mit verbose=4 auf dem nanoCUL bekomme ich weder vom CUL noch von der VCCU irgendeinen Log-Eintrag geschrieben. Die Logs der Aktoren sehen immer recht ähnlich aus, wobei ich 2x die Situation hatte, dass nun zwei bzw. einer von dreien auch bei sign=on losgefahren ist. Leider ist das aber nicht dauerhaft so, beim nächsten mal bleiben sie wieder alle 3 stehen.

Hier nochmal Logs:
2016-10-11_06:30:24 BrZi_ErkerLi_Rollo set_on
2016-10-11_06:30:24 BrZi_ErkerMi_Rollo set_on
2016-10-11_06:30:24 BrZi_ErkerRe_Rollo set_on
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo aesKeyNbr: 02
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo RSSI: -72.5
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo RAWMSG: A1119A0024AD281D3AA7804FA36DB6B523002::-72.5:nanoCULHomeMatic
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo aesCommToDev: fail
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo aesKeyNbr: 02
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo RSSI: -72
2016-10-11_06:30:27 BrZi_ErkerLi_Rollo RAWMSG: A1119A0024AD281D3AA78048C0C66F7D32D02::-72:nanoCULHomeMatic
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo aesKeyNbr: 02
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo RAWMSG: A1114A0024AD26BD3AA78048C63AC1D0FFB02::-65.5:nanoCULHomeMatic
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo RSSI: -65.5
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo aesCommToDev: fail
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo aesKeyNbr: 02
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo RSSI: -66
2016-10-11_06:30:27 BrZi_ErkerMi_Rollo RAWMSG: A1114A0024AD26BD3AA7804B1BCC4DA439402::-66:nanoCULHomeMatic
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo aesKeyNbr: 02
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo RAWMSG: A1114A0024AD28CD3AA7804B1BCB206130302::-66:nanoCULHomeMatic
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo RSSI: -66
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo aesCommToDev: ok
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo deviceMsg: zu (to hm_VCCU)
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo level: 0
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo motor: up:zu
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo pct: 0
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo zu
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo timedOn: zu
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo RSSI: -65.5
2016-10-11_06:30:28 BrZi_ErkerRe_Rollo RAWMSG: A121480024AD28CD3AA780101001042BAC8748F::-65.5:nanoCULHomeMatic
2016-10-11_06:30:58 BrZi_ErkerLi_Rollo ResndFail
2016-10-11_06:30:58 BrZi_ErkerLi_Rollo MISSING ACK
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo deviceMsg: auf (to hm_VCCU)
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo level: 100
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo motor: stop:auf
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo pct: 100
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo auf
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo timedOn: zu
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-64:nanoCULHomeMatic
2016-10-11_06:31:10 BrZi_ErkerRe_Rollo RSSI: -64
2016-10-11_06:31:16 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-64:nanoCULHomeMatic
2016-10-11_06:31:16 BrZi_ErkerRe_Rollo RSSI: -64
2016-10-11_06:31:17 BrZi_ErkerRe_Rollo RSSI: -65.5
2016-10-11_06:31:17 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-65.5:nanoCULHomeMatic
2016-10-11_06:31:26 BrZi_ErkerRe_Rollo RSSI: -66
2016-10-11_06:31:26 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-66:nanoCULHomeMatic
2016-10-11_06:31:27 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-65.5:nanoCULHomeMatic
2016-10-11_06:31:27 BrZi_ErkerRe_Rollo RSSI: -65.5
2016-10-11_06:31:33 BrZi_ErkerRe_Rollo RAWMSG: A0D15A4104AD28CD3AA780601C800::-65:nanoCULHomeMatic
2016-10-11_06:31:33 BrZi_ErkerRe_Rollo RSSI: -65
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo deviceMsg: 10 (to hm_VCCU)
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo level: 10
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo motor: up:10
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo pct: 10
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo 10
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo timedOn: zu
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo RAWMSG: A0D16A4104AD26BD3AA7806011410::-65:nanoCULHomeMatic
2016-10-11_06:31:48 BrZi_ErkerMi_Rollo RSSI: -65
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo deviceMsg: 8.5 (to hm_VCCU)
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo level: 8.5
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo motor: up:8.5
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo pct: 8.5
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo 8.5
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo timedOn: zu
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo RAWMSG: A0D1BA4104AD281D3AA7806011110::-75.5:nanoCULHomeMatic
2016-10-11_06:31:50 BrZi_ErkerLi_Rollo RSSI: -75.5
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo deviceMsg: auf (to hm_VCCU)
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo level: 100
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo motor: stop:auf
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo pct: 100
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo auf
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo timedOn: zu
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo RSSI: -65
2016-10-11_06:32:19 BrZi_ErkerMi_Rollo RAWMSG: A0D17A4104AD26BD3AA780601C800::-65:nanoCULHomeMatic
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo deviceMsg: auf (to hm_VCCU)
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo level: 100
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo motor: stop:auf
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo pct: 100
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo auf
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo timedOn: zu
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo RAWMSG: A0D1CA4104AD281D3AA780601C800::-71:nanoCULHomeMatic
2016-10-11_06:32:21 BrZi_ErkerLi_Rollo RSSI: -71
2016-10-11_06:32:23 BrZi_ErkerLi_Rollo RSSI: -78
2016-10-11_06:32:23 BrZi_ErkerLi_Rollo RAWMSG: A0D1CA4104AD281D3AA780601C800::-78:nanoCULHomeMatic
2016-10-11_06:32:23 BrZi_ErkerMi_Rollo RAWMSG: A0D17A4104AD26BD3AA780601C800::-65.5:nanoCULHomeMatic
2016-10-11_06:32:23 BrZi_ErkerMi_Rollo RSSI: -65.5
2016-10-11_06:32:28 BrZi_ErkerLi_Rollo RAWMSG: A0D1CA4104AD281D3AA780601C800::-76:nanoCULHomeMatic
2016-10-11_06:32:28 BrZi_ErkerLi_Rollo RSSI: -76

Hier ist BrZi_ErkerRe_Rollo losgelaufen, die anderen beiden nicht. Am Ende habe ich ..Mi.. und ..Li.. manuell hochfahren lassen.

Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Oktober 2016, 21:03:51
Hallo Christian,

dann stell bitte mal den NanoCUL auf verbose=4 und schicke ein List.

Wenn Rudolf nicht noch was eingebaut hat, um den verbose zu überschreiben, oder Du nicht noch Log Filter gesetzt hast, mit denen ausschließlich Deine Rolladen geloggt werden, dann kann das nicht sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 11 Oktober 2016, 21:20:39
Hallo Ansgar!

Habe jetzt wieder auf die Standardmodule und die culfw 1.66 zurückgestellt. Da sich das Logging damit aber ganauso verhält hoffe ich, dass der List auch so hilft.

Hier der HM CUL:
Internals:
   CMDS       BCFiAZEkGMKUYRTVWXefltx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400
   FD         14
   FHTID      0000
   NAME       nanoCULHomeMatic
   NR         37
   NR_CMD_LAST_H 82
   PARTIAL
   RAWMSG     A1957A6034C1AFAD3AA78EA2B4726493C4187276E593029F8B904DF
   RSSI       -90.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 nanoCUL868
   initString X21
Ar
   nanoCULHomeMatic_MSGCNT 40
   nanoCULHomeMatic_TIME 2016-10-11 21:10:29
   owner_CCU  hm_VCCU
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-10-10 18:44:02   Xmit-Events     Warning-HighLoad:1 init:2 disconnected:1 ok:1 ERROR-Overload:1
     2016-09-09 13:30:35   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-10-11 20:21:03   cmds             B C F i A Z E k G M K U Y R T V W X e f l t x
     2016-10-10 18:44:02   cond            ok
     2016-10-10 18:53:24   credit10ms      1014
     2016-10-10 18:52:37   hmSioDly        -1
     2016-10-10 18:34:36   prot_ERROR-Overload last
     2016-10-10 18:30:49   prot_Warning-HighLoad last
     2016-10-10 18:30:16   prot_disconnected last
     2016-10-10 18:30:17   prot_init       last
     2016-10-10 18:44:02   prot_ok         last
     2016-10-09 19:49:02   scF             0.999757851177839
     2016-10-11 21:10:29   state           Initialized
     2016-05-18 08:13:12   uptime          0 07:00:34
   XMIT_TIME:
     1476210090.65173
     1476210093.03576
     1476210093.36646
     1476210093.65502
     1476210095.26687
     1476210096.57788
     1476210097.771
     1476210098.69266
     1476210099.04996
     1476210099.24718
     1476210100.14954
     1476210100.34165
     1476210101.24277
     1476210101.43332
     1476210102.32497
     1476210102.56924
     1476210103.40789
     1476210103.59809
     1476210104.47128
     1476210104.66581
     1476210105.49168
     1476210106.03597
     1476210106.51094
     1476210107.5741
     1476210110.04813
     1476210111.4129
     1476210111.79988
     1476210112.08234
     1476210112.86842
     1476210113.21231
     1476210113.89919
     1476210114.12494
     1476210114.96332
     1476210115.49594
     1476210115.72205
     1476210115.75459
     1476210116.0268
     1476210117.01239
     1476210117.2861
     1476210117.81865
     1476210118.34395
     1476210122.59142
     1476210122.69679
     1476210122.84702
     1476210122.86148
     1476210123.05078
     1476210123.15595
     1476210123.34827
     1476210123.90649
     1476210124.43941
     1476210125.18106
     1476210125.71295
     1476210126.20156
     1476210126.38355
     1476210127.93746
     1476210128.7794
     1476210129.03478
     1476210129.24581
     1476210133.35166
     1476210138.2797
     1476210142.67944
     1476210147.722
     1476211927.73372
     1476211929.82924
     1476211931.40335
     1476211932.94479
     1476211935.65266
     1476211935.83206
     1476211937.48538
     1476211938.29023
     1476211938.39938
     1476211938.57627
     1476211942.91213
     1476211943.56986
     1476211943.64505
     1476211943.82167
     1476211949.22097
     1476211949.39789
     1476212261.56258
     1476213029.15197
     1476213029.42199
     1476213029.72346
   Helper:
     0a0301:
       QUEUE:
     0a0302:
       QUEUE:
     35f3dc:
       QUEUE:
     361e23:
       QUEUE:
     3f86f8:
       QUEUE:
     42250a:
       QUEUE:
     4569c9:
       QUEUE:
     4569d2:
       QUEUE:
     481c40:
       QUEUE:
     4ab1b6:
       QUEUE:
     4ad222:
       QUEUE:
     4ad26b:
       QUEUE:
     4ad279:
       QUEUE:
     4ad27a:
       QUEUE:
     4ad281:
       QUEUE:
     4ad28c:
       QUEUE:
     4ad2c0:
       QUEUE:
     4b29d6:
       QUEUE:
     4c1afa:
       QUEUE:
Attributes:
   addvaltrigger 1
   devStateIcon Initialized:usb@green Open:usb@red
   hmId       D3AA78
   model      nanoCUL
   rfmode     HomeMatic
   verbose    4

...und hier zur Sicherheit nochmal ein Aktor:

Internals:
   DEF        4AD26B
   IODev      nanoCULHomeMatic
   LASTInputDev nanoCULHomeMatic
   MSGCNT     1
   NAME       BrZi_ErkerMi_Rollo
   NOTIFYDEV  global
   NR         291
   NTFY_ORDER 50-BrZi_ErkerMi_Rollo
   STATE      zu
   TYPE       CUL_HM
   lastMsg    No:02 - t:10 s:4AD26B d:D3AA78 0601000042
   nanoCULHomeMatic_MSGCNT 1
   nanoCULHomeMatic_RAWMSG A0E02A4104AD26BD3AA780601000042::-62.5:nanoCULHomeMatic
   nanoCULHomeMatic_RSSI -62.5
   nanoCULHomeMatic_TIME 2016-10-11 20:21:39
   protLastRcv 2016-10-11 20:21:39
   protSnd    2 last_at:2016-10-11 20:21:39
   protState  CMDs_done
   rssi_at_nanoCULHomeMatic lst:-62.5 avg:-62.5 cnt:1 min:-62.5 max:-62.5
   rssi_nanoCULHomeMatic min:-66 max:-66 cnt:1 avg:-66 lst:-66
   Readings:
     2016-10-11 19:47:00   D-firmware      2.8
     2016-10-11 19:47:00   D-serialNr      NEQ0394531
     2016-10-11 19:47:45   PairedTo        0xD3AA78
     2016-10-11 19:47:47   R-driveDown     27 s
     2016-10-11 19:47:47   R-driveTurn     0.5 s
     2016-10-11 19:47:47   R-driveUp       28 s
     2016-10-11 19:47:45   R-pairCentral   0xD3AA78
     2016-10-11 19:47:47   R-sign          on
     2016-10-11 19:47:45   RegL_00.        02:01 0A:D3 0B:AA 0C:78 15:FF 18:00 00:00
     2016-10-11 19:47:47   RegL_01.        08:01 09:00 0A:00 0B:01 0C:0E 0D:01 0E:18 0F:05 10:00  30:06 57:24 56:00 00:00
     2016-10-11 20:21:39   deviceMsg       off (to hm_VCCU)
     2016-10-11 20:21:39   level           0
     2016-10-11 20:21:39   motor           stop:off
     2016-10-11 20:21:39   pct             0
     2016-10-11 20:21:39   recentStateType info
     2016-10-11 20:21:39   state           off
     2016-10-11 20:21:39   timedOn         off
   Helper:
     HM_CMDNR   2
     cSnd       ,01D3AA784AD26B010E
     mId        006A
     rxType     1
     Dir:
       cur        stop
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4AD26B,00,01,00
       nextSend   1476210099.33076
       rxt        0
       vccu       hm_VCCU
       p:
         4AD26B
         00
         01
         00
       prefIO:
         nanoCULHomeMatic
     Mrssi:
       mNo        02
       Io:
         nanoCULHomeMatic -60.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rpt:
       IO         nanoCULHomeMatic
       flg        A
       ts         1476210099.24605
       ack:
         HASH(0x3935160)
         028002D3AA784AD26B00
     Rssi:
       At_nanoculhomematic:
         avg        -62.5
         cnt        1
         lst        -62.5
         max        -62.5
         min        -62.5
       Nanoculhomematic:
         avg        -66
         cnt        1
         lst        -66
         max        -66
         min        -66
     Shadowreg:
     Tmpl:
Attributes:
   IODev      nanoCULHomeMatic
   IOgrp      hm_VCCU:nanoCULHomeMatic
   alias      Bar Mitte
   autoReadReg 4_reqStatus
   devStateIcon auf:fts_shutter_10:zu zu:fts_shutter_100:auf
   eventMap   on:auf off:zu
   expert     2_raw
   firmware   2.8
   group      Rollläden
   isSleepingRoom 0
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Barzimmer
   serialNr   NEQ0394531
   subType    blindActuator
   userattr   isSleepingRoom
   webCmd     auf:zu:stop:pct


Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 11 Oktober 2016, 21:44:11
Habe jetzt gerade zur Sicherheit nochmal über das Eventlog geprüft: Der CUL taucht auch hier nicht auf, nur der Aktor.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Oktober 2016, 22:02:54
Hallo Christian,

und wie ziehst Du das Log?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 11 Oktober 2016, 22:14:43
Für den Aktor hiermit:

Internals:
   DEF        /var/log/fhem/Rollos-%Y-%m.log ...._.*Rollo|ScZi_Rollo.*
   NAME       log_Rollos
   NR         233
   NTFY_ORDER 50-log_Rollos
   REGEXP     ...._.*Rollo|ScZi_Rollo.*
   STATE      active
   TYPE       FileLog
   currentlogfile /var/log/fhem/Rollos-2016-10.log
   logfile    /var/log/fhem/Rollos-%Y-%m.log
   Readings:
     2016-10-11 21:53:20   linesInTheFile  12804
Attributes:
   archiveCompress 1
   archivedir /var/log/fhem/archive
   logtype    text
   nrarchive  0

...und für die CULs so:

Internals:
   DEF        /var/log/fhem/log_CUL-%Y-%m.log nanoCUL.*|hm_VCCU
   NAME       log_CUL
   NR         317
   NTFY_ORDER 50-log_CUL
   REGEXP     nanoCUL.*|hm_VCCU
   STATE      active
   TYPE       FileLog
   currentlogfile /var/log/fhem/log_CUL-2016-10.log
   logfile    /var/log/fhem/log_CUL-%Y-%m.log
   Readings:
     2016-10-11 22:06:14   linesInTheFile  475
Attributes:
   archiveCompress 1
   archivedir /var/log/fhem/archive
   nrarchive  0

Wie gesagt, im Eventlog habe ich für die letzte Aktion auch nochmal gegengeprüft.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Oktober 2016, 22:31:01
Hallo Christian,

ok, da haben wir das Verständnisproblem.

Was Du so "loggst" sind notifies etc. aber nicht die Log Ausgabe aus dem Code, die interessiert.

Außerdem solltedt Du noch das globale Attribut
attr global mseclog 1 setzen, damit die Zeiten um die ms ergänzt geloggt werden.

Klick doch im Browser bei FHEM mal links auf "Logfile" ... da findest Du die interessanten Log Einträge.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 11 Oktober 2016, 22:39:36
Hi Ansgar!

Ok, danke dir!
Ich sehe mir gleich noch mein Logfile an. Wenn ich aber wieder auf deine Module gehen muss, um die Logs zu erzeugen, dann wird es verm. Wo-Ende werden. Bin ab morgen unterwegs.


Vielen Dank bis dahin,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Oktober 2016, 22:53:25
Hallo Christian,

Zitat
Wenn ich aber wieder auf deine Module gehen muss, um die Logs zu erzeugen
ja, und auch auf die TS Firmware  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 16 Oktober 2016, 15:57:47
Hallo Ansgar!

Sorry, hat etwas bei mir gedauert.

Test: Es wurden 3 Rollläden gleichzeit angesteuert. Davon hat einer reagiert, die anderen beiden nicht.

Hier das Logfile (CUL auf verbose 4):
2016.10.16 15:47:11.876 4: TSCUL_Parse: nanoCULHomeMatic  461427 A FFB2 00180816 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:47:45.213 4: TSCUL_Parse: nanoCULHomeMatic  494764 A FFA2 00214168 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:48:18.119 4: TSCUL_Parse: nanoCULHomeMatic  003382 A FFA2 00247080 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:48:52.290 4: TSCUL_Parse: nanoCULHomeMatic  037551 A FFA2 00281256 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:49:06.873 3: CUL_HM set BrZi_ErkerLi_Rollo on
2016.10.16 15:49:06.886 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD281 0201C80000
2016.10.16 15:49:06.983 3: CUL_HM set BrZi_ErkerRe_Rollo on
2016.10.16 15:49:07.024 4: TSCUL_Parse: nanoCULHomeMatic  052293 A FF93 00295872 00 0E 03 A011 D3AA78 4AD281  -138
2016.10.16 15:49:08.555 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD281 0201C80000
2016.10.16 15:49:08.560 4: TSCUL_Parse: nanoCULHomeMatic  053825 A FF91 00296032 00 11 03 A002 4AD281 D3AA78 044C00E75D457A02 -74
2016.10.16 15:49:08.637 4: TSCUL_Parse: nanoCULHomeMatic  053906 A FF93 00297544 00 0E 03 A011 D3AA78 4AD281  -138
2016.10.16 15:49:08.697 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD281 d435475d7cb75a883f4daad7a11c37fe
2016.10.16 15:49:08.759 4: TSCUL_Parse: nanoCULHomeMatic  054027 A FF93 00297696 00 19 03 A003 D3AA78 4AD281  -138
2016.10.16 15:49:08.773 4: TSCUL_Parse: nanoCULHomeMatic  054037 A FF91 00297736 00 11 03 A002 4AD281 D3AA78 04E9D4AF043EE202 -74
2016.10.16 15:49:08.790 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD281 6b4c6772d33d9afb68960c70ead358d0
2016.10.16 15:49:08.864 4: TSCUL_Parse: nanoCULHomeMatic  054133 A FF93 00297784 00 19 03 A003 D3AA78 4AD281  -138
2016.10.16 15:49:09.979 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD281 6b4c6772d33d9afb68960c70ead358d0
2016.10.16 15:49:10.565 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD26B 0201C80000
2016.10.16 15:49:10.893 4: TSCUL_Parse: nanoCULHomeMatic  056162 A FFA3 00298976 00 19 03 A003 D3AA78 4AD281  -138
2016.10.16 15:49:10.895 4: TSCUL_Parse: nanoCULHomeMatic  056164 A FFA3 00299552 00 0E 03 A011 D3AA78 4AD26B  -138
2016.10.16 15:49:10.898 4: TSCUL_Parse: nanoCULHomeMatic  056162 A FFA1 00299712 00 11 03 A002 4AD26B D3AA78 04ED331477AB5902 -67
2016.10.16 15:49:10.914 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD26B a98816e4496e6f6d8465f195e82ced28
2016.10.16 15:49:11.044 4: TSCUL_Parse: nanoCULHomeMatic  056312 A FFA3 00299912 00 19 03 A003 D3AA78 4AD26B  -138
2016.10.16 15:49:11.343 4: TSCUL_send:  nanoCULHomeMatic                    Aa 9276 19 03 A003 D3AA78 4AD26B a98816e4496e6f6d8465f195e82ced28
2016.10.16 15:49:11.344 3: TSCUL_XmitDlyHM:  nanoCULHomeMatic  id:4AD26B dDly:-389 tgtDly:240 toms:17
2016.10.16 15:49:11.581 4: TSCUL_Parse: nanoCULHomeMatic  056845 A FFA1 00300064 00 12 03 8002 4AD26B D3AA78 01012C1046A6083404 -66.5
2016.10.16 15:49:11.601 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD28C 0201C80000
2016.10.16 15:49:11.717 3: TSCUL_ParseTsHM: nanoCULHomeMatic  id:4AD26B dhmSt:632 dHMtgt:240
2016.10.16 15:49:11.718 4: TSCUL_Parse: nanoCULHomeMatic  056986 A FFA3 00300344 00 19 03 A003 D3AA78 4AD26B  -138
2016.10.16 15:49:11.723 4: TSCUL_Parse: nanoCULHomeMatic  056992 A FFA3 00300592 00 0E 03 A011 D3AA78 4AD28C  -138
2016.10.16 15:49:17.567 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD28C 0201C80000
2016.10.16 15:49:17.569 4: CUL_HM_Resend: BrZi_ErkerRe_Rollo nr 2
2016.10.16 15:49:19.107 4: TSCUL_Parse: nanoCULHomeMatic  064372 A FFA1 00300744 00 11 03 A002 4AD28C D3AA78 0423FCBBFBD2E102 -70
2016.10.16 15:49:19.187 4: TSCUL_Parse: nanoCULHomeMatic  064456 A FFA3 00306560 00 0E 03 A011 D3AA78 4AD28C  -138
2016.10.16 15:49:19.189 4: TSCUL_Parse: nanoCULHomeMatic  064454 A FFA1 00306712 00 11 03 A002 4AD28C D3AA78 042CB07E0F7E0102 -68
2016.10.16 15:49:19.193 1: PERL WARNING: Use of uninitialized value $parse in string eq at ./FHEM/10_CUL_HM.pm line 1347.
2016.10.16 15:49:19.194 1: PERL WARNING: Use of uninitialized value $parse in string eq at ./FHEM/10_CUL_HM.pm line 1348.
2016.10.16 15:49:19.194 1: PERL WARNING: Use of uninitialized value $parse in string eq at ./FHEM/10_CUL_HM.pm line 1351.
2016.10.16 15:49:19.195 1: PERL WARNING: Use of uninitialized value $parse in string eq at ./FHEM/10_CUL_HM.pm line 1355.
2016.10.16 15:49:19.195 1: PERL WARNING: Use of uninitialized value $parse in string eq at ./FHEM/10_CUL_HM.pm line 1358.
2016.10.16 15:49:19.288 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD28C 0201C80000
2016.10.16 15:49:19.464 4: TSCUL_Parse: nanoCULHomeMatic  064733 A FFA3 00308280 00 0E 03 A011 D3AA78 4AD28C  -138
2016.10.16 15:49:19.478 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD28C 1e786947479e2912045cab5f279b4ea7
2016.10.16 15:49:19.479 4: TSCUL_Parse: nanoCULHomeMatic  064731 A FFA1 00308432 00 11 03 A002 4AD28C D3AA78 044504D76F4C5102 -67
2016.10.16 15:49:19.559 4: TSCUL_Parse: nanoCULHomeMatic  064827 A FFA3 00308480 00 19 03 A003 D3AA78 4AD28C  -138
2016.10.16 15:49:19.830 4: TSCUL_send:  nanoCULHomeMatic                         As 19 03 A003 D3AA78 4AD28C 1e786947479e2912045cab5f279b4ea7
2016.10.16 15:49:19.856 4: TSCUL_send:  nanoCULHomeMatic                         As 0A 03 8002 D3AA78 4AD28C 00
2016.10.16 15:49:19.881 4: TSCUL_send:  nanoCULHomeMatic                         As 0A 03 8002 D3AA78 4AD28C 00
2016.10.16 15:49:19.885 4: TSCUL_Parse: nanoCULHomeMatic  065154 A FFA3 00308832 00 19 03 A003 D3AA78 4AD28C  -138
2016.10.16 15:49:19.911 4: TSCUL_Parse: nanoCULHomeMatic  065180 A FFA3 00308864 00 0A 03 8002 D3AA78 4AD28C  -138
2016.10.16 15:49:19.936 4: TSCUL_Parse: nanoCULHomeMatic  065205 A FFA3 00308896 00 0A 03 8002 D3AA78 4AD28C  -138
2016.10.16 15:49:22.682 4: TSCUL_Parse: nanoCULHomeMatic  067945 A FFA2 00311656 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:49:37.778 4: TSCUL_Parse: nanoCULHomeMatic  083044 A FFA1 00326744 00 0D 04 A410 4AD26B D3AA78 0601C800 -66
2016.10.16 15:49:37.797 4: TSCUL_send:  nanoCULHomeMatic                      Aw 0B 0A 04 8002 D3AA78 4AD26B 00
2016.10.16 15:49:37.798 3: TSCUL_XmitDlyHM:  nanoCULHomeMatic  id:4AD26B dDly:85 tgtDly:120 toms:99
2016.10.16 15:49:38.028 3: TSCUL_ParseTsHM: nanoCULHomeMatic  id:4AD26B dhmSt:136 dHMtgt:120 hmSioDly:-1
2016.10.16 15:49:38.029 4: TSCUL_Parse: nanoCULHomeMatic  083296 A FFA3 00326880 00 0A 04 8002 D3AA78 4AD26B  -138
2016.10.16 15:49:54.968 4: TSCUL_Parse: nanoCULHomeMatic  100231 A FF92 00343952 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:50:28.621 4: TSCUL_Parse: nanoCULHomeMatic  133883 A FF92 00377616 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:50:58.798 4: TSCUL_Parse: nanoCULHomeMatic  164060 A FF92 00407800 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:51:31.926 4: TSCUL_Parse: nanoCULHomeMatic  197188 A FF92 00440928 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:52:06.065 4: TSCUL_Parse: nanoCULHomeMatic  231328 A FF92 00475080 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138
2016.10.16 15:52:38.817 4: TSCUL_Parse: nanoCULHomeMatic  264079 A FF92 00507840 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA -138

List BrZi_ErkerLi_Rollo (ist auf Fehler gelaufen)
Internals:
   DEF        4AD281
   IODev      nanoCULHomeMatic
   LASTInputDev nanoCULHomeMatic
   MSGCNT     3
   NAME       BrZi_ErkerLi_Rollo
   NOTIFYDEV  global
   NR         290
   NTFY_ORDER 50-BrZi_ErkerLi_Rollo
   STATE      set_on
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:4AD281 d:D3AA78 04E9D4AF043EE202
   nanoCULHomeMatic_MSGCNT 3
   nanoCULHomeMatic_RAWMSG A1103A0024AD281D3AA7804E9D4AF043EE202::-74:nanoCULHomeMatic
   nanoCULHomeMatic_RSSI -74
   nanoCULHomeMatic_TIME 2016-10-16 15:49:08
   protLastRcv 2016-10-16 15:49:08
   protSnd    5 last_at:2016-10-16 15:49:08
   protState  CMDs_processing...
   rssi_at_nanoCULHomeMatic avg:-74 lst:-74 max:-74 cnt:3 min:-74
   rssi_nanoCULHomeMatic lst:-73 avg:-73 max:-73 min:-73 cnt:1
   Readings:
     2016-10-16 10:38:32   CommandAccepted yes
     2016-10-11 19:47:00   D-firmware      2.8
     2016-10-11 19:47:00   D-serialNr      NEQ0394497
     2016-10-11 19:47:40   PairedTo        0xD3AA78
     2016-10-11 19:47:41   R-driveDown     27 s
     2016-10-11 19:47:41   R-driveTurn     0.5 s
     2016-10-11 19:47:41   R-driveUp       28 s
     2016-10-11 19:47:40   R-pairCentral   0xD3AA78
     2016-10-11 19:47:41   R-sign          on
     2016-10-11 19:47:40   RegL_00.        02:01 0A:D3 0B:AA 0C:78 15:FF 18:00 00:00
     2016-10-11 19:47:41   RegL_01.        08:01 09:00 0A:00 0B:01 0C:0E 0D:01 0E:18 0F:05 10:00  30:06 57:24 56:00 00:00
     2016-10-16 15:49:08   aesCommToDev    fail
     2016-10-16 15:49:08   aesKeyNbr       02
     2016-10-16 15:45:52   deviceMsg       79.5 (to hm_VCCU)
     2016-10-16 15:45:52   level           79.5
     2016-10-16 15:45:52   motor           stop:79.5
     2016-10-16 15:45:52   pct             79.5
     2016-10-16 15:45:52   recentStateType info
     2016-10-16 15:49:06   state           set_on
     2016-10-16 15:45:52   timedOn         off
   cmdStack:
   Helper:
     AESreqAck  25E2C0D2
     HM_CMDNR   3
     cSnd       01D3AA784AD281010E,11D3AA784AD2810201C80000
     dlvl       C8
     dlvlCmd    ++A011D3AA784AD2810201C80000
     mId        006A
     rxType     1
     supp_Pair_Rep 0
     Dir:
       cur        stop
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAAa    192
       lRcTm      296032
       lstRecType 02
       lstSnd     1476625747.15952
       lstSndTgd  360
       newChn     +4AD281,00,01,00
       nextSend   1476625747.15952
       nxtSndMcnt 03
       rxt        0
       tgtDly     120
       vccu       hm_VCCU
       p:
         4AD281
         00
         01
         00
       prefIO:
         nanoCULHomeMatic
     Mrssi:
       mNo        03
       Io:
         nanoCULHomeMatic -72
     Prt:
       bErr       0
       sProc      1
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rssi:
       At_nanoculhomematic:
         avg        -74
         cnt        3
         lst        -74
         max        -74
         min        -74
       Nanoculhomematic:
         avg        -73
         cnt        1
         lst        -73
         max        -73
         min        -73
     Tmpl:
Attributes:
   IODev      nanoCULHomeMatic
   IOgrp      hm_VCCU:nanoCULHomeMatic
   alias      Bar Links
   autoReadReg 4_reqStatus
   devStateIcon auf:fts_shutter_10:zu zu:fts_shutter_100:auf
   eventMap   on:auf off:zu
   expert     2_raw
   firmware   2.8
   group      Rollläden
   isSleepingRoom 0
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Barzimmer
   serialNr   NEQ0394497
   subType    blindActuator
   userattr   isSleepingRoom
   verbose    4
   webCmd     auf:zu:stop:pct

List BrZi_ErkerRe_Rollo (ist auf Fehler gelaufen)
Internals:
   DEF        4AD28C
   IODev      nanoCULHomeMatic
   LASTInputDev nanoCULHomeMatic
   MSGCNT     6
   NAME       BrZi_ErkerRe_Rollo
   NOTIFYDEV  global
   NR         292
   NTFY_ORDER 50-BrZi_ErkerRe_Rollo
   STATE      set_on
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:4AD28C d:D3AA78 044504D76F4C5102
   nanoCULHomeMatic_MSGCNT 6
   nanoCULHomeMatic_RAWMSG A1103A0024AD28CD3AA78044504D76F4C5102::-67:nanoCULHomeMatic
   nanoCULHomeMatic_RSSI -67
   nanoCULHomeMatic_TIME 2016-10-16 15:49:19
   protLastRcv 2016-10-16 15:49:19
   protResnd  2 last_at:2016-10-16 15:49:17
   protSnd    7 last_at:2016-10-16 15:49:19
   protState  CMDs_done
   rssi_at_nanoCULHomeMatic cnt:6 min:-70 max:-67 avg:-68.91 lst:-67
   rssi_nanoCULHomeMatic lst:-69 avg:-69 max:-69 min:-69 cnt:1
   Readings:
     2016-10-16 10:26:12   CommandAccepted yes
     2016-10-11 19:47:00   D-firmware      2.8
     2016-10-11 19:47:00   D-serialNr      NEQ0394501
     2016-10-11 18:51:21   PairedTo        0xD3AA78
     2016-10-11 18:51:34   R-driveDown     27 s
     2016-10-11 18:51:34   R-driveTurn     0.5 s
     2016-10-11 18:51:34   R-driveUp       28 s
     2016-10-11 18:51:21   R-pairCentral   0xD3AA78
     2016-10-11 18:51:34   R-sign          on
     2016-10-11 18:51:21   RegL_00.        02:01 0A:D3 0B:AA 0C:78 15:FF 18:00 00:00
     2016-10-11 18:51:34   RegL_01.        08:01 09:00 0A:00 0B:01 0C:0E 0D:01 0E:18 0F:05 10:00  30:06 57:24 56:00 00:00
     2016-10-16 15:49:19   aesCommToDev    fail
     2016-10-16 15:49:19   aesKeyNbr       02
     2016-10-16 15:46:02   deviceMsg       12.5 (to hm_VCCU)
     2016-10-16 15:46:02   level           12.5
     2016-10-16 15:46:02   motor           stop:12.5
     2016-10-16 15:46:02   pct             12.5
     2016-10-16 15:46:02   recentStateType info
     2016-10-16 15:49:06   state           set_on
     2016-10-16 15:46:02   timedOn         off
   Helper:
     HM_CMDNR   3
     cSnd       01D3AA784AD28C010E,11D3AA784AD28C0201C80000
     dlvl       C8
     dlvlCmd    ++A011D3AA784AD28C0201C80000
     mId        006A
     rxType     1
     supp_Pair_Rep 0
     Dir:
       cur        stop
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       lRcTm      300744
       lstRecType 02
       lstSnd     1476625751.87087
       lstSndTgd  600
       newChn     +4AD28C,00,01,00
       nextSend   1476625751.87087
       nxtSndMcnt 03
       rxt        0
       tgtDly     120
       vccu       hm_VCCU
       p:
         4AD28C
         00
         01
         00
       prefIO:
         nanoCULHomeMatic
     Mrssi:
       mNo        03
       Io:
         nanoCULHomeMatic -65
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rpt:
       IO         nanoCULHomeMatic
       flg        A
       ts         1476625759.48423
       ack:
         HASH(0x3def530)
         038002D3AA784AD28C00
     Rssi:
       At_nanoculhomematic:
         avg        -68.9166666666667
         cnt        6
         lst        -67
         max        -67
         min        -70
       Nanoculhomematic:
         avg        -69
         cnt        1
         lst        -69
         max        -69
         min        -69
     Tmpl:
Attributes:
   IODev      nanoCULHomeMatic
   IOgrp      hm_VCCU:nanoCULHomeMatic
   alias      Bar Rechts
   autoReadReg 4_reqStatus
   devStateIcon auf:fts_shutter_10:zu zu:fts_shutter_100:auf
   eventMap   on:auf off:zu
   expert     2_raw
   firmware   2.8
   group      Rollläden
   isSleepingRoom 0
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Barzimmer
   serialNr   NEQ0394501
   subType    blindActuator
   userattr   isSleepingRoom
   verbose    4
   webCmd     auf:zu:stop:pct

List BrZi_ErkerMi_Rollo (ist korrekt gelaufen)
Internals:
   DEF        4AD26B
   IODev      nanoCULHomeMatic
   LASTInputDev nanoCULHomeMatic
   MSGCNT     4
   NAME       BrZi_ErkerMi_Rollo
   NOTIFYDEV  global
   NR         291
   NTFY_ORDER 50-BrZi_ErkerMi_Rollo
   STATE      auf
   TYPE       CUL_HM
   lastMsg    No:04 - t:10 s:4AD26B d:D3AA78 0601C800
   nanoCULHomeMatic_MSGCNT 4
   nanoCULHomeMatic_RAWMSG A0D04A4104AD26BD3AA780601C800::-66:nanoCULHomeMatic
   nanoCULHomeMatic_RSSI -66
   nanoCULHomeMatic_TIME 2016-10-16 15:49:37
   protLastRcv 2016-10-16 15:49:37
   protSnd    5 last_at:2016-10-16 15:49:37
   protState  CMDs_done
   rssi_at_nanoCULHomeMatic max:-66 avg:-66.87 lst:-66 cnt:4 min:-68
   rssi_nanoCULHomeMatic cnt:2 min:-72 max:-70 avg:-71 lst:-70
   Readings:
     2016-10-16 15:49:11   CommandAccepted yes
     2016-10-11 19:47:00   D-firmware      2.8
     2016-10-11 19:47:00   D-serialNr      NEQ0394531
     2016-10-16 10:37:50   PairedTo        0xD3AA78
     2016-10-11 19:47:47   R-driveDown     27 s
     2016-10-11 19:47:47   R-driveTurn     0.5 s
     2016-10-11 19:47:47   R-driveUp       28 s
     2016-10-11 19:47:45   R-pairCentral   0xD3AA78
     2016-10-11 19:47:47   R-sign          on
     2016-10-16 10:37:49   RegL_00.        02:01 0A:D3 0B:AA 0C:78 15:FF 18:00 00:00
     2016-10-16 10:37:50   RegL_01.        08:01 09:00 0A:00 0B:01 0C:0E 0D:01 0E:18 0F:05 10:00  30:06 57:24 56:00 00:00
     2016-10-16 15:49:11   aesCommToDev    ok
     2016-10-16 15:49:10   aesKeyNbr       02
     2016-10-16 15:49:37   deviceMsg       on (to hm_VCCU)
     2016-10-16 15:49:37   level           100
     2016-10-16 15:49:37   motor           stop:on
     2016-10-16 15:49:37   pct             100
     2016-10-16 15:49:37   recentStateType info
     2016-10-16 15:49:37   state           on
     2016-10-16 15:49:37   timedOn         off
   Helper:
     HM_CMDNR   4
     cSnd       01D3AA784AD26B010E,11D3AA784AD26B0201C80000
     dlvlCmd    ++A011D3AA784AD26B0201C80000
     mId        006A
     rxType     1
     supp_Pair_Rep 0
     Dir:
       cur        stop
       rct        up
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAAa    120
       dwoCAAw    136
       lRcTm      326744
       lstRecType 10
       lstSnd     1476625777.87908
       lstSndTgd  120
       newChn     +4AD26B,00,01,00
       nextSend   1476625777.87908
       nxtSndMcnt 04
       rxt        0
       tgtDly     120
       vccu       hm_VCCU
       p:
         4AD26B
         00
         01
         00
       prefIO:
         nanoCULHomeMatic
     Mrssi:
       mNo        04
       Io:
         nanoCULHomeMatic -64
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rpt:
       IO         nanoCULHomeMatic
       flg        A
       ts         1476625777.78562
       ack:
         HASH(0x3def008)
         048002D3AA784AD26B00
     Rssi:
       At_nanoculhomematic:
         avg        -66.875
         cnt        4
         lst        -66
         max        -66
         min        -68
       Nanoculhomematic:
         avg        -71
         cnt        2
         lst        -70
         max        -70
         min        -72
     Tmpl:
Attributes:
   IODev      nanoCULHomeMatic
   IOgrp      hm_VCCU:nanoCULHomeMatic
   alias      Bar Mitte
   autoReadReg 4_reqStatus
   devStateIcon auf:fts_shutter_10:zu zu:fts_shutter_100:auf
   eventMap   on:auf off:zu
   expert     2_raw
   firmware   2.8
   group      Rollläden
   isSleepingRoom 0
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Barzimmer
   serialNr   NEQ0394531
   subType    blindActuator
   userattr   isSleepingRoom
   verbose    0
   webCmd     auf:zu:stop:pct

List vom CUL
Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CTOG-if00-port0@38400
   FD         14
   FHTID      0000
   HM_RptCnt  19
   NAME       nanoCULHomeMatic
   NR         37
   PARTIAL
   RAWMSG     AFFA100009F8B000D04A4104AD26BD3AA780601C80010
   RSSI       -66
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCULHomeMatic_MSGCNT 59
   nanoCULHomeMatic_TIME 2016-10-16 15:49:37
   owner_CCU  hm_VCCU
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-10-16 15:45:49   Xmit-Events     ok:1 disconnected:1 Warning-HighLoad:2 init:2
     2016-09-09 13:30:35   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-10-16 15:45:07   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-10-16 15:45:49   cond            Warning-HighLoad
     2016-10-10 18:53:24   credit10ms      1014
     2016-10-16 15:49:38   hmSioDly        -1
     2016-10-10 18:34:36   prot_ERROR-Overload last
     2016-10-16 15:45:49   prot_Warning-HighLoad last
     2016-10-16 15:45:07   prot_disconnected last
     2016-10-16 15:45:08   prot_init       last
     2016-10-16 15:45:48   prot_ok         last
     2016-10-09 19:49:02   scF             0.999757851177839
     2016-10-16 15:45:07   state           Initialized
     2016-05-18 08:13:12   uptime          0 07:00:34
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    10
       hmSbusy    0
       lstSndTm   1476625778.01636
       Unknwn:
     Cnd:
       0          1
       2          2
       253        1
       255        2
     Hmq:
     Hmqo:
     Q:
       HMcndN     2
       InQueues   0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        1000
     Ref:
       Sdly       121
       doNbyterate 78
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3727.23677838561
       lHMt       308432
       lSys       230751451
       nusew      29
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      14
       pngMax     -200000
       pngMin     100000000
       pngRef     6
       pngtm      230562232
       pngtmBRs   1476626224.5024
       scF        0.999757851177839
       scFN       0
       scHT       119184
       scST       230562238
Attributes:
   addvaltrigger 1
   devStateIcon Initialized:usb@green Open:usb@red
   hmId       D3AA78
   hmLanQlen  1_min
   model      nanoCUL
   rfmode     HomeMatic
   verbose    4

Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Oktober 2016, 17:32:47
Hallo Christian,

Du hast anscheinend sehr große Verzögerungen im FHEM.

Vermutlich irgendein FHEM Modul braucht sehr viel Zeit am Stück. Ich kenne das bisher von Plots, die beim Neuzeichnen viel Zeit brauchen und dann stören. Oder auch Modul Kommunikation zu Servern mit aktivem Warten auf Antwort, was ganz FHEM anhält.

Mit AES wird das dann fatal, weil Signing Antworten nicht rechtzeitig raus gehen können und Wiederholtimeouts ansprechen, obwohl das device antwortet (aber die Antwort viel zu spät verarbeitet wird). Ohne AES ist es noch unkritisch, weil nicht signiert werden muss.

Um das Problemmodul zu identfizieren müsstest Du Dir eine minimal fhem.cfg bauen in der erst mal nur Homematic mit dem nanoCul und den Rolladen drin ist und dann testen wie es läuft und dann nach und nach weitere Module wieder aktivieren, bis es hakt.

Es gibt natürlich auch noch die Möglichkeit, dass Dein FHEM Rechner zu langsam ist, respektive FHEM vom Betriebssystem her ausgebremst wird. Den Effekt kenne ich von einer sterbenen USB-Festplatte, wo dann die Recoveryversuche von Linux Seite her (USB Resets etc.) zu entsprechenden zeitlichen Störungen geführt haben.
Da gibt das Systemlog ggf. Hinweise.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 16 Oktober 2016, 20:17:27
Hallo Ansgar!

Vielen Dank dir für den Hinweis, in die Richtung kann ich mal weiter forschen.
Ich habe in der Tat fast meinen ganzen Hausstand mittlerweile in FHEM eingebunden. Vom Vorgehen her werde ich erst mal versuchen, meine bestehende Config abzuspecken.

Gibt es vielleicht eine Möglichkeit, Profiling-Daten je Modul zusammeln (ohne dafür die Module umschreiben zu müssen)?

Meine HW sollte schon passen: Ein RasPI 2B auf dem außer FHEM nur noch Pilight läuft. Weder die SD-Karte noch der PI machen laut dmesg und syslog Mucken, das sieht alles in Ordnung aus.

Ich halte dich auf dem Laufenden, was bei der Sache herauskommt.


Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Oktober 2016, 21:39:51
Hallo Christian,

das hier ist die größte Merkwürdigkeit:
2016.10.16 15:49:11.723 4: TSCUL_Parse: nanoCULHomeMatic  056992 A FFA3 00300592 00 0E 03 A011 D3AA78 4AD28C  -138
2016.10.16 15:49:17.567 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD28C 0201C80000
2016.10.16 15:49:17.569 4: CUL_HM_Resend: BrZi_ErkerRe_Rollo nr 2
2016.10.16 15:49:19.107 4: TSCUL_Parse: nanoCULHomeMatic  064372 A FFA1 00300744 00 11 03 A002 4AD28C D3AA78 0423FCBBFBD2E102 -70
2016.10.16 15:49:19.187 4: TSCUL_Parse: nanoCULHomeMatic  064456 A FFA3 00306560 00 0E 03 A011 D3AA78 4AD28C  -138
15:49:11.723 wird der send des vorherigen Set Befehls von nanoCUL quittiert.
15:49:17.567 wird der nächste, wiederholte Versuch gesendet
15:49:19.107 wird die empfangene Antwort des vorherigen von FHEM "empfangen", also ca. 7 Sekunden verzögert
15:49:19.187 kommt die Sendequittung des wiederholten Versuchs, am Zeitstempel 00306560 (in ms mit 8ms Auflösung) ist eindeutig zu sehen, das vorher eine Verzögerung aufgetreten ist. Aber auch die kommt mehr als 1,5s später, was nicht von der Firmware auf dem nanoCUL verursacht wird.

Wenn es dumm läuft, macht der USB-Seriell Baustein auf dem nanoCUL noch Verzögerung, oder der USB Treiber, weil der Versand der Wiederholung ja noch dazwischen gelaufen ist.
Bist Du bei dem RasPi auch aktuell?
sudo aptitude und Update kann eventuell auch helfen.

Zu Pilight Nebenwirkungen kann ich nichts sagen. Was machst Du mit Pilight? Kann das längere Zeit den I/O blockieren?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 16 Oktober 2016, 21:58:20
Hi Ansgar!

Der RasPI ist aktuell, habe das letzte Upgrade vor ca. 2 Wochen gemacht. Ich bin auf Jessie und habe keine Testing oder Experimental-Pakete drauf.

Pilight hab ich zu Beginn für die IT Komponenten verwendet. Das läuft jetzt größtenteils über einen 433er CUL. Aktuell nutze ich Pilight nur noch für ein paar exotische Themen. Nicht ist leichter, als einen Test mit deaktivierten Pilight zu machen, geht nur heute Abend nicht mehr.

Ich nutze viele Entertainment-Module, z. B. 71_DENON12_AVR.pm, 70_ENIGMA2.pm, 82_LGTV_IP12.pm. Dazu dann noch Zeug für den Raspi wie 42_SYSMON.pm, Telegram, AMAD, HTTPMOD. Da würde ich ansetzen und die Dinger selektiv deaktivieren.


Viele Grüße,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 17 Oktober 2016, 19:27:31
Noch ein kleiner Nachtrag:
Habe mir jetzt das HM-MOD-RPI-PCB besorgt und via USB-TTL Adapter (UM 2102) an meinen RPi angeschlossen.
Damit fahren alle 8 Rollläden bei gleichzeitiger Bedienung absolut sauber. Das entsprechende FHEM Modul und die Firmware scheinen bei ansonsten gleichen Voraussetzung (habe noch keine Module deaktiviert) deutlich resistenter gegen Timing Probleme zu sein.

Ich werde trotzdem nochmal weiterforschen, ob ich das via CUL auch noch sauber hinbekomme.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Oktober 2016, 21:35:14
Hallo Christian,

da das AES Signing un ACK wohl vom HM-MOD-RPI-PCB abgearbeitet wird, so weit ich das verstehe, wundert mich das nicht.

Die TSculfw ermöglicht ein besseres Timing, aber FHEM muss die Sendedaten, auch AES Signing und ACK, doch früh genug bereit stellen.
Der eingeschränkte Speicher auf vielen CUL Hardware Plattformen, so auch nanoCUL, sind leider nicht sonderlich geeignet, um das AES und ACK auch auf CUL abzuarbeiten.
AES Signing wohl eher, da vom vorherigen Sendebefehl die hmId des device bekannt ist. Natürlich auf Kosten anderer Funkprotokolle.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Oktober 2016, 22:45:54
Hallo Testwillige,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 (https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979) wieder eine Aktualisierung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 18 Oktober 2016, 23:01:04
Hi Ansgar,

klar gerne, kann aber etwas dauern...

Gibt es was besonderes zu testen/beachten?

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 Oktober 2016, 21:42:56
Hallo Joachim,

bezüglich AES Hängern habe ich eine Änderung in 10_CUL_HM.pm eingebaut.
Daher diese bitte mit testen.
Christian hatte zusätzlich Timing Probleme mit FHEM, so dass der IO zu seinem nanoCUL verzögert erschien, was beim gleichzeitigen Schalten seiner Rollos aufgefallen ist. Wäre interessant zu sehen, ob Du die Probleme auch hast. Es könnte ja auch eine Einschränkung in Verbindung mit dem nanoCUL USB-Seriell Schnittstellenbaustein sein, wenn der z.B. mit FIFO Threshold Pufferung arbeitet und daher Datenpakete erst dann komplett ankommen, wenn Sendeschwellen erreicht werden (auch wenn ich doch eher an FHEM Module mit langer Rechenzeit denke).

Die TS Firmware ist unverändert.

Ansonsten habe ich 00_TSCUL.pm/16_TSSTACKED.pm um einige nicht HM Protokolle erleichtert, so dass die Module, die ich zusätzlich beigepackt habe, unterstützt werden, ansonsten jedoch 00_CUL.pm und 16_STACKABLE_CC.pm genutzt werden müssen.
Es werden also die Module CUL_HM, TSKS300, TSCUL_WS, TSCUL_TX, TSIT, UNIRoll_TS, CUL_IR und HMS unterstützt.

Mit Rudolfs Tip https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 (https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057) kannst Du nach dem Kopieren/Austausch der Dateien auch das Commandref aktualisieren und damit dann auch Doku lesen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 19 Oktober 2016, 22:56:20
bezüglich AES Hängern habe ich eine Änderung in 10_CUL_HM.pm eingebaut.
Daher diese bitte mit testen.

Hmmm habe bislang noch nichts mit AES gemacht...
Mal sehen was ich noch an HM-Geräten am Testsystem hängen habe und dann mal nachlesen was/wie AES...
Kann aber bissi dauern.


Christian hatte zusätzlich Timing Probleme mit FHEM, so dass der IO zu seinem nanoCUL verzögert erschien, was beim gleichzeitigen Schalten seiner Rollos aufgefallen ist. Wäre interessant zu sehen, ob Du die Probleme auch hast. Es könnte ja auch eine Einschränkung in Verbindung mit dem nanoCUL USB-Seriell Schnittstellenbaustein sein, wenn der z.B. mit FIFO Threshold Pufferung arbeitet und daher Datenpakete erst dann komplett ankommen, wenn Sendeschwellen erreicht werden (auch wenn ich doch eher an FHEM Module mit langer Rechenzeit denke).

Hmmm, Rolloaktoren habe ich leider gar keine.
Wie bzw. mit welchen Aktoren könnte ich das "simulieren"??
Wobei ich eh nur einen Schaltaktor im Einsatz habe den ich verwenden könnte...
...mit mehrere gleichzeitig könnte also schwierig werden...


Die TS Firmware ist unverändert.

Ansonsten habe ich 00_TSCUL.pm/16_TSSTACKED.pm um einige nicht HM Protokolle erleichtert, so dass die Module, die ich zusätzlich beigepackt habe, unterstützt werden, ansonsten jedoch 00_CUL.pm und 16_STACKABLE_CC.pm genutzt werden müssen.
Es werden also die Module CUL_HM, TSKS300, TSCUL_WS, TSCUL_TX, TSIT, UNIRoll_TS, CUL_IR und HMS unterstützt.

Ok, dann kann ich den CUL ja mal lassen...
...und ansonsten kopiere ich einfach die neuen Module, oder!?
(Backup ja klar wobei nicht so entscheidend, da "nur" Testsystem/"Spielwiese"  ;-)   )


Mit Rudolfs Tip https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 (https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057) kannst Du nach dem Kopieren/Austausch der Dateien auch das Commandref aktualisieren und damit dann auch Doku lesen.

Mache ich mal ;-)

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: weini am 19 Oktober 2016, 23:05:13
Zitat
Hmmm, Rolloaktoren habe ich leider gar keine.

Das Problem kommt IMHO nicht von den Rollladenaktoren an sich sondern aus der Situation, wenn mehrere Aktoren gleichzeitig geschaltet werden sollen.
Bei mir sind das die Rollläden, für einen Test tun es aus meiner Sicht aber genauso Lichtschalter, Dimmer etc.

VG,
Christian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 19 Oktober 2016, 23:11:56
Das Problem kommt IMHO nicht von den Rollladenaktoren an sich sondern aus der Situation, wenn mehrere Aktoren gleichzeitig geschaltet werden sollen.
Bei mir sind das die Rollläden, für einen Test tun es aus meiner Sicht aber genauso Lichtschalter, Dimmer etc.

VG,
Christian

Hi Christian,

jaja dachte ich mir schon...
...trotzdem: bei nur einem Aktor schwierig mehrere gleichzeitig ;-)

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Oktober 2016, 20:37:26
Hallo Testwillige,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 (https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979) wieder eine Aktualisierung.
Ich habe in 10_CUL_HM.pm bei meinen Änderung zum AES Signing noch eine "Unschönheit" übersehen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 27 November 2016, 18:19:57
Hallo Testwillige,

hier https://forum.fhem.de/index.php/topic,24436.msg635101.html#msg635101 (https://forum.fhem.de/index.php/topic,24436.msg635101.html#msg635101) geht's zur neuen Version!

---------------------------------------------------------------------------------------------------

ich habe nun einiges vom Timing und auch das AES Signing für HM mit in die Firmware aufgenommen.
Die AES Keys (3 Stück) können genau wie bei HMLAN gesetzt werden (von TSCUL Seite ist dafür der Befehl Ak ergänzt um 3 Keys zu setzen und die hmKey Attribute).

TSCUL versucht nun Befehle an ein device 3 mal abzusetzen, bis eine Antwort kommt.
Wenn ein device ein AES Signing anfordert, so führt dies TSCUL mit den verfügbaren Keys aus. Der Default Key ist natürlich auch in der Firmware hinterlegt.
Dies ist im Gegensatz zu HMLAN etc. auch das einzige automatische ACK seitens TSCUL, d.h. 10_CUL_HM.pm muss die sonstigen ACKS/NACKS weiterhin senden (rechtzeitig an TSCUL schicken).

Damit sind die Timing Probleme weiter entschärft, da Kommunikation von TSCUL zum device bezüglich Timing im Wesentlichen behandelt wirdt.
Bei Kommunikation eines devices zu TSCUL muss weiterhin FHEM via 10_CUL_HM.pm schnell genug eine Antwort liefern.

Je nach CUL Hardware werden bis zu 8 Sendepuffer verwaltet (einer wird stets für AES Signing genutzt). Mittels eines Flags wird stets eine "Unterhaltung"ssequenz zu einem device abgeschlossen, bevor Puffer mit Daten für andere Devices abgearbeitet werden. Aus diesen Sendedaten wird auch die eigene HMID "gelernt".
Bei Empfang eines unaufgefordeten Datenpakets von einem device an diese gelernte HMID mit Antwortanforderung wird von TSCUL ebenfalls eine "Unterhaltung" für ca. 400ms gesetzt, so dass eine Antwort von 10_CUL_HM.pm direkt entsprechend Antworttiming gesendet wird und so lange nichts an ein anderes device gesendet wird.

Im Anhang ist in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.
Alle vorcompilierten .HEX Firmware Files haben 8 (+1) Sendepuffer konfiguriert.
Die .HEX files haben ein TS im Filenamen vorangestellt bekommen.

Ergänzender Hinweis: Nach dem flashen von TSCUL kann es sein, dass das Betriebssystem TSCUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen.
Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.
Für CULs mit nativer USB Schnittstelle (z.B. CUL V3.x oder CUN) kann die \Firmware\tsculfw-code-459-trunk_lufa_00_04\culfw\Devices\99-usb-serial.rules nach /etc/udev/rules.d/99-usb-serial.rules kopiert werden. Dann wird CUL stets der Schnittstelle /dev/CUL868_0 (oder /dev/CUL433_0 bei 433.9MHz Version) zugewiesen und er kann mit
define CUL_868 TSCUL /dev/CUL868_0@12000000 1234bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Das geht leider nicht bei nicht nativen USB CULs wie z.B. nanoCUL oder CUNO2. Hier muss eine 99-usb-serial.rules nach den Daten in der dmesg Ausgabe erstellt oder modifiziert werden, um den gleichen Effekt zu erzielen, sofern der USB-Seriell Interfacebaustein eine eindeutige Seriennummer liefert.
Ansonsten kann es noch mit der USB-Schnittstelle probiert werden, an der CUL eingesteckt ist ("lsusb" Ausgabe), was an meinem RasPi aber nicht funktioniert hat, da dieser abhängig von Warmstart oder Kaltstart andere USB-Portnummern vergibt.

In der TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip sind die neuen und geänderten Module zu finden.

 00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
 DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
 CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
 16_TSSTACKED.pm -> statt der 16_STACKABLE_CC.pm, aus STACKABLE_CC werden damit TSSTACKED devices in der fhem.cfg (händisch anzupassen)

 10_TSIT.pm            -> optional statt der 10_IT.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus IT wird dann TSIT in der fhem.cfg (händisch anzupassen), das normale IT sollte nun auch nutzbar sein
 10_TSIT.pm ist entfallen. Bitte ggf. die fhem.cfg wieder auf IT umstellen und 10_IT.pm verwenden.
 10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
 13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen)
 14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
 14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
 CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_CUL_HM.pm muss ausgetauscht werden, bis @Martin die notwendigen Änderung in den Standard übernommen hat. Hier wird auf CUL_Util.pm zurück gegriffen, um den CUL Typ abzufragen.
10_CUL_HM.pm muss nicht mehr ausgetauscht werden, da Martin die notwendigen Änderung in den Standard übernommen hat. Bitte ggf. attr global exclude_from_update entsprechend anpassen, um den automatischen update für 10_CUL_HM.pm wieder zuzulassen.

Mischbetrieb mit 00_CUL.pm und 16_STACKABLE_CC.pm ist nicht möglich ohne Anpassungen im Code dieser Module. Das ist nur relevant für einen Stapel aus SSC + COC/CCD Modulen.
Wer also mit einem weiteren CUL z.B. die a-culfw nutzen möchte, kann dies nicht ohne weiteres mit einem SCC Modul tun, wenn im SCC/COC Stapel auch TSCUL für z.B. HM genutzt werden soll.

Mischbetrieb mit 00_CUL.pm und 16_STACKABLE_CC.pm ist ab # $Id: 00_CUL.pm 12983 2017-01-06 13:53:27Z StefanStrobel $  und # $Id: 16_STACKABLE_CC.pm 12973 2017-01-06 10:01:25Z StefanStrobel $ möglich da Rudolf die Änderungen eingebaut hat. Danke!

Wie immer, vor Austausch und Veränderungen der module und fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem Update am ungewollten Austausch der angepassten Module hindern:

attr global exclude_from_update 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm

Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 (https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057) noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.

fhem> { `perl contrib/commandref_join.pl` }

Gruß, Ansgar.

EDIT: Commandref um hmKey ergänzt.
EDIT: Update VTS 0.04 CCA geändert
EDIT: Update VTS 0.05 Bug in Sendewarteschlange behoben und Code für richtige Sendereihenfolge zum gleichen device bei gleicher Message Nummer und FHTID wird nicht mehr von TSCUL gesetzt, wenn 'T' nicht unterstützt wird (z.B. nanoCUL), 10_CUL_HM mit TSCUL auf Stand 12707 gebracht
EDIT: 10_CUL_HM.pm muss nicht mehr ausgetauscht werden ab Stand # $Id: 10_CUL_HM.pm 12943 2017-01-03 08:35:18Z martinp876 $
EDIT: CCA Einstellung für IT und SlowRF Default unempfindlicher gewählt
EDIT: TSCUL um set ITClock ergänzt -> IT sollte statt TSIT nutzbar sein
EDIT: Update VTS 0.06 CCA Korrekturen, ASKSIN Wiederholtiming verkürzt und HEX Files um TS im Namen ergänzt. TSIT entfällt -> IT verwenden
EDIT: TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip enthält nun source für miniCUL (ungetestet)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: klausw am 29 November 2016, 00:45:28
Hi Ansgar,

Zum Glück bin ich auf diesen Thread gestoßen.
Endlich funktionieren meine HM-SEC-SCo anstandslos.


Es tauchen allerdings noch Perlwarnungen im Log auf:

2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1008, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1017, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1180, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1866, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1875, <$fh> line 37.

Am Beispiel von Zeile 1008:
foreach (keys $unkndst){zu
foreach (keys %{$unkndst}){
behebt die Warnungen.

Grüße
Klaus
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: christian.asd am 29 November 2016, 09:39:28
Zum Glück bin ich auf diesen Thread gestoßen.
Endlich funktionieren meine HM-SEC-SCo anstandslos.

Bei mir das Gleiche. Danke für die Arbeit!!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 30 November 2016, 08:50:25
Ich möchte sehr gerne die neue Firmware testen, da ich mit mehreren Devices Kommunikationsprobleme habe.

Ich benötige aber etwas Nachhilfe: Die Firmware ist geflasht, die neuen Module in fhem kopiert. In der fhem.cfg habe ich folgende Änderung eingetragen:
define CUL_01 TSCUL /dev/ttyACM0@9600 1034
Nur leider wird dann der CUL nicht initialisiert. Was mache ich falsch?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 Dezember 2016, 01:05:48
Hallo Klaus,

Zitat
Es tauchen allerdings noch Perlwarnungen im Log auf:
danke für den Hinweis mit den Warnungen und der Lösung dazu, kann ich bei Gelegenheit mal einbauen. Alllerdings bekomme ich die Warnungen bei mir nicht. Kann es sein, dass Du schon länger keine Perl Updates mehr eingespielt hast?

Schön, dass es auch bei Dir mit der Firmware läuft.

Hallo Frank,

define CUL_01 TSCUL /dev/ttyACM0@12000000 1034wäre richtig, wenn Dein CUL ein CUL V3.4 USB Stick ist. Und Du nur ein entsprechend eingebundenes USB Device unter Linux hast.
Im Terminalfenster gib bitte mal
dmesgein. In der Ausgabe solltest Du CUL868 finden (wenn es ein USB device ist), nebst der zugewiesenen Schnittstelle, die z.B. auch /dev/ttyACM1 sein könnte.
Die Ausgabe vom FHEM Log könnte auch Hinweise zu Deinem Problem liefern, nebst deutlich mehr Infos, welches System Dein FHEM beherbergt und welche CUL Hardware Du einsetzt. Die Tips sind so nur auf Glaskugel Basis zu geben.

Außerdem noch ein paar nützliche Attribute für Homematic:
attr CUL_01 event-on-change-reading cond
attr CUL_01 webCmd credit10ms:uptime:hmPairForSec 300
#attr CUL_01 hmId F11034
#attr CUL_01 rfmode HomeMatic
Die letzten beiden braucht Du für Homematic ohne "#", also aktiv, wenn Du keine VCCU nutzt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 01 Dezember 2016, 07:46:00
Hallo Ansgar,

vielen Dank für deine Hilfe.

Ich habe einen CUL V3, ob er 3.4 weiß ich nicht. wie wäre denn die richtige Konfiguration, wenn es kein V3.4 CUL ist?

Meine dmesg (Auszug von CUL):
[   99.183853] usb 1-2: USB disconnect, device number 2
[  112.025871] usb 1-2: new full-speed USB device number 4 using xhci_hcd
[  112.156478] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[  112.156481] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  112.156482] usb 1-2: Product: CUL868
[  112.156484] usb 1-2: Manufacturer: busware.de
[  112.156485] usb 1-2: SerialNumber: 868000
[  112.156570] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[  112.157858] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Die vollständige dmesg findet ihr im Anhang.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 01 Dezember 2016, 12:00:50
Hallo Frank,

Ich möchte sehr gerne die neue Firmware testen, da ich mit mehreren Devices Kommunikationsprobleme habe.

Ich benötige aber etwas Nachhilfe: Die Firmware ist geflasht, die neuen Module in fhem kopiert. In der fhem.cfg habe ich folgende Änderung eingetragen:
define CUL_01 TSCUL /dev/ttyACM0@9600 1034
Nur leider wird dann der CUL nicht initialisiert. Was mache ich falsch?

D.h. mittels define CUL_01 CUL /dev/ttyACM0@9600 1034 lief er schon mal aber halt "schlecht"??

Dann sollte die "Umstellung" auf TSCUL eigentlich keine Probleme machen...
Lief bei mir problemlos...

Hast du weitere USB-Geräte?
Dann evtl. mal per "/dev/serial/by-id/..." bzw. "/dev/serial/by-path/..." einbinden/definieren.

Noch etwas ist mir aufgefallen (habe allerdings einen nanoCUL): ich habe eine Baudrate von 38400 statt 9600...

Also define TSCUL /dev/serial/by-path/platform-XXXXXX-port0@38400 1111.

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 01 Dezember 2016, 12:05:58
ja, bisher lief der CUL. Nur nach der Umstellung auf TSCUL nicht mehr ...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: klausw am 01 Dezember 2016, 13:38:14
Hallo Ansgar,

danke für den Hinweis mit den Warnungen und der Lösung dazu, kann ich bei Gelegenheit mal einbauen. Alllerdings bekomme ich die Warnungen bei mir nicht. Kann es sein, dass Du schon länger keine Perl Updates mehr eingespielt hast?

Das Pi2 ist relativ frisch aufgesetzt mit Raspbian Jessie Lite 2016-09-23)  (am 23.11. mit apt-get uptate und upgrade auch aktuell) , Perl ist Version v5.20.2

Könnte auch umgekehrt sein, das der Status wieder auf experimental gesetzt wurde. Es ist bei mir schon vorgekommen, das nach einem upgrade/Neuinstallation ähnliche Fehlermeldungen dazu gekommen sind.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 01 Dezember 2016, 17:42:32
Hallo Ansgar,

Ich habe alles nochmal erneut installiert ... und siehe da ... Jetzt läuft es.

Vielen herzlichen Dank. Die SEC-Devices laufen und wie es aussieht auch die Fernbedienung scheint jetzt endlich den CMD-Stau aufzulösen. Hurra.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 01 Dezember 2016, 17:58:37
Hallo,

hätte versucht die neue Firmware zu flashen, bekomme aber immer die Fehlermeldung "dfu-programmer: no device present. "
Vorgegangen bin ich wie beschrieben:
Ich empfehle bei CULV3 folgendes vorgehen:
1) CUL flashen
CUL file (.hex) nach FHEM/firmware kopieren
98_CULflash.pm nach FHEM kopieren
CULflash <CUL> CUL_V3

2) Betrieb
00_CUL.pm nach FHEM kopieren
reload 00_CUL

Die im Forum vorgeschlagenen Lösungen mit der Rechtevergabe hilft nicht, ich benutze einen Selbstbau CUL mit einem Arduino Nano laut Gummibär.
Kann mir jemand weiterhelfen? Möchte diese FW gerne probieren, da ich immer Probleme mit mit einigen HM Devices habe.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 02 Dezember 2016, 00:29:15
Die im Forum vorgeschlagenen Lösungen mit der Rechtevergabe hilft nicht, ich benutze einen Selbstbau CUL mit einem Arduino Nano laut Gummibär.

Habe ebenfalls einen nanoCUL mit dieser FW geflasht.
Aber du musst die doch sowieso selber bauen!?

Also im verzeichnis .../culfw/Devices/nanoCUL die board.h nach deinen Bedürfnissen anpassen.

Was ich gemacht habe ist ab hier zu finden:

https://forum.fhem.de/index.php/topic,24436.msg466274.html#msg466274 (https://forum.fhem.de/index.php/topic,24436.msg466274.html#msg466274)

Dann einfach 'sudo make' zum "bauen" und dann 'sudo make program' zum "flashen"...

Evtl. im makefile den Port anpassen, also falls dein CUL nicht /dev/ttyUSB0 ist.

Ich hatte zeitgleich einen nanoCUL als mySensors Gateway stecken und fälschlicherweise den "umgeflasht".

Seit dem ziehe ich alle USB-Geräte raus und stecke nur den nanoCUL zum flashen und schaue ob dieser wirklich USB0 ist...
...ansonsten passe ich das makefile an...

Hat bislang immer geklappt und ich hab schon einige male hin und her geflasht (wie du dem Thread entnehmen kannst)...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 02 Dezember 2016, 12:14:11
Nur noch eine Frage,
ist das hier die richtige FW
oder wo finde ich den letzten Stand?

https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 02 Dezember 2016, 12:24:51
Nur noch eine Frage,
ist das hier die richtige FW
oder wo finde ich den letzten Stand?

Das ist die Version, die ich auch genommen habe und aus meiner Sicht der aktuelle Stand.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 Dezember 2016, 21:26:13
Hallo Maxl,

in der zip Datei des Thread Eintrags https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) ist auch eine nanoCUL.hex zu finden.
Compiliert mit board.h:
#ifndef _BOARD_H
#define _BOARD_H

#include <stdint.h>

/* if you have an Arduino with only 8MHz disable the next line */
#define HAS_16MHZ_CLOCK

/* if you are using a cc1101 module for 868MHz disable the next line */
//#define HAS_CC1101_433


#define HAS_SPI_SEND_INLINE             // SPI single byte send is inlined
#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_PIN PINB
#define SPI_SS 2
#define SPI_MISO 4
#define SPI_MOSI 3
/* die aufgeloetete gelbe LED ist an PB5/SCLK angeschlossen! */
#define SPI_SCLK 5

#define SPI_CC1101_READ_SPECIAL_PORT  PORTB
#define SPI_CC1101_READ_SPECIAL_DDR   DDRB
#define SPI_CC1101_READ_SPECIAL_PIN   6     // we missuse this unused (has to be checked!) pin as fast signaling bit for special cc1101_read_buf

#define CC1101_CS_DDR         SPI_DDR
#define CC1101_CS_PORT        SPI_PORT
#define CC1101_CS_PIN         SPI_SS

#define CC1101_MISO_PORTIN    SPI_PIN
#define CC1101_MISO_PIN       SPI_MISO

/* cc1101 GDO0 Tx / Temperature Sensor */
#if 0
#define CC1101_OUT_DDR          DDRC
#define CC1101_OUT_PORT         PORTC
#define CC1101_OUT_PIN          PC0
#define CC1101_OUT_IN           PINC
#define CCTEMP_MUX              CC1101_OUT_PIN
#else
#define CC1101_OUT_DDR          DDRD
#define CC1101_OUT_PORT         PORTD
#define CC1101_OUT_PIN          PD3
#define CC1101_OUT_IN           PIND
#define CCTEMP_MUX              CC1101_OUT_PIN
#endif

/* cc1101 GDO2 Rx Interrupt */
#define CC1101_IN_DDR           DDRD
#define CC1101_IN_PORT          PORTD
#define CC1101_IN_PIN           PD2
#define CC1101_IN_IN            PIND

#define CC1101_INT              INT0
#define CC1101_INTVECT          INT0_vect
#define CC1101_ISC0             ISC00
#define CC1101_ISC1             ISC01
#define CC1101_EICR             EICRA

/* externe LED */
#define LED_DDR                 DDRB
#define LED_PORT                PORTB
#define LED_PIN                 1

//#define LED_ON_DDR              DDRB
//#define LED_ON_PORT             PORTB
//#define LED_ON_PIN              1

#define CALCTIME_TIMER_TCNTn       TCNT2
#define CALCTIME_TIMER_TCCRnA      TCCR2A
#define CALCTIME_TIMER_TCCRnB      TCCR2B
#define CALCTIME_TIMER_TCCRnB_CFG  _BV(CS21)

/* 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;

#define HAS_UART
#define UART_BAUD_RATE          38400
/* ATMega328P has only one UART, no need to define the UART to use */
//#define USART_RX_vect           USART0_RX_vect
//#define USART_UDRE_vect         USART0_UDRE_vect

// 2KBytes Internal SRAM
#define TTY_BUFSIZE             128   // RAM: TTY_BUFSIZE*4
#define CMD_BUFSIZE             (2 + 4 + (2 * 50) + 1)      // maximum length of a command (without \r \n) +1 for terminating 0


#define FULL_CC1101_PA                // PROGMEM:  108b

#define USE_TTYDATA_NO_FUNCTION_CODE  // use new version of command decoding, saves some bytes
#define HAS_CC_INTERRUPT_COUNTER        // cc1101 interrupt counter, read with command CC0, usefull for debbugging

#define FHTBUF_SIZE           174     //                 RAM: 174b
#define RCV_BUCKETS             2     //                 RAM: 25b * bucket
#define HAS_GET_TIMESTAMP
#define HAS_FULL_RF_ANALYZE
//#define HAS_NO_WS2000_V1_1_SUPPORT    // undef to enable WS2000 V1.1 protocol support -> but more wrong receptions possible
#define HAS_RF_RECEIVE_TIMESTAMP
#define HAS_RF_RECEIVE_FILTER_ADAPTION
#define HAS_RF_RECEIVE_KEYING
#define HAS_SLOWRF_RECTO_ACTION
//#define HAS_RSSI_DISPLAY_NONLCD
//#define HAS_RF_RECEIVE_RECORD_LOWMEM  // we have low memory, don't use it
//#define HAS_RF_RECEIVE_RECORD_SYNC
//#define HAS_RF_RECEIVE_RECORD_APPEND_TO_DATA
//#define HAS_RF_ROUTER                   // PROGMEM: 1248b  RAM: 44b
#define HAS_RAWSEND                   //
#define HAS_EM_SEND                   //
//#define HAS_KS_SEND                   //
//#define HAS_TX3_SEND                  //

#define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b

/* Intertechno Senden einschalten */
#define HAS_INTERTECHNO
#define HAS_INTERTECHNO_V3
#define HAS_HOMEEASY
//#define HAS_TCM97001
/* Intertechno Empfang einschalten */
#define HAS_IT       // define to enable IT support

#define HAS_CC1101_RX
#define HAS_CC1101_TX_CCA
#define HAS_CC1101_TX_INTDIS
#define HAS_CC1101_TX_CCA_INTDIS
#define HAS_CC1101_RX_INTEN
#define HAS_CC1101_TO_STATE
#define HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#define HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX
#define HAS_CC1101_REGULAR_CALIBRATION_AFTER_RX_FUNC
#define HAS_CC1101_FORCE_CAL_MANUAL
#define HAS_CC1101_PLL_LOCK_CHECK_MSG
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_RXTX
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_SW
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_CALSTATE

/* HAS_MBUS requires about 1kB RAM, if you want to use it you
   should consider disabling other unneeded features
   to avoid stack overflows
*/
//#define HAS_MBUS

// HM support
#define HAS_ASKSIN
#define ASKSIN_SEND_BUFS       3      // ASKSIN send buffers, 55b RAM each buffer

//#define HAS_MORITZ
//#define HAS_RWE
#define HAS_REVOLT   // define to enable REVOLT support
#define HAS_ESA      // define to enable ESA support
#define HAS_TX3
//#define HAS_IT       // define to enable IT support
//#define HAS_INTERTECHNO_V3
#define HAS_UNIROLL
#define HAS_HOERMANN
#define HAS_MEMFN
//#define HAS_MEMORY_TESTMEM              // compiles in mT extension for testing RAM
#define HAS_SOMFY_RTS
#define HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
#define HAS_FHT_8v                    // PROGMEM:  586b  RAM: 23b
#define HAS_FHT_SEND
#define HAS_FS20_SEND
#define HAS_FHT_TF
//#define HAS_KOPP_FC

#define HAS_IRRX                        //IR Receiption
//#define IRRX_SPECIAL_PORT       PORTA
//#define IRRX_SPECIAL_DDR        DDRA
//#define IRRX_SPECIAL_PIN        7       // we missuse this unused pin as fast clock divide bit for IRRX in TIMER0_COMPA_vect
#define F_INTERRUPTS            15625   // interrupts per second, min: 10000, max: 20000
//#define IRMP_PORT               PORTA
//#define IRMP_DDR                DDRA
//#define IRMP_PIN                PINA
//#define IRMP_BIT                2       // use PA2 as IR input on AVR
#undef  HAS_IRRX

#define HAS_IRTX                            //IR-Transmission
#define IRSND_OCx               IRSND_OC2A  // use OC2A
#ifndef F_INTERRUPTS           
#define F_INTERRUPTS            15625   // interrupts per second, min: 10000, max: 20000
#endif
#undef  HAS_IRTX

#define BOARD_ID_STR            "nanoCUL868"
#define BOARD_ID_STR433         "nanoCUL433"
#define CUL_HW_REVISION         "nanoCUL_V1.x"  // adapt to version print on circuit board

#endif

Ob Du was anders angeschlossen hast oder irgend eine andere Quelle für einen Schaltplan genutzt hast, weiß ich nicht.
Ich habe auch selber keinen nanoCUL und kann folglich nichts damit testen.

Da nanoCUL weniger Speicher hat, als CUL oder SCC, trotzem mit serieller Schnittstelle (zu einem seriell USB Interface Baustein) und das mit geringem seriell Puffer arbeitet, kann es sowohl zu Speicherengpässen kommen, als auch zu schlechterem Verhalten, weil der Empfangs-Puffer voll läuft und dadurch Zeichen verloren gehen.
Für ASKSIN habe ich auch nur 2+1 Sendepuffer konfiguriert, um RAM zu sparen. Nicht doll, aber hoffentlich reicht es. Vielleicht geht auch mehr, ohne dass der Speicher zur Laufzeit überläuft, aber ich kann es nicht testen. Das müssen andere ausreizen.

Wie Du das hex File auf den nanoCUL flashst, ohne "make programm" zu verwenden, können Dir Suche und nanoCUL Nutzer sicherlich verraten.
Ich hoffe, es läuft.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 04 Dezember 2016, 19:55:38
Hallo Ansgar,

mit make program bekomme ich folgende Fehlermeldung:

README board.h  makefile  nanoCUL.c
root@raspberrypi:/opt/fhem/culfw-code-00-02-trunk/Firmware/tsculfw-code-459-trunk_lufa_00_02/culfw/Devices/nanoCUL# make
Compiling C: ../../clib/ir.c
Compiling C: ../../clib/irmp.c
Compiling C: ../../clib/irsnd.c
Compiling C: ../../clib/serial.c
Compiling C: nanoCUL.c
Compiling C: ../../clib/memory.c
Compiling C: ../../clib/display.c
Compiling C: ../../clib/ringbuffer.c
Compiling C: ../../clib/ttydata.c
Compiling C: ../../clib/fht.c
Compiling C: ../../clib/rf_receive.c
Compiling C: ../../clib/rf_router.c
Compiling C: ../../clib/rf_send.c
Compiling C: ../../clib/rf_credits.c
Compiling C: ../../clib/clock.c
Compiling C: ../../clib/delay.c
Compiling C: ../../clib/aes_ecb.c
Compiling C: ../../clib/rf_asksin.c
../../clib/rf_asksin.c:172:56: warning: excess elements in array initializer [enabled by default]
../../clib/rf_asksin.c:172:56: warning: (near initialization for 'LastSendMsg') [enabled by default]
../../clib/rf_asksin.c:173:56: warning: excess elements in array initializer [enabled by default]
../../clib/rf_asksin.c:173:56: warning: (near initialization for 'LastSendMsg') [enabled by default]
Compiling C: ../../clib/cc1101_pllcheck.c
Compiling C: ../../clib/spi.c
Compiling C: ../../clib/cc1101.c
Compiling C: ../../clib/fncollection.c
Compiling C: ../../clib/stringfunc.c
Compiling C: ../../clib/rf_moritz.c
Compiling C: ../../clib/rf_rwe.c
Compiling C: ../../clib/fastrf.c
Compiling C: ../../clib/intertechno.c
Compiling C: ../../clib/somfy_rts.c
Compiling C: ../../clib/rf_mbus.c
Compiling C: ../../clib/mbus/manchester.c
Compiling C: ../../clib/mbus/3outof6.c
Compiling C: ../../clib/mbus/mbus_packet.c
Compiling C: ../../clib/mbus/crc.c
Linking: nanoCUL.elf
Creating load file for Flash: nanoCUL.hex
echo

AVR Memory Usage
----------------
Device: atmega328p

Program:   23300 bytes (71.1% Full)
(.text + .data + .bootloader)

Data:       1258 bytes (61.4% Full)
(.data + .bss + .noinit)


Creating load file for EEPROM: nanoCUL.eep
Creating Extended Listing: nanoCUL.lss
Creating Symbol Table: nanoCUL.sym

Size after:
   text    data     bss     dec     hex filename
  23278      22    1236   24536    5fd8 nanoCUL.elf

root@raspberrypi:/opt/fhem/culfw-code-00-02-trunk/Firmware/tsculfw-code-459-trunk_lufa_00_02/culfw/Devices/nanoCUL# make program
#@if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
#@if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
#echo out > /sys/class/gpio/gpio17/direction
#echo out > /sys/class/gpio/gpio18/direction
#echo 0 > /sys/class/gpio/gpio17/value
#echo 0 > /sys/class/gpio/gpio18/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio17/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio18/value
avrdude -D -p atmega328p -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 -b 57600 -c arduino    -U flash:w:nanoCUL.hex
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

makefile:232: recipe for target 'program' failed
make: *** [program] Error 1
root@raspberrypi:/opt/fhem/culfw-code-00-02-trunk/Firmware/tsculfw-code-459-trunk_lufa_00_02/culfw/Devices/nanoCUL#

Was muß ich im makefile abändern, damit er den Stick findet?

Danke
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Dezember 2016, 20:19:46
Hi Maxl,

ich hab es auch mal mit /dev/serial/by... versucht. Hat bei mir auch nicht geklappt...

Habe dann geschaut "wo" er hängt (wie gesagt alle andern USB-Geräte abgesteckt)...
...also /dev/ttyUSB0 z.B.

Dann ging's...

Aber: kann es sein, dass fhem läuft? Dort bereits den CUL definiert? Dann "hängt" fhem drauf und es kann nicht gehen...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Dezember 2016, 20:30:05
Hallo Maxl,

ich schätze mal, Du musst den nanoCUL erst mal in den Bootloader Modus bringen. (Taste drücken beim Einschalten wie bei anderen auch???? Was sagt die Anleitung?)
Wenn er nicht im Bootloader Modus ist, dann geht nix mit Programmieren.

Wenn Du das geschafft hast, es aber nicht klappt, dann könnte das
Zitat
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0
noch falsch sein, z.B, wenn der USB-Seriell Chip ein anderer ist.
Das stammt aus den original Quellcodes zu CUL, auf die ich aufgesetzt habe.

Letztlich, wie das mit nanoCUL geht, kann ich Dir leider nicht sagen, weil ich keinen nanoCUL habe, um das auszuprobieren.
Deswegen auch der Verweis auf die Suche und andere nanoCUL Nutzer.
Joachim (MadMax-FHEM) kann Dir vielleicht helfen.

Sorry und Gruß,

Ansgar.

PS: Du hast nicht bemerkt, dass ich noch ein Update auf "VTS 0.03" an bekannter Stelle hinterlegt habe.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Dezember 2016, 20:38:06
Hi Ansgar, Maxl,

ich versuch's mal...

Zitat
ich schätze mal, Du musst den nanoCUL erst mal in den Bootloader Modus bringen. (Taste drücken beim Einschalten wie bei anderen auch???? Was sagt die Anleitung?)
Wenn er nicht im Bootloader Modus ist, dann geht nix mit Programmieren.

Musste ich bei mir nicht machen, ging "einfach so"...

Aber Ansgar hat schon recht: welchen nano hast du denn?

Was sagt ein 'lsusb'?

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 04 Dezember 2016, 20:45:03
Hi,

ich vergaß FHEM zu beenden, die Schnittstelle war belegt, geflasht habe ich den Stick, jedoch meldet er sich nicht,
sobald ich die alte orginal FW von Gummibär flashe läuft er wieder, da muß noch etwas falsch sein.
Die board.h habe ich aus beiden Paketen verglichen,die PINs sind zumindest gleich definiert.  :(

Gruß
Mario


Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Dezember 2016, 20:56:53
Hi Mario,

wie meldet sich nicht?

Wird er noch erkannt?

Also 'lsusb' bzw. stimmt /dev/serial/by-id noch??

Mal meinem Link gefolgt wo steht was ich in der board.h angepasst habe?
Bzw. mal geprüft was Ansgar eingestellt hat??

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 04 Dezember 2016, 21:38:44
Hallo,

Zitat
wie meldet sich nicht?
unter FHEM kann ich kein "get ..."  ausführen, bekomme nur den Fehler diconnected, anschliessend ist er wieder initialzed, es wechselt hin und her sobald eine serielle Anfrage gestartet wird, einige devices lassen sich aber steuern, muß erst einmal alles ausprobieren, bei den "get"-Abfragen gibt es Probleme

Zitat
Wird er noch erkannt?
Also 'lsusb' bzw. stimmt /dev/serial/by-id noch??
unter Linux mit ls -l dev/serial/by-id bekomme ich beide angesteckten nano_Culs angezeigt,
beide Sticks laufen mit der alten FW version => V 1.63 nanoCUL868, sobald ich die Neue einspiele
bekomme ich diesen unter FHEM nicht mehr so richtig zum Laufen, das Meiste funktioniert aber :-)

Zitat
Mal meinem Link gefolgt wo steht was ich in der board.h angepasst habe?
Bzw. mal geprüft was Ansgar eingestellt hat??
habe die eingestellte board.h verwendet und mit der aus der "Gummibär"-Seite verglichen, die Ports dürften passen, den Rest kann ich nicht sagen

anbei das was das Logfile berichtet
2016.12.04 20:32:38.812 1: usb create starting
2016.12.04 20:32:51.957 1: usb create end
2016.12.04 20:32:51.963 0: Featurelevel: 5.7
2016.12.04 20:32:51.964 0: Server started with 246 defined e